Was onsite with a customer recently, and had failure trying to upgrade their Build 1610 Current Branch Hierarchy to Build 1702.

The problem was being reported in the SMS_DMP_Downloader log as follows:

• Download redist for update 0fb0a697-662d-45c2-a96c-8c95e5944df7      SMS_DMP_DOWNLOADER       05-Apr-17 12:42:14 PM                 19500 (0x4C2C)
• ERROR: Failed to download redist for 0fb0a697-662d-45c2-a96c-8c95e5944df7 with command  /RedistUrl http://go.microsoft.com/fwlink/?LinkID=841450 /LnManifestUrl http://go.microsoft.com/fwlink/?LinkID=841442 /RedistVersion 201702 /NoUI  "\\#########\EasySetupPayload\0fb0a697-662d-45c2-a96c-8c95e5944df7\redist" .              
• SMS_DMP_DOWNLOADER       05-Apr-17 12:43:42 PM               19500 (0x4C2C)
  Failed to download redist for 0fb0a697-662d-45c2-a96c-8c95e5944df7.  SMS_DMP_DOWNLOADER       05-Apr-17 12:43:42 PM                 19500 (0x4C2C)

If you follow the links you’ll end up downloading CAB files, these are not the files that the downloader is having trouble with, there is further details being logged in the ConfigMgrSetup log, which will indicates the file or files the downloader is failing to download or hash verify.

The CAB files referenced in SMS_DMP_DOWNLOADER contain the metadata for all the files that need to be downloaded for setup to commence, which includes the filename, file size, and a hash so that the files can be hash verified once downloaded, and once verified they are stored away in readiness for use during the upgrade, or discarded and an error thrown.

So if you are experiencing failure in this area, you are either experiencing a denial to download most likely caused by Proxy settings, noting that SMS_DMP_DOWNLOADER is running in SYSTEM context and not USER context, or you are experiencing a hash verification issue due to a corrupted download or simply failure to hash. There could be other variants I’ve not listed, but to date this is all I’ve seen.

Fixing a Proxy settings is a cinch, and if that is your problem then you should be able to fix it up quickly and skip over the rest of this post, and get your upgrade underway.

The release notes for Current Branch detail this issue, and provide a workaround: https://docs.microsoft.com/en-us/sccm/core/servers/deploy/install/release-notes

The suggested workaround is to tweak the Software Publishing registry value which resides in the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers registry path.

This value corresponds to the Internet Explorer security setting Check for publisher’s certificate Revocation and Check for signatures on downloaded programs, as noted here, with a bit of a deep dive here.

I know that SMS_DMP_DOWNLOADER is running under SYSTEM context, and not the currently logged in USER, so I am unsure as to why the Registry Hive is HKCU, and not HKLM, but this is offered as a workaround and I see others have reported it helping them.

Another fix is to get the binaries being referred too in the ConfigMgrSetup log, download them yourself, or obtain from another Hierarchy that went from your build to the build you are upgrading too, and pop them into the location that the downloader is trying to store them in. Rerun the Site upgrade, and repeat if necessary until the upgrade is underway, resorting to the registry change if the hashing is failing completely. This helped me get the upgrade underway.

Had a customer reporting issues with client registration when devices use Management Point Replicas.

Had a look around and discovered that MP Replica’s are not processing brand new Client Registrations.

You’ll see the issue manifesting in the MP_CLIENTID log on the MP being used to perform the registration, and on the device in the ClientIDManagerStartup log where it’ll never complete the registration.

Here is an MP trying to handle the registration request:

The spGetLockState stored procedure is missing from the database, it wasn’t replicated across when the publication was created.

There are more objects missing, just waiting for the EM Product Group to confirm what is what.

I noticed that if you uninstall a client and reinstall it, this issue isn’t triggered.

Soon as I have confirmation of a workaround I’ll update this post. Right now it seems as simple as following through on looking at what spGetLockState refers too, and hunting around to see what other objects are missing, but hold off for a bit as I might get more info soon.

Couple weeks back I mentioned that Client Registration is broken for Management Point Replicas.

I escalated it up to the product group and the great news is that it looks likely to be fixed at the next current branch hotfix rollup for 1702, no promises there, but they are aware of it  which is good.

I also asked for a problem\solution post on TechNet or wherever it should be hosted, so that customers who have this issue can work around it quickly, however, said work if done may be beaten by the hotfix release, so the only obvious option is to wait for the hotfix to arrive.

If you didn’t know you had this issue and cannot wait for a hotfix rollup, say you need to patch new Servers using SCCM, then the good news is that you can either raise a ticket with Premier, or take a look at REPLICATEDOBJECTS on your Primary Site server, note that spGetLockState and DeploymentMutex are probably missing, insert them into that table like a boss, and then redo the publication setup and subscriptions to get things working again.

Thought I’d give one of the new features in ConfigMgr Technical Preview build 1705 called Improvements for SQL Server Always On Availability Groups a walk through, so that I could soak up all the SQL AlwaysOn Availability Group and Windows Server Failover Clustering knowledge.

From the docs:

With this release, you can now use asynchronous commit replicas in the SQL Server Always On availability groups you use with Configuration Manager. This means you can add additional replicas to your availability groups to use as off-site (remote) backups, and then use them in a disaster recovery scenario.

As it says, the reason why you’d run an Availability Group asynchronous Replica is for off-site backup, in the event that you lose your cluster fully, the asynchronous replica can be used for rapid disaster recovery.

To kick the tires on recovery would require restoring the site and loads of work, and since an asynchronous replica DB is the same but with possible data loss (the nature an asynchronous replication), it is the same process as restoring from a full cold backup, so I’ll not test it for now, instead I’ll get the feature working and leave it there.

So what does a SQL AlwaysOn Availability Group asynchronous replica mean or do.

Let’s take a step back. In an Availability Group, when a SQL transaction is to be committed to the Primary instance database it is first replicated to each Replica and committed into its database, once that is done successfully the commit at the Primary instance completes. This means the primary waits around a lot for replicas to commit the transactions being replicated to them, they need to perform well and be physically close network-wise. It makes for high integrity compared to the asynchronous replica, which the Primary instance doesn’t wait around for, it just sends transactions to it and doesn’t wait for acknowledgement, which means that some data “in transit” could be lost if an ‘event’ occurred. With Technical Preview 5 you can now restore from an asynchronous replica database as a supported scenario.

So let’s build us an Availability Group and get ConfigMgr to play ball with it.

The last time I built a cluster was NT4 days, things haven’t changed too much in terms of standing one up, so that wasn’t difficult, but I had several learning experiences around standing up SQL AlwaysOn, which I dare say helped me bottom out my knowledge on the subject.

This guide is not for production usage, you could certainly distil it into a procedure to be applied in production, instead this guide is for lab work only.

Before you can get things underway you’re going to need the following, so as to keep on the rails throughout this guide.

Media

• Operating System – Windows 2016 DataCenter with UI
• SQL Server 2016 (SP if you want, CU’s, whatever ConfigMgr supports)
• SQL Management Console SSMS-Setup-ENU-R16.5.3-B13.0.16106.4

Virtual Machines

1. Domain Controller
2. SQL Server Replica\Node A (192.168.1.170) – 2GB Memory – Single disk
3. SQL Server Replica\Node B (192.168.1.171) – 2GB Memory – Single disk
4. SQL Server Replica\Node C (192.168.1.172 – 2GB Memory – Single disk)
5. A pre-built ConfigMgr Technical Preview Build 1705 Site server with SQL locally installed (can be remote but heck …)

The account that you do all the action with, the one you’ll login, please make it a Domain Administrator, it’ll cut through the ‘butter’ faster, if you want to tighten down then follow the guide and analyse everything post-build.

Right then, get your cool juice and saddle up, as we’re about to ride out and get ourselves SQL AlwaysOn Availability Group  working with ConfigMgr.

Prepare the SQL Server AlwaysOn Replicas

Go ahead and stand up three virtual machines using Windows Server 2016 DataCenter with Desktop.

Once built do the following:

• Give them a name
  
  

• VM1– CMSQLAONA – 192.168.1.170
• VM2– CMSQLAONB – 192.168.1.171
• VM3– CMSQLAONA – 192.168.1.172
  
  

• Join to your Domain
  
  
• Fix their IP and make a note
  
  
• Add the Computer Account of the Technical Preview Primary Site server to the local administrator group on each replica
  
  
• Make sure all replicas have been rebooted to commit the configuration changes
  
  
• At this point I switch on Remote Access for RDP, and turn off the Windows Firewall on the Domain Profile, from there I add in the servers to RDCMan so I can move off of the Hyper-V host.

Install the Windows Failover Clustering feature

Let’s do this in one go across all three nodes.

• Fire up the PowerShell ISA, paste in the below script and let it go:

$serverList = "CMSQLAONA","CMSQLAONB","CMSQLAONC"

ForEach ($server in $serverList)
{
    Install-WindowsFeature -computername $server –Name Failover-Clustering –IncludeManagementTools
}

• After a while you’ll have the clustering feature enabled on all three nodes.
  

Create a Windows Cluster

We’re now going to create our Windows Cluster, this breaks down into two tasks:

1. Create a Network Share for the File Share Witness
2. Create the cluster itself.

The Network share will be used to enable a file system quorum, so that we can introduce a basic cluster into our lab.

Create a Network Share for the Quorum

I chose the Domain Controller to host this share, it is highly available to the lab. The file share witness will not handle large volumes of data, and as a result, will utilise a small footprint during its lifecycle.

• Create a new folder on the Domain Controller anywhere of your choosing, call it CMSQLAOFSW, I’ll use C:\CMSQLAOFSW
  
  
• Share the folder out, give the Full Control share permissions to Everyone
  
  

The ACL’s to this folder will be changed during the Cluster creation process, during which a domain user account representing the name you give the Cluster will be created and given Full Control permissions. The account you are installing with will need to be a Local Administrator on the Domain Controller for all this magic to happen.

• Navigate into your share by referencing it as a UNC in Start\Run, to confirm you are able to access it

Easy. You’ll be creating another share later on.

Create the Windows Cluster

Head over to CMSQLAONA and fire up the Failover Cluster Manager. Its an admin-interface based on ancient MMC technology, so do the right thing, and turn off the Action menu like a Boss!

• Right click Failover Cluster Manager in the left hand pane, then select Create Cluster

• Once the wizard fires up, click through the welcome page and add in your Cluster Nodes CMSQLAONA, CMSQLAONB and CMSQLAONC using the browse button.
  
  
• Once you have all three Nodes listed as below, then click Next
  
  
  

• Next up is testing the cluster nodes by running a set of validation steps, you don’t have to run this but I’d let it run in case there is something exotic about your environment that’ll catch you out later on

• Click Next to pass through the Before You Begin page, select Run all tests (recommended), its the default anyway, and proceed with the wizard by clicking Next

• Have a nose through the list of tests, click Next when ready to run them

• The validation test should pass if you stand the virtual machines up from the ISO’s, but scrolling down you’ll notice that it complains about redundancy for network connections in the Validate Network Communications step, which you’d resolve as part of hardening a procedure for production use, but can ignore in the lab

• You can click on View Report to see a nice HTML based report

• Let’s carry on configuring the Cluster, select Finish in the wizard

• Enter SQLAOCluster as the Cluster Name
  
  
• Give the Cluster Name the IP of 192.168.1.174 or whatever IP you’ve set aside for you lab environment
  
  
• Select Next

• Select Next

• Note that warning about the disk witness, we’re going to use a File Share Witness (FSW) so this can be ignored
  
  
• Select Finish to wrap up
  
  
• Once the wizard has finished, RDP to your DNS server which is no doubt on your Domain Controller, and check out the new record created for the Cluster Name

• You now have a Windows Cluster, but to complete it you will need to add in the Quorum Witness. Our choice of a File Share Witness is driven by the need for simplicity, in a lab environment a disk can be shared amongst VM’s, but it takes the complexity level up a notch, fortunately we can use a SMB File Share to perform the Quorum duties, which is highly uncomplicated to setup, so let’s get it done
  
  
• Return to the Failover Cluster Manager

• Right click SQLAOCluster, select More Actions, and select Configure Cluster Quorum Settings…

• If you do not understand what a Quorum Witness is, please stop and deep dive the subject for a bit, get this foundational knowledge under your belt so as to help round off. I recommend doing this for any part of the guide that takes you out of your comfort zone, when you get that twinge its your brain prompting you to fill the gap, for Quorum Witnesses read here
  
  
• Have a read of the Before You Begin notes before you skip over
  
  

• Select Next

• Select Select the quorum witness
  
  
• Select Next

• Select Configure a file share witness, note the cool Cloud Witness as well as the classic disk witness
  
  
• Select Next

• Punch in the UNC to your File Share Witness share, you can browse to it or manually enter it. If you manually enter then here’s a top tip, always test a UNC by copy\pasting it into Start\Run to make sure you can browse it, obviously if your account doesn’t have rights this method doesn’t work, in those cases I NET USE and pass the credentials to make sure all is well
  
  
• Select Next

• Confirm and click Next

• Select Finish
  
  
• Note that Witness now changes to File Share Witness (FSW), and shows the UNC path to it

• Paste the File Share Witness UNC into Start\Run, to see the file system objects just created by the Cluster

You now have a Windows Server Failover Cluster.

Ping the Cluster Name and you will get a ping response back from the IP you specified during the setup of the Cluster Name, I keep wanting to say Cluster Interface, I think this is what we called it years ago, or perhaps it just makes more sense to my brain to call it an interface as that is what it is.

Worth noting that we won’t be using the Cluster Name at all for the SQL AlwaysOn Availability Groups. The SQL AO AG’s have their own Cluster Name concept called a Listener. You’ll come to that shortly.

Install SQL 2016 on the SQL AlwaysOn Replicas

• We’ll run SQL using a domain user account so visit your Domain Controller and create a user called CMClusterService, make note of the password, it only needs to be a Domain User

If you run SQL Server using SYSTEM context you’ll need to handle the certificate transfer, I didn’t test this but saw it called out in some Microsoft SQL documentation, it might handle transferring the certificates for you, I did see a call out in some logs when creating the Availability Group that suggest certificates are being exchanged automatically between the Replicas in the Availability Group.

We’ll cookie cut the installation of CMSQLAONB and CMSQLAONC using an INI file we create from installing SQL 2016 manually on CMSQLAONA.

• Insert the SQL ISO media into the CMSQLAONA, CMSQLAONA and CMSQLAONA virtual machines
  
  
• Login to CMSQLAONA
  
  
• Run the Setup.exe on the SQL DVD Media:

• Select Installation

• Select New SQL Server stand-alone installation or add features to an existing installation
  
  
  

• Tick to accept the license terms and select Next

• Tick Use Microsoft Updates to check for updates (recommended) unless you do not have access to the Internet
  
  
• Select Next

• Select Next

• If it finds anything, let it install

• Choose Database Engine Services and keep default paths
  
  
• You could add in Reporting Services, it’ll require another account and also some special handling for the ConfigMgr Reporting Point role. I’ve skipped doing this, since I have SQL Reporting Services and its database on the Primary, along with the ConfigMgr Reporting Point role, which will point to the SQL AlwaysOn Availability Group Listener you’re about to encounter later on in the guide
  
  
• Select Next

• Select Next

• Okay so now we want to set the startup type for the Agent and Server to Automatic
  
  
• Enter the domain user account credentials (CMClusterService) you created for the SQL Cluster for both the Agent and Server services
  
  
• Select the Collation Tab (this is a highly important step)

• Select the SQL collation, used for backwards compatibility radio button, change the collation to SQL_Latin1_General_CP1_CI_AS
  
  
• Select OK

• Select OK

• Add the local Administrators group
  
  
• Add your domain account as well
  
  
• Leave Data Directories, TempDB and FILESTREAM alone
  
  
• Select Next

• Put that path into the clipboard as we’re about to automate the silent unattended installation of two SQL Servers using a modified version of it
  
  

C:\Program Files\Microsoft SQL Server\130\Setup Bootstrap\Log\20170613_143153\ConfigurationFile.ini

• Edit the file and make the following amendments:
  
  

1. False to True for IACCEPTROPENLICENSETERMS
2. False to True for QUIET
3. Put a ; semicolon character before UIMODE

• Copy the file to a newly created folder C:\SQLInstall on both CMSQLAONB and CMSQLAONC
  
  
• Now click Install to get the SQL installation underway on CMSQLAONA
  
  
• Login to CMSQLAONB and fire up a CMD prompt
  
  
• Begin the SQL installation by modifying the passwords in the command below then running it:
  
  

D:\SETUP.EXE /CONFIGURATIONFILE=”C:\SQLInstall\ConfigurationFile.ini” /IAcceptSQLServerLicenseTerms /SQLSVCPASSWORD="<PASSWORD>" /AGTSVCPASSWORD="<PASSWORD>"

• Follow through with the same unattended silent SQL installation steps on CMSQLAONC

• While those SQL installations are bubbling away, go back to CMSQLAONA, and install SQL Management Studio. Back in the day, the studio was part and parcel of the SQL Setup, they diverged into separate installs, which means the console is unlinked from the SQL setup, and can easily be updated with a smaller media footprint
  
  
• Launch the SQL Management Studio installer

• Select Install
  
  
• You can install this on one all three nodes, or just the primary one you’ll be working from, I’ll install to CMSQLAONA only, and do all administration of SQL from there
  
  
• This one can take forever, even on a fast system. Go get yourself some Tea!
  
  

• I recommend pinning the Studio to the Taskbar

Configure SQL

We now need to make some configuration changes to the SQL Server engines on all three of our SQL servers.

Set SQL Engine Memory limits

I recommend that you calculate the memory limits based on how much you added when you created the virtual machines, they can in a small environment run on as little as 1GB.

• RDP onto CMSQLAONA and open Microsoft SQL Server Management Studio using Run as administrator option
  
  
• Connect the studio to all three nodes CMSQLAONA,  CMSQLAONB and CMSQLAONC
  
  
• With the root nodes expanded it’ll look like this:
  
  

• Right click CMSQLAONA and select Properties, then select Memory
  
  

• Repeat for CMSQLAONB and CMSQLAONC

Permission all Nodes for Primary Site access

• Add the computer account of the Primary Site server to the local Administrator group on both CMSQLAONA, CMSQLAONB and CMSQLAONC
  
  
• The CMSQLAONC entry above is redundant in this lab setup, since CMSQLAONC is running in Asynchronous mode and the Primary Site will not establish a direct connection

Bring in the CM Database

Now this is where my lab complicates things. I’ve already taken my Technical Preview 5 Primary Site towards the dark side, and its currently running its brain on a 3-node SQL AlwaysOn Availability Group. I’m going to export the DB and import it CMSQLAONA, but it means the shots will be off when it shows recovery mode.

Since my site database already resides on a SQL AlwaysOn Availability Group, it is running as FULL And not SIMPLE recovery mode. You will most likely be running SQL on the Primary, and it will most likely already be running in SIMPLE recovery mode, in this case the backup steps are the same to liberate a backup of the CM database from that SQL installation.

Take down ConfigMgr

We need to stop ConfigMgr from talking to the Database. At this point the show is over for ConfigMgr, service will resume once the Availability Group is setup and ConfigMgr told to use it.

For my lab all I need to do is wind down the services on the Primary, no site systems exist which could be connecting to the database, but its the primary that’d do the writing to the database anyway.

• RDP over to your ConfigMgr Current Branch Technical Preview 5 Site server
  
  
• Open the Services (MMC) console
  
  
• Stop the following services in this order
  
  

1. ConfigMgr Task Sequence Agent
2. Configuration Manager Remote Control
3. CONFIGURATION_MANAGER_UPDATE
4. SMS Agent Host (if installed)
5. SMS_NOTIFICATION_SERVER
6. SMS_SITE_COMPONENT_MANAGER
7. SMS_EXECUTIVE
8. SMS_SITE_SQL_BACKUP
9. SMS_SITE_VSS_WRITER

• You could use the PREINST /STOPSITE command, but that’ll mark everything for reinstallation the moment you start the services up. This isn’t necessary, since we’re going to start the site up by changing the SQL configuration from the Setup program, which’ll induce component installation behaviour
  
  
• A good working practice is to disable services when you are putting them to sleep for administrative purposes, so that if the server reboots by accident, it won’t come back up and start the application before you are ready

Backup and Move the ConfigMgr Database

I’m now going to backup the ConfigMgr CTP database (CM_CTP), and move the backup file to the CMSQLAONA node in the following location C:\SQLBackup

• Visit SQL Management Studio on the target SQL Server currently hosting your site database
  
  
• Find the site database, right click it and select Tasks and then Back Up…

• For a standalone primary with SQL locally installed, you’ll be backing up a database running in SIMPLE recovery mode, which means the file extension for your backup will be BAK and not TRN, which is the case when you are already running in FULL recovery mode
  
  
• Enter your preferred backup path location, and enter the file name as CMBackup-<CURRENTDATE>.BAK (TRN if you are moving from one SQL AlwaysOn Availability Group to another)
  
  
• Copy the TRN or BAK file over to a new folder called C:\CMBackup on CMSQLAONA
  

Configure the SQL Engine on all Nodes

We’ll modify the SQL Engine on all three node before creating the Availability Group, as doing it later will require micro-managing the Availability Group, failing over between the nodes so as to configure each of them.

• Select CMSQLAONA and click New Query
  
  
• To confirm you are about to run queries against the correct node, take a look at the bottom right of the yellow status bar, it’ll show you the name of the server the query will be run against, as will the studio applications status bar:

SQL Management Studio Application Title bar:

SQL Management Studio Status Bar

• Paste this lot in and click Execute

USE Master;

GO

SP_CONFIGURE 'show advanced options', 1;

RECONFIGURE WITH OVERRIDE;

GO

EXEC SP_CONFIGURE 'max text repl size',2147483647 ;

RECONFIGURE WITH OVERRIDE;

GO

EXEC SP_CONFIGURE 'clr enabled', 1;

RECONFIGURE WITH OVERRIDE;

GO

The result should be:

Configuration option 'show advanced options' changed from 0 to 1. Run the RECONFIGURE statement to install.

Configuration option 'max text repl size (B)' changed from 65536 to 2147483647. Run the RECONFIGURE statement to install.

Configuration option 'clr enabled' changed from 0 to 1. Run the RECONFIGURE statement to install.

• Select CMSQLAONB
  
  
• Paste the same as above and click Execute
  
  
• Select CMSQLAONC
  
  
• Paste the same as above and click Execute

Restore the ConfigMgr Database

It’s time to restore the ConfigMgr database..

• Remain within SQL Management Studio on CMSQLAONA
  
  
• Select CMSQLAONA and right click Databases, select Restore Database…
  
  

• You’ll be presented with the Restore Database page

• Select Device and select the ellipses…
  
  
  

• Select Add
  
  
  
• Navigate to C:\CMBackup and select the CMBackup file

• Select OK

• Select OK

• You can click on Files and you’ll see it is going to restore the Database to the default SQL locations:

• Select OK to get on with the recovery of CM_CTP

Configure SQL Database CM_CTP

Next up is more SQL configuration, but this time not the SQL Engine but the site database.

For this series of steps, you’ll stay on CMSQLAONA and inside SQL Management Studio, and you will change the database name used in the steps to whatever you called your site database, mine is called CM_CTP.

• Select CMSQLAONA and then select New Query

Change Recovery Model from SIMPLE to FULL

Use CM_CTP;

ALTERDATABASECM_CTPSETRECOVERYFULL;

Take stock and contemplate how you’re going to handle SQL Transaction Logs now that you’ll be in FULL recovery mode, and how they mass up on you consuming disk space, and regularly need backing up. I’m going to totally leave you hanging, and let you read up on how to handle this.

Set SA owner on DB

UseCM_CTP;

EXECsp_changedbowner'sa'

Set TRUSTWORTHY bit on DB

USECM_CTP;

ALTERDATABASECM_CTPSETTRUSTWORTHYON;

Enable SERVICEBROKER on DB

UseCM_CTP;

ALTERDATABASECM_CTPSETENABLE_BROKER;

Enable SERVICEBROKERPRIORITY on DB

UseCM_CTP;

ALTERDATABASECM_CTPSET HONOR_BROKER_PRIORITY ON;

You can verify the configuration of SQL by running the following SQL script which is taken from the ConfigMgr Documentation:

Note: You can paste this into your existing query window or create a new one making sure you are focused on the correct SQL server, select what you paste in and then click Execute to execute the selection (change the USE CM_CTP to your database name)

USE CM_CTP

SET NOCOUNT ON

DECLARE @dbname NVARCHAR(128)

SELECT @dbname = sd.name FROM sys.sysdatabases sd WHERE sd.dbid = DB_ID()

IF (@dbname = N'master' OR @dbname = N'model' OR @dbname = N'msdb' OR @dbname = N'tempdb' OR @dbname = N'distribution' ) BEGIN
RAISERROR(N'ERROR: Script is targetting a system database.  It should be targeting the DB you created instead.', 0, 1)
GOTO Branch_Exit;
END ELSE
PRINT N'INFO: Targetted database is ' + @dbname + N'.'

PRINT N'INFO: Running verifications....'

IF NOT EXISTS (SELECT * FROM sys.configurations c WHERE c.name = 'clr enabled' AND c.value_in_use = 1)
PRINT N'ERROR: CLR is not enabled!'
ELSE
PRINT N'PASS: CLR is enabled.'

DECLARE @repltable TABLE (
name nvarchar(max),
minimum int,
maximum int,
config_value int,
run_value int )

INSERT INTO @repltable
EXEC sp_configure 'max text repl size (B)'

IF NOT EXISTS(SELECT * from @repltable where config_value = 2147483647 and run_value = 2147483647 )
PRINT N'ERROR: Max text repl size is not correct!'
ELSE
PRINT N'PASS: Max text repl size is correct.'

IF NOT EXISTS (SELECT db.owner_sid FROM sys.databases db WHERE db.database_id = DB_ID() AND db.owner_sid = 0x01)
PRINT N'ERROR: Database owner is not sa account!'
ELSE
PRINT N'PASS: Database owner is sa account.'

IF NOT EXISTS( SELECT * FROM sys.databases db WHERE db.database_id = DB_ID() AND db.is_trustworthy_on = 1 )
PRINT N'ERROR: Trustworthy bit is not on!'
ELSE
PRINT N'PASS: Trustworthy bit is on.'

IF NOT EXISTS( SELECT * FROM sys.databases db WHERE db.database_id = DB_ID() AND db.is_broker_enabled = 1 )
PRINT N'ERROR: Service broker is not enabled!'
ELSE
PRINT N'PASS: Service broker is enabled.'

IF NOT EXISTS( SELECT * FROM sys.databases db WHERE db.database_id = DB_ID() AND db.is_honor_broker_priority_on = 1 )
PRINT N'ERROR: Service broker priority is not set!'
ELSE
PRINT N'PASS: Service broker priority is set.'

PRINT N'Done!'

Branch_Exit:

That script is dead handy!

We’re looking for INFO and PASS only

INFO: Targetted database is CM_CTP.
INFO: Running verifications....
PASS: CLR is enabled.
PASS: Max text repl size is correct.
PASS: Database owner is sa account.
PASS: Trustworthy bit is on.
PASS: Service broker is enabled.
PASS: Service broker priority is set.
Done!

Configure SQL Security for Primary Site server

We’re going to recreate the SQL login for the site server to use, this will have been lost as SQL Engine logins are not backed up when you backup a database, the SQL logins are present in the database but not on the new SQL server.

• Expand CMSQLAONA, Security and right click Logins, now select New Login…

My Primary’s hostname is CMCBTP so I’ll create the new login as its computer account

• Select Server Roles

• Make sure public is ticked, it should be by default
  
  
• I added sysadmin as I was troubleshooting on the first go around setting up a Availability Group, the site server doesn’t need these rights, but the account you are logged in as when working through this guide must have sysadmin rights
  
  
• Select OK
  
  
• Expand CMSQLAONB, Security and right click Logins, now select New Login…

Again use the Primary’s site servers hostname, CMCBTP$

• Make sure public is ticked

• Select OK

Enable SQL AlwaysOn Feature

Next up is enabling the SQL AlwaysOn feature on all three Replicas. This feature will not light up until a replica is a member of a Windows Server Failover Cluster.

• From CMSQLAONA open SQL Server Configuration Manager

• Select SQL Server Services, right click SQL Server (MSSQLSERVER) and select Properties
  
  
• Now visit the AlwaysOn High Availability tab
  
  
• Select Enable AlwaysOn Availability Groups

• Select OK
  
  
• Restart the SQL Server service for the change to take effect, as it warned you. You can restart the service inside the Configuration Manager console, right click SQL Server (MSSQLSERVER) and select Restart

Note: The AlwaysOn feature would not light up and be greyed out, if this server wasn’t a node in a Windows Cluster, didn’t I just say that? It is worth repeating!

• Perform this step on each of the remaining replicas CMSQLAONB and CMSQLAONC

Create a Network Share to facilitate the transfer of the site database CM_CTP to all Availability Group Replicas

When we create the Availability Group we need to somehow get the site database copied across to all remaining replicas, CMSQLAONB and CMSQLAONC. Well we can do this manually or we can let SQL do it for us using a file share.

I created this file share on CMSQLAONA, as this is a bridgehead for doing all the SQL administrative work so far, let’s create it here.

• Open File Explorer
  
  
• Create a new folder on CMSQLAONA called C:\CMDBTransfer
  
  
• Share the folder out

• Give the Full Control share permissions to Everyone

• Select OK
  
  
• Right click the CMDBTransfer folder, select Properties and then the Security tab
  
  
• Set the ACL’s so that the SQL Account YourDomain\CMClusterService has full permissions

• Select OK
  

Create a SQL AlwaysOn Availability Group

Good to create the Availability Group now. We’ll begin the creation of the Availability Group on CMSQLAONA.

• Return to SQL Management Studio
  
  
• Navigate to CMSQLAONA
  
  
• Right click AlwaysOn High Availability

• Select New Availability Group Wizard…

• Have a read
  
  
• Select Next

• We’ll now name our Availability Group as ConfigMgrAG
  
  
• You could call it whatever you want, if you change it keep an eye out for references to ConfigMgrAG fruther into the guide, and substitute for whatever you chose
  
  
• Select Next

• It see’s our database, select it
  
  

Note: When I first took my ConfigMgr Tech Preview site database from a local install into the first availability group lab that I created, the text in this dialog was different, some actions where needed, and size of DB was mentioned, as well as results of a prerequisite check. I might move my ConfigMgr Current branch into an Availability Group, which means I’ll see this wizard again, return here and amend for the differences. In the meantime you might need to wing this section a bit, by doing whatever the prerequisite checker asks of you

• Select Next

We are now going to add in the Replicas that will participate in the Availability Group, that’ll be all three cluster nodes CMSQLAONA, CMSQLAONB and CMSQLAONC

• Select Add Replica…

• Enter CMSQLAONB and select Connect

• Select Add Replica…
  
  
• Enter CMSQLAONB and select Connect

• Note that CMSQLAONA is listed as a Primary Replica, and CMSQLAONB and CMSQLAONB are listed as Secondary Replica’s
  
  
• For CMSQLAONA tick Automatic Failover (Up to 3), tick Synchronous Commit (Up to 3) and select Yes for Readable Secondary
  
  
• For CMSQLAONB tick Automatic Failover (Up to 3), tick Synchronous Commit (Up to 3) and select Yes for Readable Secondary
  
  
• For CMSQLAONC, which we’ll use to enable the Technical Preview Build 1705 feature for AlwaysOn, Asynchronous Availability Group replica support, untick Automatic Failover (Up to 3), untick Synchronous Commit (Up to 3) and select Yes for Readable Secondary

• Select the Listener tab

• Select Create an availability group listener
  
  

Note: The Listener is actually a DNS record that will be used by Applications when they attempt to connect to the Availability Group, earlier in the guide I called out a link on tooling up knowledge-wise on what a Listener is, so I’ll forgo being an echo-chamber and repeat what you already knew or just learnt.

• Enter ConfigMgrAGL as the listener DNS name
  
  
• Enter 1433 as the Port
  
  
• Enter an IP address for the listener to use, I used 192.168.1.173 for ConfigMgrAGL
  
  
• If you build further Availability Groups, they will have their own unique listener, much like a Cluster Name (interface!)
  
  
• Select Next

The site database needs to be transferred to the other two Replica in the Availability Group, SQL can automatically do this for us, with that share we created, or we can handle it manually ourselves. Guess which method we’re opting for!

• Select Full
  
  
• Enter the full path to the CMDBTransfer share you created earlier(\\CMSQLAONA\CMDBTransfer)
  
  
• Select Next

• And all the ducks line up
  
  
• Select Next

• Select Finish to get things underway

• Time for more tea

• More tea

• Great we’re done here
  
  
• Visit your DNS server and you’ll see a new A record has been created for your new Availability Group ConfigMgrAGL

• From CMSQLAONA visit the SQL Management Studio
  
  
• Expand out CMSQLAONA and the Availability Group nodes

• You did that :-)
  
  
• I am assuming it all worked out, well done!
  
  
• Let’s see if its really working, bring up the Dashboard, a right click off the Availability Node

• Select Show Dashboard

• Click on ConfigMgrAG to drill down

• If you are not seeing Green you’ve derailed somewhere, not very helpful of me but I would recommend reading any critical or warning messages it produces, take it from there
  
  
• Note that you can administer most of the Availability Group from here, a primary to note is that you launch the failover wizard from the dashboard but can launch it from a right click on your Availability Group in Object Explorer

Final SQL Configurations

The site database now residing on CMSQLAONB was transferred there using SQL Backup and Restore, which means that some database settings haven’t been carried across. These need to be set, or normalised, but we cannot straight connect and configure, we need to tell the Availability Group to failover to that replica then perform the tasks. So let’s get on with that

• From SQL Management Studio right click your Availability Group, you can do this from any of the Replica nodes but the assumption for this guide is that CMSQLAONA is your Primary instance, and the others replicas are Secondary Replicas, so do your right click from CMSQLAONA

• Select Next

• Tick CMSQLAONB which should be the nominated Replica for Failover
  
  
• Select Next

• Select Connect

• It won’t let you interact other than with the buttons, select Connect

• Select Next

• Select Next

• Select Close
  
  
• You’ll see the dashboard show critical, leave it alone for a few moments, it auto refreshes, proceed when it returns to a healthy state
  
  
• Notice our Primary instance is now CMSQLAONB

• Select CMSQLAONB in the Object Explorer then select New Query:

Use CM_CTP;

EXECsp_changedbowner'sa'

USE CM_CTP;

ALTERDATABASE CM_CTP SETTRUSTWORTHYON;

Use CM_CTP;

ALTERDATABASE CM_CTP SET HONOR_BROKER_PRIORITY ON;

• Execute that lot on CMSQLAONB

• I did not have to set ENABLE_BROKER in my lab, so I've pulled the following step as not required:

Use CM_CTP;

ALTERDATABASE CM_CTP SETENABLE_BROKER;

• Rerun the following validation script:

SET NOCOUNT ON

DECLARE @dbname NVARCHAR(128)

SELECT @dbname = sd.name FROM sys.sysdatabases sd WHERE sd.dbid = DB_ID()

IF (@dbname = N'master' OR @dbname = N'model' OR @dbname = N'msdb' OR @dbname = N'tempdb' OR @dbname = N'distribution' ) BEGIN
RAISERROR(N'ERROR: Script is targetting a system database.  It should be targeting the DB you created instead.', 0, 1)
GOTO Branch_Exit;
END ELSE
PRINT N'INFO: Targetted database is ' + @dbname + N'.'

PRINT N'INFO: Running verifications....'

IF NOT EXISTS (SELECT * FROM sys.configurations c WHERE c.name = 'clr enabled' AND c.value_in_use = 1)
PRINT N'ERROR: CLR is not enabled!'
ELSE
PRINT N'PASS: CLR is enabled.'

DECLARE @repltable TABLE (
name nvarchar(max),
minimum int,
maximum int,
config_value int,
run_value int )

INSERT INTO @repltable
EXEC sp_configure 'max text repl size (B)'

IF NOT EXISTS(SELECT * from @repltable where config_value = 2147483647 and run_value = 2147483647 )
PRINT N'ERROR: Max text repl size is not correct!'
ELSE
PRINT N'PASS: Max text repl size is correct.'

IF NOT EXISTS (SELECT db.owner_sid FROM sys.databases db WHERE db.database_id = DB_ID() AND db.owner_sid = 0x01)
PRINT N'ERROR: Database owner is not sa account!'
ELSE
PRINT N'PASS: Database owner is sa account.'

IF NOT EXISTS( SELECT * FROM sys.databases db WHERE db.database_id = DB_ID() AND db.is_trustworthy_on = 1 )
PRINT N'ERROR: Trustworthy bit is not on!'
ELSE
PRINT N'PASS: Trustworthy bit is on.'

IF NOT EXISTS( SELECT * FROM sys.databases db WHERE db.database_id = DB_ID() AND db.is_broker_enabled = 1 )
PRINT N'ERROR: Service broker is not enabled!'
ELSE
PRINT N'PASS: Service broker is enabled.'

IF NOT EXISTS( SELECT * FROM sys.databases db WHERE db.database_id = DB_ID() AND db.is_honor_broker_priority_on = 1 )
PRINT N'ERROR: Service broker priority is not set!'
ELSE
PRINT N'PASS: Service broker priority is set.'

PRINT N'Done!'

Branch_Exit:

• Again we’re looking for INFO and PASS only:

INFO: Targetted database is CM_CTP.
INFO: Running verifications....
PASS: CLR is enabled.
PASS: Max text repl size is correct.
PASS: Database owner is sa account.
PASS: Trustworthy bit is on.
PASS: Service broker is enabled.
PASS: Service broker priority is set.
Done!

That’s it, use the failover wizard to switch back to the CMSQLAONA replica node as the Primary instance

Set the SQL SPN’s

While we’re running SQL with a domain user account we’re going nowhere at the application layer (ConfigMgr) without Service Principal Names (SPN’s). We’ll create them by hand.

• RDP to your Domain Controller or wherever you are hosting Microsoft DNS
  
  
• Open ADSIEDIT
  
  
• Navigate down to Users and find the CN-CMClusterService entry

• Double click it or select Edit
  
  
• Add in the following SPN entries so that ConfigMgr can find the SQL Service:
  
  

MSSQLSvc/CMSQLAONA:1433

MSSQLSvc/CMSQLAONA.SMSM.COM:1433

MSSQLSvc/CMSQLAONB:1433

MSSQLSvc/CMSQLAONB.SMSM.COM:1433

MSSQLSvc/CMSQLAONC:1433

MSSQLSvc/CMSQLAONC.SMSM.COM:1433

• We only need the CMSQLAONA and CMSQLAONB entries, since they are the active replicas in synchronous mode that ConfigMgr will use, but we’ll add CMSQLAONC so that you can play around with changing the roles in the Availability Group
  
  
• Select OK

• Select OK

Configure the Availability Group for Maintenance Mode (failover = Manual)

Before we can let ConfigMgr take a look at the new Availability Group we need to set it to Manual Failover mode. Perhaps in the future we’ll be able to work on Availability Groups without having to put them into manual mode, which would be every single time you service the ConfigMgr product, as is the case with Management Point Replicas which need to literally brought down before you can upgrade. I’d like to see these two areas ironed out to reduce administrator burden from lighting up cool features.

• Return to CMSQLAONA and to the SQL Management Studio
  
  
• Select CMSQLAONA which should be the Primary instance, check the Dashboard to confirm
  
  
• Right click your Availability Group and select Properties

• Set the Failover mode for CMSQLAONA and CMSQLAONB to Manual

• You have to do this on the Primary instance, which means the correct SQL server, as I said the dashboard lets you know which Replica is the Primary instance.

• You can see the Failover mode in the Dashboard

• Once they are set to Manual you are good to move onto configuring ConfigMgr

Configure ConfigMgr to use the SQL AlwaysOn Availability Group

We can now turn to ConfigMgr and ask it politely to start using our new Availability Group.

• Launch ConfigMgr Setup from the installation folder, not the installation media. Run C:\Program Files\Microsoft Configuration Manager\bin\X64\Setup.exe and select Run as administrator

• Select Next

• Select Perform site maintenance or reset this site

• Select Modify SQL Server configuration

• Enter the Availability group Listener FQDN for your ConfigMgrAG Availability Group
  
  
• Select Next

• It’ll detect the SQL AlwaysOn Availability Group and thrown a warning before you proceed
  
  
• Select Begin
  
  
• Open the ConfigMgrSetup log using LogLauncher
  
  
• Keep an eye on that log and pray!
  
  
• Once it is done you’ll get green in the configuration wizard

• You’ll also see happiness in the log, tailing off with the following

• If you are seeing SSPI errors review your SPN work, most likely related, other issues could be connectivity, not enough account permissions, some steps missed
  
  
• Go check out SMSDBMON on your Primary, it’ll show you DB activity, if there is a problem it’ll show there

Reconfigure Availability Group Failover mode

We’ve now got ConfigMgr pointing at the Availability Group, we can now return the Failover Mode to Automatic.

• Return to CMSQLAONA and to the SQL Management Studio
  
  
• Select CMSQLAONA which should be the Primary instance, check the Dashboard to confirm
  
  
• Right click your Availability Group and select Properties

• Set the Failover mode for CMSQLAONA and CMSQLAONB to Automatic
  
  
• Select OK

Reporting Point

If you had one running its most likely pointing at the old SQL Database that was home for the site database, that’ll be all ugly and broken now, so remove the Reporting Point role, add the role back, when configuring the role use the Availability Group Listener. The SRSRP log should show that the data sources have been updated with the Availability Group Listener name.

If your going to edit reports you’ll need the latest Report Builder V3, which you can find here

WSUS

Forget it. It’s unsupported.

Are there any options?

Yes, read here, it has everything to do with WSUS trying to be a bad boy and putting the SUSDB database into single-user mode, which an Availability Group won’t have any of. As you’ll see in this guide, its just a matter of procedure, and you can have WSUS running its database in an Availability Group, not the one being used by ConfigMgr, a new one dedicated for WSUS usage.

A great source of information alongside the SQL Documentation library came from here Prepare to use SQL Server Always On availability groups with Configuration Manager, which takes you to the ConfigMgr Documentation library, a world-class documentation library.

Another source very worthy of a mention is this article from Benjamin Reynolds at Microsoft titled Moving the ConfigMgr site database to an Always On Availability Group, he writes up on how to do what I do above, but he does it to a production database while minimising down time. You’ll find both articles complement each other in that Benjamin skips over some aspects whereas I document their steps. Using both you can build out your lab and put together an ace plan to do a production run at some point.

There are quite a few cool features in the Build 1702 release of System Center Configuration Manager Current Branch, the one I’m going to go over here is the feature that gives Software Update Points Boundary Group-awareness, or boundary affinity.

This complements the already boundary group-aware Distribution Point, Management Point and State Migration Point roles, and with this introduction, we finally have usage control over all the content roles.

In a flat and well-connected environment with multiple Software Update Points, or in an Azure based environment, which SUP a device anywhere in the Hierarchy uses doesn’t really matter, the only real consideration is that if a SUP goes down, a surge in network traffic will take place, caused when devices attempt to synchronise with a new SUP, and if multiplied across devices that switch roughly at the same time, and are in a remote office behind a slow link, that surge can be huge and disruptive.

When a device synchronises with a SUP, the payload can vary from 20MB to 200MB, with the variance being due to a dynamic scan being performed between the ConfigMgr Agent and the Software Update Point (with Windows Update Agent (WUA) and Windows Server Update Services (WSUS) underpinning both), where the OS and other information is sent to WSUS  which sits underneath the SUP, and a customised payload is returned to the device for it to use for patch scanning. This strips out the OS patches that are not needed and thus makes the payload variable. The cost of switching between SUP’s depends on the amount of applicable-to-the-device patches in the database, and if the SUP that is selected for use shares SQL with the previously used SUP (Delta sync), or if a different SQL is used by each of them (Full sync).

A good example of the hazards of a population switching to another SUP would be if you had a Secondary Site server, and the SUP went offline. This would cause the devices using the SUP on the secondary to switch to one of the Parent Primary Sites SUP’s. This effect I’ve heard referred too as “Jumping the gate”, as in unexpectedly crossing the WAN link and causing network congestion, which is often the reason why you would deploy a Secondary in the first place, so as to benefit from compression taking place between the sites and offloading of roles from the Primary, which reduces resource (Disk, Memory, CPU) and network utilisation. There isn’t any resiliency with this design approach because your Secondary can only have one SUP, and if that fails, you literally depend on your network fabric stopping the connections on the device-side of the WAN link, or your WAN link will take a hit from the resync traffic.

There are other examples of when total SUP control would be a boon, such as a SUP located in a DMZ. If the SUP goes offline devices will try to reach across to other remote SUP’s, but in most cases port 8530\8531 will be blocked by the router handling traffic for the DMZ, so as to stop any outflow across the network, which actually introduces one of a few problems you’ll encounter while trying to manage SUP selection, and which we’ve used edits to the WSUS Scan Retry Error Code list that the ConfigMgr Site Control File contains to overcome, which is tweaked and delivered to all devices using a manual one-time technique performed at the Primary Site server. If that doesn’t work your final throw of the dice would be to configure how the router responds to requests to access an endpoint (a remote SUP), the response of the router influences how the Windows Update Agent responds, and if WUA thinks the error response is a recoverable error it will wait for service to return, and literally stick to the wrong SUP. Configuring the router to deny the socket requests rather than dropping them often helps devices to throw an error code that can be added to the Scan Retry Error Code list, so that WUA gives up trying to connect to a SUP it’ll never be able to speak too.

Those days are behind us with Build 1702 available, now we can forget about micro-managing the SUP selection problems, and let the Hierarchy take care of it using Boundary Groups. You can literally drop a down-level SUP into a part of the network and be highly selective about who uses it, and whether it can be fallen back too, we couldn’t before with any ease. We can now rethink how we’ve designed for SUP usage with existing ConfigMgr designs.

Right off it is worth noting that the Software Update Point affinity feature is always-on (see below for explanation), unlike Management Point affinity which can be toggled as seen below in Hierarchy Settings:

It is pretty easy to test SUP affinity in a simple lab setup. You’ll need to service ConfigMgr and install Build 1702, resulting in the following versions (or higher):

• ConfigMgr Site version for 1702 5.0.8498.1000 (Console Version 5.00.8498.1500)
• Client version 5.00.8498.1007 are needed before the functionality can be used.

Your lab will have to have at least the following to test the SUP Affinity feature:

• Build 1702 Primary Site server (MP\Active SUP)
  
• Build 1702 Site system (MP\Down-level SUP)
  
• ConfigMgr supported Windows OS with Build 1702 Client to test the Software Update  Point selection
  
• Three IP Range boundaries, used to split up a single IP Subnet
  
• Two Boundary Groups
  
• A Grin for when you see how much control you have over a SUP now!

Here are the three Boundaries:

These IP Range Boundaries let us single out an IP Address (192.168.1.126) that will be used for our tests to switch between using the Site server, and the Site system, and back to the Site server. You could extend this range out to include more than one IP address but obviously edit the other two to accommodate the change.

We then create two Boundary Groups, SiteServer (Active SUP) and SiteSystem (Down-level SUP):

You can see that the Default-Site-Boundary-Group boundary group is also listed in the shot above, it is worth noting that when upgrading to Build 1702 you’ll find all the Site’s Software Update Points have been added there during the upgrade, this is to emulate existing functionality of pooled SUP’s with non-deterministic selection and is why you don’t have a check box for this feature in Hierarchy Settings as you do for the Management Point role. If you design to include usage of this boundary group, consider what functionality you want from the SUP’s in terms of fallback selection. For the lab I removed all the references so that there is no fallback available.

This is worth noting from the documentation, describing exactly how the SUP will  handle a fail-over:

When a client that already has a software update point fails to reach it, the client can then fallback to find another. When using fallback, the client receives a list of all software update points from its current boundary group. If it fails to find an available server for 120 minutes, it will then fallback to its neighbor boundary groups and the default site boundary group. Fallback to both boundary groups happens at the same time because the software update points fallback time to neighbor groups is set to 120 minutes and cannot be changed. 120 minutes is also the default period used for fallback to the default site boundary group. When a client falls back to both a neighbor and default site boundary group, the client attempts to contact software update points from the neighbor boundary group before trying to use one from the default site boundary group.

So a device will hang around trying to find a SUP for 120 minutes before trying a neighbour and the fallback boundary groups, with a preference for the neighbours SUPs. A non-editable timeout of 120 minutes, for design purposes this influences how you configure for fallback and needs to be factored into a design.

The documentation also refers to existing devices, and states the following:

The continued use of an existing software update point even when that server is not in the client’s current boundary group is intentional. This is because a change of software update point can result in a large use of network bandwidth as the client synchronizes data with the new software update point. The delay in transition can help to avoid saturating your network should all your clients switch to a new software update point at the same time.

The feature owners at Microsoft decided to be cautious, and try not to cause any heavy network utilisation just from upgrading the Hierarchy to 1702. If you leave all SUP’s in the fallback boundary group post-upgrade, no devices will switch to another SUP and perform a delta or full resync causing network congestion. This gives you control over possible network surges straight off the bat, nice, giving you ample time to plan out your boundary groups for SUP usage and perform the transitioning.

Once you have upgraded to Build 1702, and implemented your planned changes to the boundary groups and their SUP references, to effect a switch to the SUP’s referenced in Boundary Groups the device is a member of, you can do one of the following:

• New installation or reinstallation of the existing ConfigMgr Client, noting that OSD builds will honour boundary group based SUP selection as New installations
  
• Send down a request to existing ConfigMgr Clients using the Notification Channels Switch to next Software Update Point action which will be honoured when the next Scan Cycle is initiated by deployment, schedule or manually (Automation)

Okay so the whole “Controlling SUP’s is very important” message should be truly imparted by now, let’s get on with walking through how easy SUP affinity is to control in Build 1702.

I only have one Subnet here in my lab, and to isolate a single device on that subnet for testing I used IP Range boundaries, splitting a single subnet on the last octet into three distinct boundaries:

• 1 to 125
  
• 126 <—Test device IP Address (192.168.1.126)
  
• 127 to 254

In the shots below you’ll see that we added the following IP Ranges to the SiteServer (Active SUP) Boundary Group:

• 192.168.1.1-192.1681.125
  
• 192.168.1.127-192.168.1.254

And then we add the following IP Ranges to the SiteSystem (Down-level SUP) Boundary Group:

• 192.168.1.126-192.168.1.126

This is how it looks once setup:

SiteServer (Active SUP)

Any IP Address within the defined IP Ranges above, will use the Active SUP:

SiteSystem (Down-level SUP)

The single IP Address defined above, will use the Down-level SUP:

I built a Windows 10 Build 1607 Virtual Machine and installed the ConfigMgr agent there, giving the machine the 192.168.1.126 IP address so that it will become the SUP test device and use the down-level SUP:

This device is now a member of the SiteSystem (Down-level SUP) Boundary Group. This Boundary Group as we know contains a reference to the down-level SUP, so eventually the device will receive a list containing just one entry, the down-level SUP.

We can determine which SUP is going to be used for a scan by looking at the ScanAgent log on the device, in the shot below we have a device which is using the Active SUP, whereas we have configured so that it uses the down-level SUP:

We know from the documentation that the device will not switch all the while its current SUP is healthy, even if the SUP in the Boundary Group is different than the one it is currently using, so we have to do something to induce this behaviour. Luckily, the Product Group, who mentioned this to me, have built in a way to carry out this task from the Console, using the Notification Channels Switch to next Software Update point action.

We issue the Switch to next Software Update Point Client Notification Action, and we can see its delivery if we open up the CcmNotificationAgent log on the device:

We see the GUID and tasktype entry show up, but the device will not perform a switch until it performs its next Scan Cycle.

This Client Notification also reflected in the ScanAgent log on the device:

Once we kick off a Scan cycle manually, we see the actual switching take place in the ScanAgent log, but note that you don’t have to initiate the scan cycle to complete the procedure, since the next time a scan is induced via a deployment or on schedule, the switch will take place then:

And we see the same in the WUAHandler log:

Perfect. The test device has moved to the correct SUP, the down-level one, as desired.

Using this technique the entire device estate could be moved to nominated SUP’s with minimal ease, while remaining totally in control.

To test the feature out further:

• Swap the references around in the two boundary groups
  
• Initiate the Client Notification Action followed by a Scan cycle
  
• Observe the device switching back to the Active SUP
  
• Repeat these steps to switch back to the down-level SUP

The final thing worth mentioning is that if you have a Site system that hosts a combination of a Distribution Point, a Management Point or a Software Update Point, and you wish to separate the roles out between different Boundary Groups, you’re going to need to do this at the Site system level. This is because Boundary Group references do not refer to the role, but to the site system hosting the role. That’d make for a good User Voice suggestion, to atomise the bounding beyond Site systems and into Roles.

A long overdue feature for ConfigMgr, and now that it is here the old story about not being able to control usage for the core roles can be put to bed. With MP, DP, SUP and SMP affinity, it’ll make for more optimised hierarchy designs. A real bonus for those of us that get a kick out of designing complex hierarchies.

Thanks and big props to the Product Group!

Things turn over so rapidly now, it would seem, and as we iterate forwards with new releases of ConfigMgr using the Servicing channel, we suddenly get hit with an announcement that support for something important or at least popular has been dropped, making us feel that things are moving too quickly, after a pace that hasn’t changed much for a decade.

The following comes from the What’s new in Version 1702 documentation on the Microsoft website:

• SQL Server 2008 R2, for site database servers. Deprecation of support was first announced on July 10, 2015. This version of SQL Server remains supported when you use a Configuration Manager version prior to version 1702.
  
• Windows Server 2008 R2, for site system servers and most site system roles. Deprecation of support was first announced on July 10, 2015. This version of Windows remains supported when you use a Configuration Manager version prior to version 1702.
  
• Windows Server 2008, for site system servers and most site system roles. Deprecation of support was first announced on July 10, 2015.
  
• Windows XP Embedded, as a client operating system. Deprecation was first announced on July 10, 2015. This version of Windows remains supported when you use a Configuration Manager version prior to version 1702.

One of the more popular legacy Microsoft Windows Server Operating Systems out there has to be Windows Server 2008 R2 !

I know a lot of folks rolled the dice when Server 2003 was taken out of support and put to pasture, and that they did a quick jump to Server 2008 R2, either due to licensing or timing, instead of getting up to at least server 2012.

Well, the time has come to stop putting it off, if you want to upgrade and continue benefiting from the feature growth of the ConfigMgr product in the form of Build 1702, you are going to have to do an in-place upgrade of the OS, or backup\restore ConfigMgr onto at least Server 2012 and possibly upgrade your SQL version.

The lesser burden is for those running SQL Server 2008 R2, you are going to have to upgrade to at least SQL 2012.

If I am honest, handling the above two upgrades isn’t that big a deal, it just requires a bit of reading, web searches and planning before its undertaken. The really important announcement for deprecated features for Build 1702 is Windows XP Embedded, as these are running on devices with massive penalties for storage space and OS upgrade restrictions due to the software they run, and are not as easy to deal with.

For customers running embedded devices using Windows XP Embedded, upgrading will depend on the vendor of the hardware and software, and if the device can handle at least XP Embedded SP3, which ultimately should really just be about whether the devices running it have enough storage and the LOB software can handle the upgrade, otherwise upgrading to SP 3 won’t be that difficult to deal with, so as to upgrade to Build 1702.

I see these devices mostly in retail and banking, and it is costly for them to be replaced, they are not seen the same way as a PC, which can be recycled after a handful of years, Embedded devices are often an investment that the customer wants to get the last out of.

However, it may be time to take a look at these legacy Windows XP Embedded devices, and finally try to get them rid of them, as support won’t last for more than a few more years by the look of how things are panning out, not from some inside information that I have as an MVP, just how time trots on, licensing changes, and new hardware comes out, and replacing them will replace a lot of time and motion, better to start it now.

Join WMUG for a day of Windows 10 and Azure Cloud

Friday the 21st of April 2017

This event will be held at a different location than normal, at the Hotel Xenia

Hotel Xenia

160 Cromwell Road

London SW5 0TL, UK

Sponsored by the Mac Management specialists Parallels

Featuring three (3) Microsoft MVP's, Robert Marshall (EM) and Gerry Hampson (EM) and Sam Erskine (CDM), alongside the most excellent WMUG team, guest speakers and our event sponsor, Parallels

The agenda will be as follows:

The event is completely FREE to you including refreshments and lunch, courtesy of our sponsor for the 

Please note that registrants Name and Email address will be provided to the Sponsor, please do let us know if this is an issue for you. We view providing your details as a small token of gratitude towards the Sponsor, which enables the event to be free.

To register click the REGISTER button on this page and proceed to enter your details. We thrive on attendance, so only register if you can make it!

Was onsite with a customer recently, and had failure trying to upgrade their Build 1610 Current Branch Hierarchy to Build 1702.

The problem was being reported in the SMS_DMP_Downloader log as follows:

• Download redist for update 0fb0a697-662d-45c2-a96c-8c95e5944df7      SMS_DMP_DOWNLOADER       05-Apr-17 12:42:14 PM                 19500 (0x4C2C)
• ERROR: Failed to download redist for 0fb0a697-662d-45c2-a96c-8c95e5944df7 with command  /RedistUrl http://go.microsoft.com/fwlink/?LinkID=841450 /LnManifestUrl http://go.microsoft.com/fwlink/?LinkID=841442 /RedistVersion 201702 /NoUI  "\\#########\EasySetupPayload\0fb0a697-662d-45c2-a96c-8c95e5944df7\redist" .              
• SMS_DMP_DOWNLOADER       05-Apr-17 12:43:42 PM               19500 (0x4C2C)
  Failed to download redist for 0fb0a697-662d-45c2-a96c-8c95e5944df7.  SMS_DMP_DOWNLOADER       05-Apr-17 12:43:42 PM                 19500 (0x4C2C)

If you follow the links you’ll end up downloading CAB files, these are not the files that the downloader is having trouble with, there is further details being logged in the ConfigMgrSetup log, which will indicates the file or files the downloader is failing to download or hash verify.

The CAB files referenced in SMS_DMP_DOWNLOADER contain the metadata for all the files that need to be downloaded for setup to commence, which includes the filename, file size, and a hash so that the files can be hash verified once downloaded, and once verified they are stored away in readiness for use during the upgrade, or discarded and an error thrown.

So if you are experiencing failure in this area, you are either experiencing a denial to download most likely caused by Proxy settings, noting that SMS_DMP_DOWNLOADER is running in SYSTEM context and not USER context, or you are experiencing a hash verification issue due to a corrupted download or simply failure to hash. There could be other variants I’ve not listed, but to date this is all I’ve seen.

Fixing a Proxy settings is a cinch, and if that is your problem then you should be able to fix it up quickly and skip over the rest of this post, and get your upgrade underway.

The release notes for Current Branch detail this issue, and provide a workaround: https://docs.microsoft.com/en-us/sccm/core/servers/deploy/install/release-notes

The suggested workaround is to tweak the Software Publishing registry value which resides in the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers registry path.

This value corresponds to the Internet Explorer security setting Check for publisher’s certificate Revocation and Check for signatures on downloaded programs, as noted here, with a bit of a deep dive here.

I know that SMS_DMP_DOWNLOADER is running under SYSTEM context, and not the currently logged in USER, so I am unsure as to why the Registry Hive is HKCU, and not HKLM, but this is offered as a workaround and I see others have reported it helping them.

Another fix is to get the binaries being referred too in the ConfigMgrSetup log, download them yourself, or obtain from another Hierarchy that went from your build to the build you are upgrading too, and pop them into the location that the downloader is trying to store them in. Rerun the Site upgrade, and repeat if necessary until the upgrade is underway, resorting to the registry change if the hashing is failing completely. This helped me get the upgrade underway.

LogLauncher is back in the development dry-dock for a refitting, no small change indeed, as I’m adding in a feature request from Zeng (Sandy), the ability to scan as many devices as you want, and see them in the navigation tree on the left so you can hop around them removing the need to open several LogLauncher processes to accomplish the same result, something like this working code example:

Fortunately the code-base is quite modular although I realised after setting off to implement this feature, quite nested, but all in all it wasn’t that much of a hassle to get most of the feature in, 4-5 hours of keyboard bashing time.

Am a while off from finishing, there were a few things that V3.4 does that I don’t like (because I am an OCD type of guy lol!), so I’ll finish up those before V3.5 is released.

Got any features you think this tool should have? Tweet me and if it is sensible and doable, I’ll add it to the TODO list.

This is an idea of the highest order!

It deserves to get the "Most votes ever on User Voice" due to its utter brilliance!

Joking aside, quite a helpful feature if we can get it implemented.

Man up, click here, apply a vote!

User Voice: Trusted Source Locations - Complete the trusted source story

Had a customer reporting issues with client registration when devices use Management Point Replicas.

Had a look around and discovered that MP Replica’s are not processing brand new Client Registrations.

You’ll see the issue manifesting in the MP_CLIENTID log on the MP being used to perform the registration, and on the device in the ClientIDManagerStartup log where it’ll never complete the registration.

Here is an MP trying to handle the registration request:

The spGetLockState stored procedure is missing from the database, it wasn’t replicated across when the publication was created.

There are more objects missing, just waiting for the EM Product Group to confirm what is what.

I noticed that if you uninstall a client and reinstall it, this issue isn’t triggered. UPDATE:  Not so, client registration will fail entirely

Soon as I have confirmation of a workaround I’ll update this post. Right now it seems as simple as following through on looking at what spGetLockState refers too, and hunting around to see what other objects are missing, but hold off for a bit as I might get more info soon.

Click here for the follow up post

Couple weeks back I mentioned that Client Registration is broken for Management Point Replicas.

I escalated it up to the product group and the great news is that it looks likely to be fixed at the next current branch hotfix rollup for 1702, no promises there, but they are aware of it  which is good.

I also asked for a problem\solution post on TechNet or wherever it should be hosted, so that customers who have this issue can work around it quickly, however, said work if done may be beaten by the hotfix release, so the only obvious option is to wait for the hotfix to arrive.

If you didn’t know you had this issue and cannot wait for a hotfix rollup, say you need to patch new Servers using SCCM, then the good news is that you can either raise a ticket with Premier, or take a look at REPLICATEDOBJECTS on your Primary Site server, note that spGetLockState and DeploymentMutex are probably missing, insert them into that table like a boss, and then redo the publication setup and subscriptions to get things working again.

UPDATE: Update Roll-up (UR) for Current Branch 1702 has been released which fixes this issue

A complete dump of the REPLICATEDOBJECTS table used to replicate the SQL objects to a Management Point Replica when the Publication is created:

ActiveDirectoryForests MP
ActiveDirectoryForestTrusts MP
ActiveDirectoryObjectInfo MP
AppOfflineLicense MP
AutoClientUpgradeConfigs MP
AutoClientUpgradeSettings MP
BGB_Server MP
BoundaryEx MP
BoundaryGroup MP
BoundaryGroupMembers MP
BoundaryGroupRelationships MP
BoundaryGroupSiteSystem MP
CEP_CollectionPolicies MP
CEP_ServiceWindows MP
CI_ApplicationModelInfo MP
CI_AssignmentTargetedCIs MP
CI_AssignmentTargetedGroups MP
CI_CategoryInstances MP
CI_Certificates MP
CI_CIAssignments MP
CI_CICategories MP
CI_CICategories_All MP
CI_CIDocuments MP
CI_CIEULA MP
CI_CIRelationTypeMapping MP
CI_CIStatus MP
CI_ConfigurationItemContents MP
CI_ConfigurationItemRelations MP
CI_ConfigurationItemRelations_Flat MP
CI_ConfigurationItems MP
CI_ConfigurationItemsOptionalRelations MP
CI_ContentFiles MP
CI_ContentPackages MP
CI_Contents MP
CI_DocumentStore MP
CI_LocalizedProperties MP
CI_Models MP
CI_Types MP
CI_UpdateCIs MP
CI_UpdateInfo MP
CI_UpdateSources MP
ClientAgent MP
ClientAgentProperty MP
ClientAgentProperty_Value MP
ClientBaseline MP
ClientDeploymentSettings MP
ClientKeyData MP
ClientKeyDataCertExtend MP
ClientPfxCertificates MP
ClientPilotingConfigs MP
ClientSettings MP
ClientSettingsAssignments MP
ClientSettingsAssignments_L MP
CM_Certificates MP
CM_UpdatePackages MP
Collections MP
Collections_G MP
Collections_L MP
CommonMACAddresses MP
CommonSMBIOS_GUIDs MP
ContentDPMap MP
CrpRequests MP
DeploymentMutex MP
DepPolicyAssignment MP
DeviceDiscoveryTranslation MP
DeviceMPSettings MP
DistributionPoints MP
DMP_FetchAPNSCertPolicies MP
DMP_FetchAPNSCSRPolicies MP
DMP_FetchAppModelPolicies MP
DMP_FetchAuthenticationPolicy MP
DMP_FetchBrandingInfoPolicies MP
DMP_FetchClientAgentPolicies MP
DMP_FetchDCMPolicies MP
DMP_FetchDepTokenPolicy MP
DMP_FetchEnrollmentPolicy MP
DMP_FetchInventoryPolicies MP
DMP_FetchMaintenanceWindowPolicies MP
DMP_FetchMEPPolicies MP
DMP_FetchPolicyData MP
DMP_FetchWP8AppMgmtPolicy MP
DMP_GetAppOfflineLicense MP
DMP_GetDeviceActions MP
DMP_GetDeviceManagementState MP
DMP_GetDeviceSMSID MP
DMP_GetDiscoveryTranslations MP
DMP_GetMachinePolicies MP
DMP_GetMDMCICertificates MP
DMP_GetMDMCrpRequests MP
DMP_GetMDMNdesList MP
DMP_GetPackageVersion MP
DMP_GetPolicies MP
DMP_GetPolicyAssignments MP
DMP_GetPolicyUserInfo MP
DMP_GetProviderCert MP
DMP_GetSettings MP
DMP_GetSoftwareDistBody MP
DMP_GetSoftwareDistIDs MP
DPInfo MP
Drs_Signals MP
EasySetupSettings MP
EN_ClientCertificateRecords MP
EULA_Content MP
EULA_LocalizedContent MP
Feature_EC MP
Flat_Group_User_Relationship MP
fn_GetBuildNumber MP
fn_IsPassportForWorkCI MP
fn_IsTermsAndConditionsCI MP
fn_ListCIs MP
fn_ListDeploymentTypeCIs MP
Fn_localefallback MP
Fn_LocalizedCIProperties MP
fn_MIG_ClientKeyData MP
fn_SMSDefaultZero MP
fn_SplitString MP
fnConvertBinaryToBase64String MP
fnConvertBinaryToHexString MP
fnConvertLocalToUTC MP
fnConvertXmlToIndentedString MP
fnCurrentSiteVersion MP
fnCurrentSiteVersion_INT MP
fnCurrentSiteVersion_INT_TABLE MP
fnDMGetAccountID MP
fnDMGetDeviceIDBySMSID MP
fnDMGetUserIDByObjectGuid MP
fnDMGetUserIDByUniqueName MP
fnGetCertSubjectAltName MP
fnGetCertSubjectName MP
fnGetNumericIPAddress MP
fnGetParentSiteCode MP
fnGetSiteCode MP
fnGetSiteNumber MP
fnGetSiteNumberBySiteCode MP
fnGetSiteSystemName MP
fnIsOfficeContent MP
fnIsSecondary MP
fnIsSiteServerUpgradeAction MP
fnMDMCalculateHash MP
fnMP_GetBoundaryGroupsXML MP
fnSplitString MP
GetAppPackage MP
GetMPLocationForIPAddressAndADSite MP
GetMPLocationForIPSubnet MP
ImportedMachineIdentity MP
IntuneAccountInfo MP
IntuneServiceLocations MP
InventoryAction MP
InventoryClass MP
InventoryClassProperty MP
LANG_Installed MP
LANG_Installed_L MP
LastPXEAdvertisement MP
MachineIdGroupXRef MP
MDMAppPolicyMapping MP
MDMCertificates MP
MDMCIRelations MP
MDMClientIdentity MP
MDMCrpCertificates MP
MDMDeviceActionResults MP
MDMDeviceActions MP
MDMDeviceManagementStates MP
MDMNdesList MP
MDMPolicy MP
MDMPolicyAssignment MP
MDMUserApplicationState MP
MDMUserApplicationTargetingHistory MP
MDMUserPolicyAssignment MP
MIG_Client MP
MIG_SiteInfo MP
MP_BgbCheckResync MP
MP_BgbGetPushMessage MP
MP_GetAffinityForClientID MP
MP_GetAllInventoryClasses MP
MP_GetAssignedMPListForSite MP
MP_GetAssignedSite MP
MP_GetAutoClientUpgradeConfigs MP
MP_GetCertificateRequestToken MP
MP_GetCertificateRevokeStateForSMSID MP
MP_GetClientIDFromMacAddress MP
MP_GetClientIDFromSmbiosID MP
MP_GetClientIDFromWTGDeviceID MP
MP_GetClientPackageInfo MP
MP_GetComplianceServiceInfo MP
MP_GetContentCloudDPUrls MP
MP_GetContentCloudDPUrlsBGR MP
MP_GetContentDPInfo MP
MP_GetContentDPInfoProtected MP
MP_GetContentDPInfoUnprotected MP
MP_GetContentFileHash MP
MP_GetContentInformation MP
MP_GetContentWUMULocations MP
MP_GetCRPCertificates MP
MP_GetCurrentBGDPList MP
MP_GetDHAUrlList MP
MP_GetDynamicPolicyAssignments MP
MP_GetEncryptionCertificateForSMSID MP
MP_GetHINVLastUpdateTime MP
MP_GetInternetMPListForSite MP
MP_GetInventoryClassProperties MP
MP_GetListOfMPsInSite MP
MP_GetListOfMPsInSiteOSD MP
MP_GetLocalMPListForSite MP
MP_GetLocalSitesFromAssignedSite MP
MP_GetMachineIdentity MP
MP_GetMachinePolicyAssignments MP
MP_GetMigrationInfoForRestoreClient MP
MP_GetMigrationInfoUsersForRestoreClient MP
MP_GetMPListForSite MP
MP_GetMPListForSiteEx MP
MP_GetMPSitesFromAssignedSite MP
MP_GetPeerDPList MP
MP_GetPendingPackagesForBranchDP MP
MP_GetPfxCertificateList MP
MP_GetPfxThumbprintList MP
MP_GetPolicyBody MP
MP_GetPolicyBodyAfterAuthorization MP
MP_GetPortalCertificates MP
MP_GetPortalInfo MP
MP_GetProtectedDPList MP
MP_GetProtectedSMPSites MP
MP_GetProxyMPListForSite MP
MP_GetSdmDocument MP
MP_GetSecretDataRequestToken MP
MP_GetSiteInfo MP
MP_GetSiteInfoUnified MP
MP_GetSiteInfoUnifiedBGR MP
MP_GetSiteInfoUnifiedBGRWSUS MP
MP_GetStateMigAssocInfo MP
MP_GetStateMigClientInfo MP
MP_GetSuperPeerContentLocations MP
MP_GetToken MP
MP_GetUnprotectedSMPSites MP
MP_GetUserAndUserGroupPolicyAssignments MP
MP_GetUserIdentificationXml MP
MP_GetWebServcieInfo MP
MP_GetWSUSServerLocations MP
MP_GetWSUSServerLocations_WithBGR MP
MP_IsClientRegistered MP
MP_IsPolicyBodyAuthorized MP
MP_MatchDrivers MP
NBS_GetPxeAction MP
NBS_GetPxeBootAction MP
NBS_LookupDevice MP
NBS_LookupPxeDevice MP
PackageContentInfoHash MP
PendingRegistrationData MP
PfxCertificates MP
PkgPrograms MP
PkgPrograms_G MP
PkgPrograms_L MP
PkgStatus MP
PkgStatus_G MP
PkgStatus_L MP
Policy MP
PolicyAssignment MP
PortalInfo MP
ProgramOffers MP
ProgramOffers_G MP
ProgramOffers_L MP
Proxy_RoleEndpoint MP
Quar_QuarantineCIs MP
ResPolicyChange MP
ResPolicyMap MP
SC_Address MP
SC_Address_Property MP
SC_AddressType MP
SC_ClientCfg_Property MP
SC_ClientComponent MP
SC_ClientComponent_Property MP
SC_ClientConfiguration MP
SC_Component MP
SC_Component_Property MP
SC_Component_PropertyList MP
SC_Configuration MP
SC_Configuration_Property MP
SC_GlobalProperty MP
SC_GlobalProperty_Property MP
SC_Properties MP
SC_RoleType MP
SC_SiteDefinition MP
SC_SiteDefinition_Property MP
SC_SysResUse MP
SC_SysResUse_Property MP
SC_SysResUse_ServiceWindow MP
SC_UserAccount MP
SC_UserAccount_Property MP
SEDO_LockableObjectComponents MP
SEDO_LockableObjects MP
SEDO_LockableObjectTypes MP
ServerKeyData MP
SettingsPolicy MP
SiteExchangeKeys MP
Sites MP
SiteWork MP
SMS_ConfigurationData MP
SMS_ConfigurationVariables MP
SMSContentHash MP
SMSData MP
SMSPackageHash MP
SMSPackages MP
SMSPackages_G MP
SMSPackages_L MP
SoftwarePolicy MP
sp_BgbConfigSSBForRemoteService MP
sp_BgbConfigSSBForReplicaDB MP
sp_GetCertSubjectAltName MP
sp_GetCertSubjectName MP
sp_GetPublicKeyForSMSID MP
sp_GetPublicKeySMSUID MP
spAddSSBRoute MP
spCreateDBMasterKey MP
spGetCloudDPToken MP
spGetContentInfoHash MP
spGetLockState MP
spGetRandomPassword MP
spGetResourceClientState MP
spGetSiteExchangeKey MP
spUpdateMDMDeviceActionResult MP
spUpdateMDMOnPremDevicePinResetResult MP
spUpdateSSBEndPoint MP
StateMigration MP
StateMigrationAssociation MP
StateMigrationAssociationUsers MP
SuperPeerClients MP
SuperPeerContentCacheMap MP
SuperPeerContentMap MP
SuperPeers MP
SupportedPlatforms MP
SysResList MP
System_AUX_Info MP
System_DISC MP
System_IP_Address_ARR MP
System_IP_Subnets_ARR MP
System_IPv6_Prefi_ARR MP
System_MAC_Addres_ARR MP
System_Resource_N_ARR MP
System_SMS_Assign_Arr MP
System_SMS_Instal_ARR MP
System_System_Rol_ARR MP
TS_AppReferences MP
TS_References MP
TS_TaskSequence MP
TSAppPolicy MP
UnknownSystem_DISC MP
Update_SyncStatus MP
User_DISC MP
User_Group_DISC MP
User_User_Group_Name_ARR MP
UserAppModelSoftwareRequest MP
UserMachineRelation MP
UserMachineSourceRelation MP
UserMachineTypeRelation MP
v_ActiveClients MP
v_BundledConfigurationItems_All MP
v_Categories MP
v_CI_DriverHardwareIDs MP
v_CI_DriversCIs MP
v_CIAppDependenceRelations MP
v_CICategories MP
v_CICategories_All MP
v_CIContents MP
v_CIContents_All MP
v_CIEULA_LocalizedContent MP
v_CIRelation MP
v_CIRelation_All MP
v_CIRelationEx MP
v_ConfigurationItems MP
v_EULAContent MP
v_LocalizedCIProperties_SiteLoc MP
v_UpdateCIs MP
v_UpdateContents MP
vCI_AssignmentTargetedCIs MP
vCI_AssignmentTargetedGroups MP
vCIAllContents MP
vClientSettingsAssignments MP
vDistributionPoints MP
vMDMAppPolicyMapping MP
vProxy_Roles MP
vSMS_CI_GlobalConditions MP
vSMS_CIDocuments MP
vSMS_CIPlatform MP
vSMS_CIRelation MP
vSMS_CIRelation_Flat MP
vSMS_ConfigurationItems MP
vSMS_SC_Address MP
vSMS_SC_ClientComponent MP
vSMS_SC_ClientConfiguration MP
vSMS_SC_Component MP
vSMS_SC_Configuration MP
vSMS_SC_GlobalProperty MP
vSMS_SC_SiteDefinition_Properties MP
vSMS_SC_SysResUse MP
vSMS_SC_SysResUse_Properties MP
vSMS_TaskSequencePackage MP
vSMS_Valid_CM_Certificates MP
vSysResList MP
WebServiceInfo MP
WSUSServerLocations MP
XMLConfigStore MP

Join WMUG for an evening stride with Wally Mead and Gerry Hampson, through ConfigMgr and Cireson products

Monday 21st August, 2017 - 6 PM to 8:30 PM 

1 Fore Street, London, EC2Y 9DT

Sponsored by Cireson

Venue provided by WeWork

WeWork is the platform for creators. We provide the space, community and services you need to create your life’s work. To learn more send an email to joinuslondon@wework.com or call 0203 695 4926."

Featuring special guest Wally Mead, with additional presenter and host Gerry Hampson, accompanied by host Paul Winstanley

That's 3 x Microsoft Enterprise Mobility MVP's!

The event is completely free to you including refreshments

Please only book if you most definitely can make it so that others can get a fair chance at attending.

The agenda will be as follows:

• 18:00 Brief introduction from WeWork and WMUG
• 18:05 What’s New in Configuration Manager Current Branch (Wally Mead / Gerry Hampson)
• 19:05 Break 
• 19:15 Extend your Configuration Manager reach with the Cireson Portal for Configuration Manager (Wally Mead)
• 19.55 Have your Secured your Access to the Configuration Manager Console? (Wally Mead)
• 20:30 End

Presentation summaries:

• Extend your Configuration Manager reach with the Cireson Portal for Configuration Manager

If you want to provide access to Configuration Manager to more of your IT staff, but worry about given them too much power and control, or don’t want to have to spend countless hours training them on the use of the Configuration Manager Console, then the Cireson Portal for Configuration Manager is the solution for you. It is a web based experience that provides role-based control to specific features of Configuration Manager in an easy to use interface. In this session, you’ll learn what the Cireson Portal for Configuration Manager can do for your environment through slides and extensive demos.

• What’s New in Configuration Manager Current Branch

As you know, Microsoft releases a new build of Configuration Manager every few months. Are you up to date with the latest release, or are you still a few builds behind? Even if you are up to date, do you know all the new features that have been added to each build? In this session, you will learn what’s new in the product, from the original release of current branch, up to the most current one. And may even have time to talk about what the future may hold!

• Have your Secured your Access to the Configuration Manager Console?

Everyone who uses Configuration Manager knows that it has role-based access control (RBAC). However, not everyone really uses it. This means that either you take on all the responsibilities and duties for Configuration Manager yourself (or in a very small team) or you are likely providing way more power and control to those who don’t really need it. In this session, you’ll learn how to properly configure and environment through the implementation of Configuration Manager’s role-based administration features.

The Speakers:

• Wally Mead - A legend in SCCM circles, a great all-rounder presenter and MVP in Enterprise Mobility, and Cireson employee

• Paul Winstanley - Recently awarded MVP in Enterprise Management and Independent contractor with 20+ years experience. 7 years specialised in Configuration Manager and Enterprise Client Management. Also a CGJam Contributor and Pi enthusiast who regularly teaches kids in his spare time

• Gerry Hampson - Senior Consultant Engineer with Ergo Group based in Dublin. Recently awarded his first MVP in Enterprise Mobility through his awesome work on gerryhampsoncm.blogspot.ie and Microsoft TechNet forums

To register click here

* Please note that by registering you accept that your email address will be provided to Cireson and WeWork for marketing purposes

Who said that PC’s are dead. I recently bought the parts to make a custom machine, and today I finally built it.

It’s destined to act as a Hyper-V 3.0 server, so that I can run a large bunch of Virtual Machines.

Here’s the spec’s:

• Asus Rampage IV Extreme Intel X79 (Socket 2011) DDR3 Motherboard
• x2 G.Skill TridentX 64GB (4x16GB) DDR3 PC3-19200C10 2400MHz Quad Channel Kit (F3-2400C10Q-32GTX)
• Intel Core i7-3820 3.60GHz (Sandybridge-E) Socket LGA2011 Processor – Retail
• Noctua NH-D14-2011 Dual Radiator CPU Cooler with PWM Fans (Socket LGA2011)
• Corsair Professional Series AX1200 High Performance 1200W Modular '80 Plus Gold' Power Supply (CMPSU-1200AXUK)
• Fractal Design Define XL USB3.0 Full Tower Case - Titanium Grey
• x8 Seagate Barracuda 2TB 7200RPM SATA 6Gb/s 64MB Cache - OEM (ST2000DM001)
• Sapphire HD 6570 Ultimate Edition 1024MB GDDR3 PCI-Express SILENT Graphics Card
• x2 Intel 330 Series 60GB 2.5" SATA 6Gb/s Solid State Hard Drive – Retail
• LG GH24NS90 24x DVD±RW SATA ReWriter (Black) – OEM

And here’s what the Noctua NH-D14-2011 looks like:

It doesn’t come with the model obviously, but her and a review of the Noctua NH-D14-2011 can be found here

I had a real time putting this together, the Noctua NH-D14-2011 wouldn’t fit when the memory ports are fully loaded, part of the Noctua heatsink needed trimming for the right fit, here’s what I hacked off and the tool that helped me get there

Here’s some shots of the profile, showing how I butchered the radiator fins on the heat-sink before it’d sit above the ram

Honestly, don’t try this at home!

It’s currently running Windows Server 2012 RC, running the X.M.P profile which supports the speeds this RAM can run at (2400Mhz)

Great CPU temp all things considered

64GB of DDR3 2400Mhz RAM ready for duty

I used the on-board Intel Rapid Storage Technology Controller to form a RAID 10 using four of the 2TB disks.

Plenty of room for optimisation later on, external RAID controller for better disk performance, overclock that CPU (4Ghz+!) and maybe go for the Intel 6 core instead of the 4 core that’s in there, so there’s a little room for growth if I want to, but this thing is so bad ass I don’t think I’ll upgrade it for a long time!

Thought I’d give one of the new features in ConfigMgr Technical Preview build 1705 called Improvements for SQL Server Always On Availability Groupsa walk through, so that I could soak up all the SQL AlwaysOn Availability Group and Windows Server Failover Clustering knowledge.

From the docs:

With this release, you can now use asynchronous commit replicas in the SQL Server Always On availability groups you use with Configuration Manager. This means you can add additional replicas to your availability groups to use as off-site (remote) backups, and then use them in a disaster recovery scenario.

As it says, the reason why you’d run an Availability Group asynchronous Replica is for off-site backup, in the event that you lose your cluster fully, the asynchronous replica can be used for rapid disaster recovery.

To kick the tires on recovery would require restoring the site and loads of work, and since an asynchronous replica DB is the same but with possible data loss (the nature an asynchronous replication), it is the same process as restoring from a full cold backup, so I’ll not test it for now, instead I’ll get the feature working and leave it there.

So what does a SQL AlwaysOn Availability Group asynchronous replica mean or do.

Let’s take a step back. In an Availability Group, when a SQL transaction is to be committed to the Primary instance database it is first replicated to each Replica and committed into its database, once that is done successfully the commit at the Primary instance completes. This means the primary waits around a lot for replicas to commit the transactions being replicated to them, they need to perform well and be physically close network-wise. It makes for high integrity compared to the asynchronous replica, which the Primary instance doesn’t wait around for, it just sends transactions to it and doesn’t wait for acknowledgement, which means that some data “in transit” could be lost if an ‘event’ occurred. With Technical Preview 5 you can now restore from an asynchronous replica database as a supported scenario.

So let’s build us an Availability Group and get ConfigMgr to play ball with it.

The last time I built a cluster was NT4 days, things haven’t changed too much in terms of standing one up, so that wasn’t difficult, but I had several learning experiences around standing up SQL AlwaysOn, which I dare say helped me bottom out my knowledge on the subject.

This guide is not for production usage, you could certainly distil it into a procedure to be applied in production, instead this guide is for lab work only.

Before you can get things underway you’re going to need the following, so as to keep on the rails throughout this guide.

Media

• Operating System – Windows 2016 DataCenter with UI
• SQL Server 2016 (SP if you want, CU’s, whatever ConfigMgr supports)
• SQL Management Console (E.g. SSMS-Setup-ENU-R16.5.3-B13.0.16106.4)

Virtual Machines

1. Domain Controller
2. SQL Server Replica\Node A (192.168.1.170) – 2GB Memory – Single disk
3. SQL Server Replica\Node B (192.168.1.171) – 2GB Memory – Single disk
4. SQL Server Replica\Node C (192.168.1.172 – 2GB Memory – Single disk)
5. A pre-built ConfigMgr Technical Preview Build 1705 Site server with SQL locally installed (can be remote but heck …)

The account that you do all the action with, the one you’ll login, please make it a Domain Administrator, it’ll cut through the ‘butter’ faster, if you want to tighten down then follow the guide and analyse everything post-build.

Right then, get your cool juice and saddle up, as we’re about to ride out and get ourselves SQL AlwaysOn Availability Group  working with ConfigMgr.

Prepare the SQL Server AlwaysOn Replicas

Go ahead and stand up three virtual machines using Windows Server 2016 DataCenter with Desktop.

Once built do the following:

• Give them a name
  
  

• VM1– CMSQLAONA – 192.168.1.170
• VM2– CMSQLAONB – 192.168.1.171
• VM3– CMSQLAONA – 192.168.1.172
  
  

• Join to your Domain
  
  
• Fix their IP and make a note
  
  
• Add the Computer Account of the Technical Preview Primary Site server to the local administrator group on each replica
  
  
• Make sure all replicas have been rebooted to commit the configuration changes
  
  
• At this point I switch on Remote Access for RDP, and turn off the Windows Firewall on the Domain Profile, from there I add in the servers to RDCMan so I can move off of the Hyper-V host.

Install the Windows Failover Clustering feature

Let’s do this in one go across all three nodes.

• Fire up the PowerShell ISA, paste in the below script and let it go:

$serverList = "CMSQLAONA","CMSQLAONB","CMSQLAONC"

ForEach ($server in $serverList)
{
    Install-WindowsFeature -computername $server –Name Failover-Clustering –IncludeManagementTools
}

• After a while you’ll have the clustering feature enabled on all three nodes.

Create a Windows Cluster

We’re now going to create our Windows Cluster, this breaks down into two tasks:

1. Create a Network Share for the File Share Witness
2. Create the cluster itself.

The Network share will be used to enable a file system quorum, so that we can introduce a basic cluster into our lab.

Create a Network Share for the Quorum

I chose the Domain Controller to host this share, it is highly available to the lab. The file share witness will not handle large volumes of data, and as a result, will utilise a small footprint during its lifecycle.

• Create a new folder on the Domain Controller anywhere of your choosing, call it CMSQLAOFSW, I’ll use C:\CMSQLAOFSW
  
  
• Share the folder out, give the Full Control share permissions to Everyone
  
  

The ACL’s to this folder will be changed during the Cluster creation process, during which a domain user account representing the name you give the Cluster will be created and given Full Control permissions. The account you are installing with will need to be a Local Administrator on the Domain Controller for all this magic to happen.

• Navigate into your share by referencing it as a UNC in Start\Run, to confirm you are able to access it

Easy. You’ll be creating another share later on.

Create the Windows Cluster

Head over to CMSQLAONA and fire up the Failover Cluster Manager. Its an admin-interface based on ancient MMC technology, so do the right thing, and turn off the Action menu like a Boss!

• Right click Failover Cluster Manager in the left hand pane, then select Create Cluster

• Once the wizard fires up, click through the welcome page and add in your Cluster Nodes CMSQLAONA, CMSQLAONB and CMSQLAONC using the browse button.
  
  
• Once you have all three Nodes listed as below, then click Next
  
  
  

• Next up is testing the cluster nodes by running a set of validation steps, you don’t have to run this but I’d let it run in case there is something exotic about your environment that’ll catch you out later on

• Click Next to pass through the Before You Begin page, select Run all tests (recommended), its the default anyway, and proceed with the wizard by clicking Next

• Have a nose through the list of tests, click Next when ready to run them

• The validation test should pass if you stand the virtual machines up from the ISO’s, but scrolling down you’ll notice that it complains about redundancy for network connections in the Validate Network Communications step, which you’d resolve as part of hardening a procedure for production use, but can ignore in the lab

• You can click on View Report to see a nice HTML based report

• Let’s carry on configuring the Cluster, select Finish in the wizard

• Enter SQLAOCluster as the Cluster Name

If you are prompted to enter an IP address then a DHCP reservation was not created, most likely permissions based issue, otherwise you’ll see a dialog like this:

• Give the Cluster Name the IP of 192.168.1.174 or whatever IP you’ve set aside for you lab environment
  
  
• Select Next

• Select Next

• Note that warning about the disk witness, we’re going to use a File Share Witness (FSW) so this can be ignored
  
  
• Select Finish to wrap up
  
  
• Once the wizard has finished, RDP to your DNS server which is no doubt on your Domain Controller, and check out the new record created for the Cluster Name

• You now have a Windows Cluster, but to complete it you will need to add in the Quorum Witness. Our choice of a File Share Witness is driven by the need for simplicity, in a lab environment a disk can be shared amongst VM’s, but it takes the complexity level up a notch, fortunately we can use a SMB File Share to perform the Quorum duties, which is highly uncomplicated to setup, so let’s get it done
  
  
• Return to the Failover Cluster Manager

• Right click SQLAOCluster, select More Actions, and select Configure Cluster Quorum Settings…

• If you do not understand what a Quorum Witness is, please stop and deep dive the subject for a bit, get this foundational knowledge under your belt so as to help round off. I recommend doing this for any part of the guide that takes you out of your comfort zone, when you get that twinge its your brain prompting you to fill the gap, for Quorum Witnesses read here
  
  
• Have a read of the Before You Begin notes before you skip over
  
  

• Select Next

• Select Select the quorum witness
  
  
• Select Next

• Select Configure a file share witness, note the cool Cloud Witness as well as the classic disk witness
  
  
• Select Next

• Punch in the UNC to your File Share Witness share, you can browse to it or manually enter it. If you manually enter then here’s a top tip, always test a UNC by copy\pasting it into Start\Run to make sure you can browse it, obviously if your account doesn’t have rights this method doesn’t work, in those cases I NET USE and pass the credentials to make sure all is well
  
  
• Select Next

• Confirm and click Next

• Select Finish
  
  
• Note that Witness now changes to File Share Witness (FSW), and shows the UNC path to it

• Paste the File Share Witness UNC into Start\Run, to see the file system objects just created by the Cluster

You now have a Windows Server Failover Cluster.

Ping the Cluster Name and you will get a ping response back from the IP you specified during the setup of the Cluster Name, I keep wanting to say Cluster Interface, I think this is what we called it years ago, or perhaps it just makes more sense to my brain to call it an interface as that is what it is.

Worth noting that we won’t be using the Cluster Name at all for the SQL AlwaysOn Availability Groups. The SQL AO AG’s have their own Cluster Name concept called a Listener. You’ll come to that shortly.

Install SQL 2016 on the SQL AlwaysOn Replicas

• We’ll run SQL using a domain user account so visit your Domain Controller and create a user called CMClusterService, make note of the password, it only needs to be a Domain User, add the account to Local Administrators on all SQL nodes

If you run SQL Server using SYSTEM context you’ll need to handle the certificate transfer, I didn’t test this but saw it called out in some Microsoft SQL documentation, it might handle transferring the certificates for you, I did see a call out in some logs when creating the Availability Group that suggest certificates are being exchanged automatically between the Replicas in the Availability Group.

We’ll cookie cut the installation of CMSQLAONB and CMSQLAONC using an INI file we create from installing SQL 2016 manually on CMSQLAONA.

• Insert the SQL ISO media into the CMSQLAONA, CMSQLAONA and CMSQLAONA virtual machines
  
  
• Login to CMSQLAONA
  
  
• Run the Setup.exe on the SQL DVD Media:

• Select Installation

• Select New SQL Server stand-alone installation or add features to an existing installation
  
  
  

• Tick to accept the license terms and select Next

• Tick Use Microsoft Updates to check for updates (recommended) unless you do not have access to the Internet
  
  
• Select Next

• Select Next

• If it finds anything, let it install

• Choose Database Engine Services and keep default paths
  
  
• You could add in Reporting Services, it’ll require another account and also some special handling for the ConfigMgr Reporting Point role. I’ve skipped doing this, since I have SQL Reporting Services and its database on the Primary, along with the ConfigMgr Reporting Point role, which will point to the SQL AlwaysOn Availability Group Listener you’re about to encounter later on in the guide
  
  
• Select Next

• Select Next

• Okay so now we want to set the startup type for the Agent and Server to Automatic
  
  
• Enter the domain user account credentials (CMClusterService) you created for the SQL Cluster for both the Agent and Server services
  
  
• Select the Collation Tab (this is a highly important step)

• Select the SQL collation, used for backwards compatibility radio button, change the collation to SQL_Latin1_General_CP1_CI_AS
  
  
• Select OK

• Select OK

• Add the local Administrators group
  
  
• Add your domain account as well
  
  
• Leave Data Directories, TempDB and FILESTREAM alone
  
  
• Select Next

• Put that path into the clipboard as we’re about to automate the silent unattended installation of two SQL Servers using a modified version of it
  
  

C:\Program Files\Microsoft SQL Server\130\Setup Bootstrap\Log\20170613_143153\ConfigurationFile.ini

• Edit the file and make the following amendments:
  
  

1. False to True for IACCEPTROPENLICENSETERMS
2. False to True for QUIET
3. Put a ; semicolon character before UIMODE

• Copy the file to a newly created folder C:\SQLInstall on both CMSQLAONB and CMSQLAONC
  
  
• Now click Install to get the SQL installation underway on CMSQLAONA
  
  
• Login to CMSQLAONB and fire up a CMD prompt
  
  
• Begin the SQL installation by modifying the passwords in the command below then running it:
  
  

D:\SETUP.EXE /CONFIGURATIONFILE=”C:\SQLInstall\ConfigurationFile.ini” /IAcceptSQLServerLicenseTerms /SQLSVCPASSWORD="<PASSWORD>" /AGTSVCPASSWORD="<PASSWORD>"

• Follow through with the same unattended silent SQL installation steps on CMSQLAONC

• While those SQL installations are bubbling away, go back to CMSQLAONA, and install SQL Management Studio. Back in the day, the studio was part and parcel of the SQL Setup, they diverged into separate installs, which means the console is unlinked from the SQL setup, and can easily be updated with a smaller media footprint
  
  
• Launch the SQL Management Studio installer

• Select Install
  
  
• You can install this on one all three nodes, or just the primary one you’ll be working from, I’ll install to CMSQLAONA only, and do all administration of SQL from there
  
  
• This one can take forever, even on a fast system. Go get yourself some Tea!
  
  

• I recommend pinning the Studio to the Taskbar

Configure SQL

We now need to make some configuration changes to the SQL Server engines on all three of our SQL servers.

Set SQL Engine Memory limits

I recommend that you calculate the memory limits based on how much you added when you created the virtual machines, they can in a small environment run on as little as 1GB.

• RDP onto CMSQLAONA and open Microsoft SQL Server Management Studio using Run as administrator option
  
  
• Connect the studio to all three nodes CMSQLAONA,  CMSQLAONB and CMSQLAONC
  
  
• With the root nodes expanded it’ll look like this:
  
  

• Right click CMSQLAONA and select Properties, then select Memory
  
  

• Repeat for CMSQLAONB and CMSQLAONC

Permission all Nodes for Primary Site access

• Add the computer account of the Primary Site server to the local Administrator group on both CMSQLAONA, CMSQLAONB and CMSQLAONC
  
  
• The CMSQLAONC entry above is redundant in this lab setup, since CMSQLAONC is running in Asynchronous mode and the Primary Site will not establish a direct connection
  
  
• While you are at it, add the SQL Service account to the local administrator group on CMSQLAONB and CMSQLAONC

Bring in the CM Database

Now this is where my lab complicates things. I’ve already taken my Technical Preview 5 Primary Site towards the dark side, and its currently running its brain on a 3-node SQL AlwaysOn Availability Group. I’m going to export the DB and import it CMSQLAONA, but it means the shots will be off when it shows recovery mode.

Since my site database already resides on a SQL AlwaysOn Availability Group, it is running as FULL And not SIMPLE recovery mode. You will most likely be running SQL on the Primary, and it will most likely already be running in SIMPLE recovery mode, in this case the backup steps are the same to liberate a backup of the CM database from that SQL installation.

Take down ConfigMgr

We need to stop ConfigMgr from talking to the Database. At this point the show is over for ConfigMgr, service will resume once the Availability Group is setup and ConfigMgr told to use it.

For my lab all I need to do is wind down the services on the Primary, no site systems exist which could be connecting to the database, but its the primary that’d do the writing to the database anyway.

• RDP over to your ConfigMgr Current Branch Technical Preview 5 Site server
  
  
• Open the Services (MMC) console
  
  
• Stop the following services in this order
  
  

1. ConfigMgr Task Sequence Agent
2. Configuration Manager Remote Control
3. CONFIGURATION_MANAGER_UPDATE
4. SMS Agent Host (if installed)
5. SMS_NOTIFICATION_SERVER
6. SMS_SITE_COMPONENT_MANAGER
7. SMS_EXECUTIVE
8. SMS_SITE_SQL_BACKUP
9. SMS_SITE_VSS_WRITER

• You could use the PREINST /STOPSITE command, but that’ll mark everything for reinstallation the moment you start the services up. This isn’t necessary, since we’re going to start the site up by changing the SQL configuration from the Setup program, which’ll induce component installation behaviour
  
  
• A good working practice is to disable services when you are putting them to sleep for administrative purposes, so that if the server reboots by accident, it won’t come back up and start the application before you are ready

Backup and Move the ConfigMgr Database

I’m now going to backup the ConfigMgr CTP database (CM_CTP), and move the backup file to the CMSQLAONA node in the following location C:\SQLBackup

• Visit SQL Management Studio on the target SQL Server currently hosting your site database
  
  
• Find the site database, right click it and select Tasks and then Back Up…

• For a standalone primary with SQL locally installed, you’ll be backing up a database running in SIMPLE recovery mode, which means the file extension for your backup will be BAK and not TRN, which is the case when you are already running in FULL recovery mode
  
  
• Enter your preferred backup path location, and enter the file name as CMBackup-<CURRENTDATE>.BAK (TRN if you are moving from one SQL AlwaysOn Availability Group to another)
  
  
• Select OK
  
  
• Copy the TRN or BAK file over to a new folder called C:\CMBackup on CMSQLAONA
  

Configure the SQL Engine on all Nodes

We’ll modify the SQL Engine on all three SQL nodes before creating the Availability Group, as doing it later will require micro-managing the Availability Group, failing over between the nodes so as to configure each of them.

• RDP to CMSQLAONA and launch SQL Management Studio
  
  
• Connect to CMSQLAONA and CMSQLAONB
  
  
• Select CMSQLAONA and click New Query
  
  
• To confirm you are about to run queries against the correct node, take a look at the bottom right of the yellow status bar, it’ll show you the name of the server the query will be run against, as will the studio applications status bar:

SQL Management Studio Application Title bar:

SQL Management Studio Status Bar

• Paste this lot in and click Execute

USE Master;

GO

SP_CONFIGURE 'show advanced options', 1;

RECONFIGURE WITH OVERRIDE;

GO

EXEC SP_CONFIGURE 'max text repl size',2147483647 ;

RECONFIGURE WITH OVERRIDE;

GO

EXEC SP_CONFIGURE 'clr enabled', 1;

RECONFIGURE WITH OVERRIDE;

GO

The result should be:

Configuration option 'show advanced options' changed from 0 to 1. Run the RECONFIGURE statement to install.

Configuration option 'max text repl size (B)' changed from 65536 to 2147483647. Run the RECONFIGURE statement to install.

Configuration option 'clr enabled' changed from 0 to 1. Run the RECONFIGURE statement to install.

• Select CMSQLAONB and select New Query
  
  
• Paste the same as above and click Execute
  
  
• Select CMSQLAONC and select New Query
  
  
• Paste the same as above and click Execute

Restore the ConfigMgr Database

It’s time to restore the ConfigMgr database..

• Remain within SQL Management Studio on CMSQLAONA
  
  
• Select CMSQLAONA and right click Databases, select Restore Database…
  
  

• You’ll be presented with the Restore Database page

• Select Device and select the ellipses…
  
  
  

• Select Add
  
  
  
• Navigate to C:\CMBackup and select the CMBackup file

• Select OK

• Select OK

• You can click on Files and you’ll see it is going to restore the Database to the default SQL locations:

• Select OK to get on with the recovery of CM_CTP

Configure SQL Database CM_CTP

Next up is more SQL configuration, but this time not the SQL Engine but the site database.

For this series of steps, you’ll stay on CMSQLAONA and inside SQL Management Studio, and you will change the database name used in the steps to whatever you called your site database, mine is called CM_CTP.

• Select CMSQLAONA and then select New Query, copy\paste the below SQL code snippets and execute each time

Change Recovery Model from SIMPLE to FULL

Use CM_CTP;

ALTERDATABASECM_CTPSETRECOVERYFULL;

Take stock and contemplate how you’re going to handle SQL Transaction Logs now that you’ll be in FULL recovery mode, and how they mass up on you consuming disk space, and regularly need backing up. I’m going to totally leave you hanging, and let you read up on how to handle this.

Set SA owner on DB

UseCM_CTP;

EXECsp_changedbowner'sa'

Set TRUSTWORTHY bit on DB

USECM_CTP;

ALTERDATABASECM_CTPSETTRUSTWORTHYON;

Enable SERVICEBROKER on DB

UseCM_CTP;

ALTERDATABASECM_CTPSETENABLE_BROKER;

Enable SERVICEBROKERPRIORITY on DB

UseCM_CTP;

ALTERDATABASECM_CTPSET HONOR_BROKER_PRIORITY ON;

You can verify the configuration of SQL by running the following SQL script which is taken from the ConfigMgr Documentation:

Note: You can paste this into your existing query window or create a new one making sure you are focused on the correct SQL server, select what you paste in and then click Execute to execute the selection (change the USE CM_CTP to your database name)

USE CM_CTP

SET NOCOUNT ON

DECLARE @dbname NVARCHAR(128)

SELECT @dbname = sd.name FROM sys.sysdatabases sd WHERE sd.dbid = DB_ID()

IF (@dbname = N'master' OR @dbname = N'model' OR @dbname = N'msdb' OR @dbname = N'tempdb' OR @dbname = N'distribution' ) BEGIN
RAISERROR(N'ERROR: Script is targetting a system database.  It should be targeting the DB you created instead.', 0, 1)
GOTO Branch_Exit;
END ELSE
PRINT N'INFO: Targetted database is ' + @dbname + N'.'

PRINT N'INFO: Running verifications....'

IF NOT EXISTS (SELECT * FROM sys.configurations c WHERE c.name = 'clr enabled' AND c.value_in_use = 1)
PRINT N'ERROR: CLR is not enabled!'
ELSE
PRINT N'PASS: CLR is enabled.'

DECLARE @repltable TABLE (
name nvarchar(max),
minimum int,
maximum int,
config_value int,
run_value int )

INSERT INTO @repltable
EXEC sp_configure 'max text repl size (B)'

IF NOT EXISTS(SELECT * from @repltable where config_value = 2147483647 and run_value = 2147483647 )
PRINT N'ERROR: Max text repl size is not correct!'
ELSE
PRINT N'PASS: Max text repl size is correct.'

IF NOT EXISTS (SELECT db.owner_sid FROM sys.databases db WHERE db.database_id = DB_ID() AND db.owner_sid = 0x01)
PRINT N'ERROR: Database owner is not sa account!'
ELSE
PRINT N'PASS: Database owner is sa account.'

IF NOT EXISTS( SELECT * FROM sys.databases db WHERE db.database_id = DB_ID() AND db.is_trustworthy_on = 1 )
PRINT N'ERROR: Trustworthy bit is not on!'
ELSE
PRINT N'PASS: Trustworthy bit is on.'

IF NOT EXISTS( SELECT * FROM sys.databases db WHERE db.database_id = DB_ID() AND db.is_broker_enabled = 1 )
PRINT N'ERROR: Service broker is not enabled!'
ELSE
PRINT N'PASS: Service broker is enabled.'

IF NOT EXISTS( SELECT * FROM sys.databases db WHERE db.database_id = DB_ID() AND db.is_honor_broker_priority_on = 1 )
PRINT N'ERROR: Service broker priority is not set!'
ELSE
PRINT N'PASS: Service broker priority is set.'

PRINT N'Done!'

Branch_Exit:

That script is dead handy!

We’re looking for INFO and PASS only

INFO: Targetted database is CM_CTP.
INFO: Running verifications....
PASS: CLR is enabled.
PASS: Max text repl size is correct.
PASS: Database owner is sa account.
PASS: Trustworthy bit is on.
PASS: Service broker is enabled.
PASS: Service broker priority is set.
Done!

Configure SQL Security for Primary Site server

We’re going to recreate the SQL login for the site server to use, this will have been lost as SQL Engine logins are not backed up when you backup a database, the SQL logins are present in the database but not on the new SQL server.

• Expand CMSQLAONA, Security and right click Logins, now select New Login…

My Primary’s hostname is CMCBTP so I’ll create the new login as its computer account

• Select Server Roles

• Make sure public is ticked, it should be by default
  
  
• I added sysadmin as I was troubleshooting on the first go around setting up a Availability Group, the site server doesn’t need these rights, but the account you are logged in as when working through this guide must have sysadmin rights
  
  
• Select OK
  
  
• Expand CMSQLAONB, Security and right click Logins, now select New Login…

Again use the Primary’s site servers hostname, CMCBTP$

• Make sure public is ticked

• Select OK

Enable SQL AlwaysOn Feature

Next up is enabling the SQL AlwaysOn feature on all three Replicas. This feature will not light up until a replica is a member of a Windows Server Failover Cluster.

• From CMSQLAONA open SQL Server Configuration Manager

• Select SQL Server Services, right click SQL Server (MSSQLSERVER) and select Properties
  
  
• Now visit the AlwaysOn High Availability tab
  
  
• Select Enable AlwaysOn Availability Groups

• Select OK
  
  
• Restart the SQL Server service for the change to take effect, as it warned you. You can restart the service inside the Configuration Manager console, right click SQL Server (MSSQLSERVER) and select Restart

Note: The AlwaysOn feature would not light up and be greyed out, if this server wasn’t a node in a Windows Cluster, didn’t I just say that? It is worth repeating!

• Perform this step on each of the remaining replicas CMSQLAONB and CMSQLAONC

Create a Network Share to facilitate the transfer of the site database CM_CTP to all Availability Group Replicas

When we create the Availability Group we need to somehow get the site database copied across to all remaining replicas, CMSQLAONB and CMSQLAONC. Well we can do this manually or we can let SQL do it for us using a file share.

I created this file share on CMSQLAONA, as this is a bridgehead for doing all the SQL administrative work so far, let’s create it here.

• Open File Explorer
  
  
• Create a new folder on CMSQLAONA called C:\CMDBTransfer
  
  
• Share the folder out

• Give the Full Control share permissions to Everyone

• Select OK
  
  
• Right click the CMDBTransfer folder, select Properties and then the Security tab
  
  
• Set the ACL’s so that the SQL Account YourDomain\CMClusterService has full permissions

• Select OK
  

Create a SQL AlwaysOn Availability Group

Good to create the Availability Group now. We’ll begin the creation of the Availability Group on CMSQLAONA.

• Return to SQL Management Studio
  
  
• Navigate to CMSQLAONA
  
  
• Right click AlwaysOn High Availability

• Select New Availability Group Wizard…

• Have a read
  
  
• Select Next

• We’ll now name our Availability Group as ConfigMgrAG
  
  
• You could call it whatever you want, if you change it keep an eye out for references to ConfigMgrAG fruther into the guide, and substitute for whatever you chose
  
  
• Select Next

• It see’s our database, select it

Note: You may be prompted that a Full backup is required of the newly imported database, if so stop, backup the database that you just imported so as to overcome this constraint and proceed.

Note: When I first took my ConfigMgr Tech Preview site database from a local install into the first availability group lab that I created, the text in this dialog was different, some actions are needed, and size of DB was mentioned, as well as results of a prerequisite check. I might move my ConfigMgr Current branch into an Availability Group, which means I’ll see this wizard again, return here and amend for the differences. In the meantime you might need to wing this section a bit, by doing whatever the prerequisite checker asks of you

• Select Next

We are now going to add in the Replicas that will participate in the Availability Group, that’ll be all three cluster nodes CMSQLAONA, CMSQLAONB and CMSQLAONC

• Select Add Replica…

• Enter CMSQLAONB and select Connect

• Select Add Replica…
  
  
• Enter CMSQLAONB and select Connect

• Note that CMSQLAONA is listed as a Primary Replica, and CMSQLAONB and CMSQLAONB are listed as Secondary Replica’s
  
  
• For CMSQLAONA tick Automatic Failover (Up to 3), tick Synchronous Commit (Up to 3) and select Yes for Readable Secondary
  
  
• For CMSQLAONB tick Automatic Failover (Up to 3), tick Synchronous Commit (Up to 3) and select Yes for Readable Secondary
  
  
• For CMSQLAONC, which we’ll use to enable the Technical Preview Build 1705 feature for AlwaysOn, Asynchronous Availability Group replica support, untick Automatic Failover (Up to 3), untick Synchronous Commit (Up to 3) and select Yes for Readable Secondary

• Select the Listener tab

• Select Create an availability group listener
  
  

Note: The Listener is actually a DNS record that will be used by Applications when they attempt to connect to the Availability Group, earlier in the guide I called out a link on tooling up knowledge-wise on what a Listener is, so I’ll forgo being an echo-chamber and repeat what you already knew or just learnt.

• Enter ConfigMgrAGL as the listener DNS name
  
  
• Enter 1433 as the Port
  
  
• Enter an IP address for the listener to use, I used 192.168.1.173 for ConfigMgrAGL
  
  
• If you build further Availability Groups, they will have their own unique listener, much like a Cluster Name (interface!)
  
  
• Select Next

The site database needs to be transferred to the other two Replica in the Availability Group, SQL can automatically do this for us, with that share we created, or we can handle it manually ourselves. Guess which method we’re opting for!

• Select Full
  
  
• Enter the full path to the CMDBTransfer share you created earlier(\\CMSQLAONA\CMDBTransfer)
  
  
• Select Next

• And all the ducks line up
  
  
• Select Next

• Select Finish to get things underway

• Time for more tea

• More tea

• Great we’re done here
  
  
• Visit your DNS server and you’ll see a new A record has been created for your new Availability Group ConfigMgrAGL

• From CMSQLAONA visit the SQL Management Studio
  
  
• Expand out CMSQLAONA and the Availability Group nodes

• You did that :-)
  
  
• I am assuming it all worked out, well done!
  
  
• Let’s see if its really working, bring up the Dashboard, a right click off the Availability Node

• Select Show Dashboard

• Click on ConfigMgrAG to drill down

• If you are not seeing Green you’ve derailed somewhere, not very helpful of me but I would recommend reading any critical or warning messages it produces, take it from there
  
  
• Note that you can administer most of the Availability Group from here, a primary to note is that you launch the failover wizard from the dashboard but can launch it from a right click on your Availability Group in Object Explorer

Final SQL Configurations

The site database now residing on CMSQLAONB was transferred there using SQL Backup and Restore, which means that some database settings haven’t been carried across. These need to be set, or normalised, but we cannot straight connect and configure, we need to tell the Availability Group to failover to that replica then perform the tasks. So let’s get on with that

• Make sure the SQL Availability Group nodes are healthy (green tick) and that they have synchronised, this could take some time, observe from the Dashboard, more tea may be required
  
  
• From SQL Management Studio right click your Availability Group and select Failover…, you can do this from any of the Replica nodes but the assumption for this guide is that CMSQLAONA is your Primary instance, and the others replicas are Secondary Replicas, so do your right click from CMSQLAONA

• Select Next

• Tick CMSQLAONB which should be the nominated Replica for Failover
  
  
• Select Next

• Select Connect

• It won’t let you interact other than with the buttons, select Connect

• Select Next

• Select Next

• Select Close
  
  
• You’ll see the dashboard show critical, leave it alone for a few moments, it auto refreshes, proceed when it returns to a healthy state
  
  
• Notice our Primary instance is now CMSQLAONB

• Select CMSQLAONB in the Object Explorer then select New Query:

Use CM_CTP;

EXECsp_changedbowner'sa'

USE CM_CTP;

 

ALTERDATABASE CM_CTP SETTRUSTWORTHYON;

Use CM_CTP;

 

ALTERDATABASE CM_CTP SET HONOR_BROKER_PRIORITY ON;

• Execute that lot on CMSQLAONB

• I did not have to set ENABLE_BROKER in my lab, so I've pulled the following step as not required:

Use CM_CTP;

ALTERDATABASE CM_CTP SETENABLE_BROKER;

• Rerun the following validation script:

SET NOCOUNT ON

DECLARE @dbname NVARCHAR(128)

SELECT @dbname = sd.name FROM sys.sysdatabases sd WHERE sd.dbid = DB_ID()

IF (@dbname = N'master' OR @dbname = N'model' OR @dbname = N'msdb' OR @dbname = N'tempdb' OR @dbname = N'distribution' ) BEGIN
RAISERROR(N'ERROR: Script is targetting a system database.  It should be targeting the DB you created instead.', 0, 1)
GOTO Branch_Exit;
END ELSE
PRINT N'INFO: Targetted database is ' + @dbname + N'.'

PRINT N'INFO: Running verifications....'

IF NOT EXISTS (SELECT * FROM sys.configurations c WHERE c.name = 'clr enabled' AND c.value_in_use = 1)
PRINT N'ERROR: CLR is not enabled!'
ELSE
PRINT N'PASS: CLR is enabled.'

DECLARE @repltable TABLE (
name nvarchar(max),
minimum int,
maximum int,
config_value int,
run_value int )

INSERT INTO @repltable
EXEC sp_configure 'max text repl size (B)'

IF NOT EXISTS(SELECT * from @repltable where config_value = 2147483647 and run_value = 2147483647 )
PRINT N'ERROR: Max text repl size is not correct!'
ELSE
PRINT N'PASS: Max text repl size is correct.'

IF NOT EXISTS (SELECT db.owner_sid FROM sys.databases db WHERE db.database_id = DB_ID() AND db.owner_sid = 0x01)
PRINT N'ERROR: Database owner is not sa account!'
ELSE
PRINT N'PASS: Database owner is sa account.'

IF NOT EXISTS( SELECT * FROM sys.databases db WHERE db.database_id = DB_ID() AND db.is_trustworthy_on = 1 )
PRINT N'ERROR: Trustworthy bit is not on!'
ELSE
PRINT N'PASS: Trustworthy bit is on.'

IF NOT EXISTS( SELECT * FROM sys.databases db WHERE db.database_id = DB_ID() AND db.is_broker_enabled = 1 )
PRINT N'ERROR: Service broker is not enabled!'
ELSE
PRINT N'PASS: Service broker is enabled.'

IF NOT EXISTS( SELECT * FROM sys.databases db WHERE db.database_id = DB_ID() AND db.is_honor_broker_priority_on = 1 )
PRINT N'ERROR: Service broker priority is not set!'
ELSE
PRINT N'PASS: Service broker priority is set.'

PRINT N'Done!'

Branch_Exit:

• Again we’re looking for INFO and PASS only:

INFO: Targetted database is CM_CTP.
INFO: Running verifications....
PASS: CLR is enabled.
PASS: Max text repl size is correct.
PASS: Database owner is sa account.
PASS: Trustworthy bit is on.
PASS: Service broker is enabled.
PASS: Service broker priority is set.
Done!

That’s it, use the failover wizard to switch back to the CMSQLAONA replica node as the Primary instance

Set the SQL SPN’s

While we’re running SQL with a domain user account we’re going nowhere at the application layer (ConfigMgr) without Service Principal Names (SPN’s). We’ll create them by hand.

• RDP to your Domain Controller or wherever you are hosting Microsoft DNS
  
  
• Open ADSIEDIT
  
  
• Navigate down to Users and find the CN-CMClusterService entry

• Double click it or select Edit
  
  
• Add in the following SPN entries so that ConfigMgr can find the SQL Service:
  
  

MSSQLSvc/CMSQLAONA:1433

MSSQLSvc/CMSQLAONA.SMSM.COM:1433

MSSQLSvc/CMSQLAONB:1433

MSSQLSvc/CMSQLAONB.SMSM.COM:1433

MSSQLSvc/CMSQLAONC:1433

MSSQLSvc/CMSQLAONC.SMSM.COM:1433

• We only need the CMSQLAONA and CMSQLAONB entries, since they are the active replicas in synchronous mode that ConfigMgr will use, but we’ll add CMSQLAONC so that you can play around with changing the roles in the Availability Group
  
  
• Select OK

• Select OK

Configure the Availability Group for Maintenance Mode (failover = Manual)

Before we can let ConfigMgr take a look at the new Availability Group we need to set it to Manual Failover mode. Perhaps in the future we’ll be able to work on Availability Groups without having to put them into manual mode, which would be every single time you service the ConfigMgr product, as is the case with Management Point Replicas which need to literally brought down before you can upgrade. I’d like to see these two areas ironed out to reduce administrator burden from lighting up cool features.

• Return to CMSQLAONA and to the SQL Management Studio
  
  
• Select CMSQLAONA which should be the Primary instance, check the Dashboard to confirm
  
  
• Right click your Availability Group and select Properties

• Set the Failover mode for CMSQLAONA and CMSQLAONB to Manual

• You have to do this on the Primary instance, which means the correct SQL server, as I said the dashboard lets you know which Replica is the Primary instance.

• You can see the Failover mode in the Dashboard

• Once they are set to Manual you are good to move onto configuring ConfigMgr

Configure ConfigMgr to use the SQL AlwaysOn Availability Group

We can now turn to ConfigMgr and ask it politely to start using our new Availability Group.

• Launch ConfigMgr Setup from the installation folder, not the installation media. Run C:\Program Files\Microsoft Configuration Manager\bin\X64\Setup.exe and select Run as administrator

• Select Next

• Select Perform site maintenance or reset this site

• Select Modify SQL Server configuration

• Enter the Availability group Listener FQDN for your ConfigMgrAG Availability Group
  
  
• Select Next

• It’ll detect the SQL AlwaysOn Availability Group and thrown a warning before you proceed
  
  
• Select Begin
  
  
• Open the ConfigMgrSetup log using LogLauncher
  
  
• Keep an eye on that log and pray!
  
  
• Once it is done you’ll get green in the configuration wizard

• You’ll also see happiness in the log, tailing off with the following

• If you are seeing SSPI errors review your SPN work, most likely related, other issues could be connectivity, not enough account permissions, some steps missed
  
  
• Go check out SMSDBMON on your Primary, it’ll show you DB activity, if there is a problem it’ll show there

Reconfigure Availability Group Failover mode

We’ve now got ConfigMgr pointing at the Availability Group, we can now return the Failover Mode to Automatic.

• Return to CMSQLAONA and to the SQL Management Studio
  
  
• Select CMSQLAONA which should be the Primary instance, check the Dashboard to confirm
  
  
• Right click your Availability Group and select Properties

• Set the Failover mode for CMSQLAONA and CMSQLAONB to Automatic
  
  
• Select OK

Reporting Point

If you had one running its most likely pointing at the old SQL Database that was home for the site database, that’ll be all ugly and broken now, so remove the Reporting Point role, add the role back, when configuring the role use the Availability Group Listener. The SRSRP log should show that the data sources have been updated with the Availability Group Listener name.

If your going to edit reports you’ll need the latest Report Builder V3, which you can find here

WSUS

Forget it. It’s unsupported.

Are there any options?

Yes, read here, it has everything to do with WSUS trying to be a bad boy and putting the SUSDB database into single-user mode, which an Availability Group won’t have any of. As you’ll see in this guide, its just a matter of procedure, and you can have WSUS running its database in an Availability Group, not the one being used by ConfigMgr, a new one dedicated for WSUS usage.

A great source of information alongside the SQL Documentation library came from here Prepare to use SQL Server Always On availability groups with Configuration Manager, which takes you to the ConfigMgr Documentation library, a world-class documentation library.

Another source very worthy of a mention is this article from Benjamin Reynolds at Microsoft titled Moving the ConfigMgr site database to an Always On Availability Group, he writes up on how to do what I do above, but he does it to a production database while minimising down time. You’ll find both articles complement each other in that Benjamin skips over some aspects whereas I document their steps. Using both you can build out your lab and put together an ace plan to do a production run at some point.

When it comes to identifying what department a device belongs too, it can either be easy or beyond complicated.

For some it is a simple case of relying on a well-organised Active Directory Site layout, or Organisational Unit structure, but for other SCCM administrator sorry souls, branding from external directories and sources is haphazard and unreliable.

If you are in the latter category, and are fed up with a poorly run external branding mechanism, branding devices can be made to be a cinch using SCCM, some patience and a multi-pronged form of attack.

I’ve got a simple solution here that helps you get an existing estate branded, and which can then lead on to efforts to perform mandatory branding when new devices are introduced, or existing devices are rebuilt.

There isn’t anything here more complicated than leveraging an SCCM feature called Collection Variables, the usage of you’ll pick up as you follow the guide.

The key components needed for this solution are a PowerShell Script, in a Package, in a Task Sequence as an Run PowerShell Script step, some Collections hosting Collection Variables, and RegKeyToMof by Mark Cochrane to extend Hardware Inventory out easily, so we can return the branding data back to the Site server for ‘usage’.

With this guide you can walk through a two phased approach to branding your existing desktop estate, firstly brand what is already out there, so that you can reliably query against devices Hardware Inventory, so as to eek out which department it belongs too.

The second phase would be up to you to cover, and that would be making sure the branding of a device is performed during the Operating System build process. This, if done right, will make sure all new devices coming in are branded and compatible with the SCCM hierarchies collection queries that revolve around the branding itself.


Before we get going let’s make some assumptions about you:

• You don’t need me to explain when to finish completing a wizard, choosing defaults to wrap up
  
  
• If I do not mention a setting, that’s because it is supposed to stay as it is, in its default setting
  
  
• If this all looks like rocket science, you really should park yourself up and read material on the subjects, keywords for you to look up and research in the documentation library would be:
  
  

Collections
Collection Variables
Collection Queries
Packages
Package Source
Task Sequences
Deployments
Hardware Inventory
Extending Hardware Inventory
Windows Registry
PowerShell (well okay, don’t deep dive it, take an eternity, if you don’t know it at least look up what a PowerShell variable is)

I bet you all can tick those boxes, if you can great, move on, otherwise if you proceed with the intent of building this tool out in your lab, without doing any reading whatsoever, you’ll get a big tut from me if I find out, and a Low-Quality-Grade sticker posted to you. Put in the burn and effort to soak up the detail as it is important, not to remember it all, but to have been there a few times, forms muscle memory, an important aid for someone trying to cover a product as vast as SCCM is.

Let’s begin.

• Create your Package Source Folder
  
  

• Visit your Content Source location used for SCCM content, create yourself an SCCMBranding folder
  
  

• Create the PowerShell script
  
  

• Copy the following script to the new folder, and call the file SCCMBranding.ps1, don’t save it yet, copy it then go to the next instruction
  
  

# SCCM Branding Tool

# Written by Robert Marshall EM MVP

$ToolVersion = "1.0"

$CompanyName = "SMSMarshall"

$HKLMCompanyPath = "HKLM:\SOFTWARE\" + $CompanyName # Company Path

$HKLMBrandingPath = "HKLM:\SOFTWARE\" + $CompanyName + "\Branding" # Company Branding path

$companyID = "DepartmentID" # Name of Registry Value and Collection Variable

$TSEnv = New-Object -COMObject Microsoft.SMS.TSEnvironment

$TSLogPath = $TSEnv.Value("_SMSTSLogPath")    
    
$TSLogFile = "$TSLogPath\$($MyInvocation.MyCommand).log"

# Start the logging

Start-Transcript $TSLogPath

Write-host "SCCM Branding Tool $ToolVersion"

if ( -Not (Test-Path $HKLMCompanyPath)){

    Write-host "Creating new key $HKLMCompanyPath"

    New-Item -Path $HKLMCompanyPath -ItemType RegistryKey -Force
}

if ( -Not (Test-Path $HKLMBrandingPath)){

    Write-host "Creating new key $HKLMBrandingPath"
    
     New-Item -Path $HKLMBrandingPath -ItemType RegistryKey -Force
}

Write-host "Checking if $companyID exists"

$valueExists = Get-ItemProperty $HKLMBrandingPath $companyID -ErrorAction SilentlyContinue

if ($valueExists -eq $null){

    Write-host "ID $companyID does not exist"
    
     # Determine where to do the logging            
    
     Write-Host "Creating Branding registry key" $companyID

    New-ItemProperty -Path $HKLMBrandingPath -Name $companyID -Value $tsenv.Value($companyID)

}
else{
     Write-host "ID $companyID exists"
}

Write-host "Finished."
    
# Stop logging
Stop-Transcript

• Before you save this file, change the $CompanyName value to the name of your company or some identifier for your Lab, branding will live in a sub-key called Branding (HKLM\Software\CompanyName\Branding)
  
  
• What does this script do? It logs a lot, and looks for the Collection Variable then imprints it on the Registry
  
  
  
• Create a new Package
  
  

• Call it SCCM Branding Tool
  
  
• Set the data source to point at the SCCMBranding folder
  
  
• No need for a Program, we’re running content from the package using a task sequence
  
  

• Create a Task Sequence
  
  

• Call it SCCM Branding Tool
  
  
• Add Run PowerShell Script action
  
  

• Set the Package to the SCCM Branding Tool
  
  
• Enter SCCMBrandingTools.ps1 as the script name
  
  
• It should look a lot like this:
  
  
  

• Edit the task sequences properties
  
  

• Select suppress task sequence notification, however skip this step if you want the deployment to be visible for troubleshooting\first time around purposes
  
  

• Create a Collection
  
  

• Call it SCCM Branding Tool
  
  

• Add a new Collection Variable
  
  
• Call it DepartmentID
  
  
• Give it a value of CompanyTechnicalGroupA
  
  
  

What we’ve done is created a collection that will be used for both the Deployment of our Task Sequence, and for defining what DepartmentID is, so that the branding tool can place that value in the registry of the devices being targeted.

If you were taking this from the lab into production, you’d have a single collection for deploying the branding tool, and then you’d define the collections you will use to hold each collection variable, one collection per department so as to break down your devices into their respective departments.

This will introduce lots of collections, and you’ll need to manually add existing devices into respective department collections, so that it is given the right DeploymentID value when the branding task sequence is run on it.

You can add devices to these collections manually, or automate it a bit with query logic on the collections to process AD Site, Organisational Unit, Username, even software installed; Choose whatever way you can manipulate inventory and discovery data, to determine if a device belong in a departmental branding collection.

We now have to tell SCCM to inventory this new registry key on the devices in the Hierarchy.

• Modify SCCM Hardware Inventory Definition and Reporting
  
  

• Open RegEdit on the target device you’ll be using for branding
  
  
• Navigate to HKEY Local Machine, Software
  
  
• Create a Key, and name it as whatever you specified in the SCCMBranding.ps1 script as the $CompanyName variable value (It needs to look like HKLM\Software\CompanyXYZ)
  
  
• Create a sub-key under your Company name key, and call it Branding
  
  
• Create a string value (REG_SZ) and call it DepartmentID, it does not have to have a value
  
  
• Download RegKeyToMOF and run it on the device you just created the registry keys on
  
  
• It will start up and show the HKLM registry hive, navigate to Software, find your Company Name key, expand it and click on Branding
  
  
• On the right make sure the tick box is ticked for DepartmentID
  
  
• Tick 64bitsonly unless you have 32 bit Operating Systems that’ll need this running on, in which case don’t tick it, then check out the class names and how they are defined as this will change how you write queries for collections
  
  
• Below you’ll see I’ve highlighted the reporting class, copy that to the clipboard
  
  
  

• Copy the clipboard contents to a file called SCCMBranding-DepartmentID-Reporting.mof anywhere of your choosing, somewhere safe, consider when\if you rebuild the site server, you’ll need this file again
  
  
• Now return to RegKeyToMOF and select the configuration.mof tab
  
  
• Do the same and copy the text (with or without the // comments) into a file called SCCMBranding-DepartmentID-Definition.mof
  
  
• We’re done with RegKeyToMOF now, that really made extending SCCM Hardware Inventory a breeze, thanks Mark!
  
  
• You can also delete the registry value, and key all the way back to Branding, do this is if the device you just used to obtain the registry key from is going to be the test device
  
  
• Now open the dataldr.log log file on the site server in readiness to watch MOFCOMP process the definition change we’re about to make to Hardware Inventory
  
  
• On the site server open the SCCM installation folder, navigate into Inboxes, CLIFILES.SRC, and into the HINV folder
  
  
• Open the configuration.mof file in WORDPAD
  
  
• Navigate to the bottom of the file, and put the cursor between the extension start and end comment blocks like so, then paste in the contents of the SCCMBranding-DepartmentID-Definition.mof file
  
  
  
  

• Save the file, return to the data loader (dataldr) log file and see MOFCOMP process the MOF successfully, if not check what you are doing, the definition mof contents go into this definition file, not the reporting mof content
  
  
  
• If all is good in the data loader log, open the SCCM Console, navigate to Administration, Client Settings, edit the Default Client Settings
  
  
• Select Hardware Inventory then select Set Classes…
  
  
• Select the Import… button and navigate to the SCCMBranding-DepartmentID-Reporting.mof file
  
  

• Accept all the prompts with default options selected, and click apply to update the default client settings for the Hierarchy

Let’s deploy the task sequence to the combined deployment and branding collection, we’re almost there.

• Deploy the SCCM Branding Task Sequence
  
  

• Make it Required, as soon as possible, or available if you are troubleshooting\passing through this solution for the first time
  
  
• Tick Do not show task sequence progress, you can untick this if you’ve already decided to make the task sequence available and visible
  
  
• Override maintenance window for Software installation
  
  
• Allow remote or fallback, share if using BranchCache
  
  
• Download when needed or before, either works, choose appropriate to your hierarchy

• Kick the tyres – Run the branding tool on the device
  
  
  

• Add the device to the SCCM Branding collection, it will then pickup that Collection Variable and the Deployment
  
  
• Make sure it shows in the collection before proceeding, obviously a very important step!
  
  
• Perform a Machine Policy Retrieval for the device, either at the device or using the client notification channel, quite important to make sure the device gets the very latest policy payload or you’ll be testing with old policy containing your previous edits and such like, voiding your test and forcing you to repeat it
  
  
• Keep an eye on PolicyEvaluator for new policy coming in, once you see it carry on (no policy update? try nudging it again)
  
  
• If you made the deployment interactive (available) and the task sequence visible, it’ll be showing in Software Center, from where you can install it

• Check out the ExecMgr and SMSTS log files, they will show you the launch of the task sequence, and the task sequence logging file, the ContentTransferManager log will show you the script content being brought down.
  
  
  
• If SMSTS log doesn’t exist, the deployment hasn’t run, you’ll have to figure out what went wrong using the device logs, and check how you’ve configured everything on the Site server.

This is a clean run through task sequence execution, that branded a device correctly:

Transcript started, output file is C:\WINDOWS\CCM\Logs\SMSTSLog RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
SCCM Branding Tool 1.0 RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
reating new key HKLM:\SOFTWARE\SMSMarshall\Branding RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
   Hive: HKEY_LOCAL_MACHINE\SOFTWARE\SMSMarshall RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
Name                           Property                                         RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
----                           --------                                         RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
Branding                                                                        RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
Checking if DepartmentID exists RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
D DepartmentID does not exist RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
reating Branding registry key DepartmentID RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
epartmentID : CompanyTechnicalGroupA RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
PSPath       : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\ RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
               SMSMarshall\Branding RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\ RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
               SMSMarshall RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
PSChildName  : Branding RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
PSDrive      : HKLM RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
PSProvider   : Microsoft.PowerShell.Core\Registry RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
Finished. RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
Process completed with exit code 0 RunPowerShellScript 12/08/2017 14:50:49 10052 (0x2744)

• Open RegEdit
  
  
   

• The device has been branded!
  
  

Let’s check out what SCCM can see.

• Back to the SCCM Console, Assets and Compliance and show members for the All Systems collection
  
  
• Find the test device, right click it and select Start and then Resource Explorer
  
  
   

• As if by magic, our registry key value has appeared in the hardware inventory for our test device. Sweet.

Whatever device you add to the collection will now be branded with the DepartmentID value CompanyTechnicalGroupA.

Let’s reflect on what we’ve achieved so far.

We have:

• A basic but cool PowerShell script, that will brand devices using a Task Sequence Collection Variable if we run it inside a Task Sequence (to get at Collection Variables)
  
  
• A Package containing the PowerShell script
  
  
• A Task Sequence with the Run PowerShell Script action invoking our PowerShell script
  
  
• A single collection that we’re using to set a Collection Variable, and to deploy to any members
  
  
• Hardware Inventory returning the registry key value if it exists on any device in the Hierarchy (we can narrow this down using custom client settings to switch it off on grouped devices if we so wished)
  
  

What we don’t have is a way to determine what is branded and what isn’t. So let’s build that out now using two collections dedicated for that exact purpose.

If we want to keep track of what hasn’t been branded, we need a collection to query for them, however it isn’t straightforward to do due to collection logic limitations, so we’re going to need two collections and those very useful INCLUDE\EXCLUDE collection rules.

• Create a Collection for all branded devices
  
  

• Name it SCCM Branding – Branded Devices
  
  
• Limit it by a All Desktop and Server devices, or another collection of your choosing
  
  
• Create a new Query
  
  

• Name it IsBranded
  
  

• Create a Collection for all unbranded devices
  
  

• Name it SCCM Branding - Unbranded Devices
  
  
• Limit it by a All Desktop and Server devices or another collection of your choosing
  
  
• Add an INCLUDE rule and select All Desktop and Server devices (or whatever you want to limit with)
  
  
• Add an EXCLUDE rule and select SCCM Branding – Branded Devices

• Finish up the creation of the collection
  
  
• This collection will show devices that have not been branded by including all devices (according to what you chose for the include rule) and then excluding those known to be branded in the SCCM Branding – Branded Devices collection
  
  

If you check out the Collection Evaluator log, you will be able to see your new collections queries run, and the resulting devices added to each like so:

* 2 Devices in this Hierarchy, a fresh bud just built, one device is branded, the other not

Finally, we’ll build a collection into which we will pour all the devices for a specific department (or even multiple departments), using a query that looks for DepartmentID having a specific value.

Since we only have one value coming back as a branding value, CompanyTechnicalGroupA, we’re going to build around that.

• Create a new Collection
  
  

• Name it SCCM Branding – CompanyTechnicalGroupA
  
  
• Limit it to All Desktop and Server clients (you can limit by any collection obviously, giving this solution a high level of granularity)
  
  
• Add a new Query Rule
  
  

• Call the rule SCCMBranding
  
  
• Click Edit Query Statement …
  
  
• Select Criteria
  
  
• Select Starburst (yellow star icon)
  
  
• Select Select …
  
  
• Now look for your new SCCMBranding class
  
  
  

• Select OK
  
  
• Select Values…
  
  
  

• It should list the data discovered from the test device or devices
  
  
• Choose the DepartmentID listed, select OK four times to finish up the Query

Let Collection Evaluator run the collections query, and eventually, you’ll see your first device or devices dropping into the collection:

So there you go, a very basic branding tool, that you can easily build out further, by hybridising it to wrap around your organisation and hierarchy setup.

An immediate step you could take forward, is to use Compliance Settings to figure out who doesn’t have branding, but since you cannot pass Collection Variables down using Compliance Settings, you cannot use it to brand via this solutions approach of pivoting off of Collection Variables.

Enjoy.