Hello!
My name is Herbert Fuchs and together with other members of the Customer Success Unit and the Customer Service & Support Organization we want to help our Customers with This Blog-Series. We gathered information and put
our field and support experience into this. Special thanks to our contributors, reviewers and content-writers, Wilhelm Kocher, Anthony Fontanez, Emilian Bucur, Pavel Yurenev, Anderson Cassimiro and Madalina Zamfir.
In this Blog we want to explain what is necessary to change the Operating System of a Server which hosts the Configuration Manager by a Side-by-Side Migration.
To be more exact – it is not a change of the Operating System of your current Infrastructure – You set up a completely new Site in your Domain where you implement Current Best Practices. Maybe you want to implement a general new Design, based on your experience with the current Environment. Even with a fresh new Site – you made a lot of investment regarding Applications, Packages, Task Sequences, and other configurations which you do not want to rebuild again. And here you can use the Side-by-Side Migration, to keep this investment in your new Site too. It is also necessary to reassign all your clients from the old to the new Site – probably you will not catch all clients in the first run – so there will be a period when you must run in parallel.
This Scenario also comes sometimes if you change your Service Partner – and the new Partner want to implement/install a new Configuration Manager, instead of using the existing one for political reasons, unknown configurations where there was no hand over.
There can be also a Scenario where you want to place your Management Servers to a different domain – a Site by Site Migration is the only option in that case.
The Side-by-Side Method is a safe way to do a Transition – You define a Migration-Plan, Schedules, Responsibilities, Timelines without any pressure - however it also takes the longest time – as always there are depends – but a Side-by-Side Migration is usually not a weekend job.
Site by Site Migration Prerequisites
You find a full list of Prerequisites on this Article:
Migration prerequisites - Configuration Manager | Microsoft Learn
It is important to note which Configuration Manager Version are supported for Migration.
- Configuration Manager 2007 SP2
- System Center Configuration Manager SP2 or System Center Configuration Manager SP1 R2
- Configuration Manager Current Branch of the same or lower version
What is also important is what you can migrate and what not:
Migration job planning - Configuration Manager | Microsoft Learn
Site-Data like Hardware Inventory / Software Inventory cannot be migrated. This Data will come again as soon the Clients are reassigned and sent their first Inventories.
Before we start the Migration – it is advisable to create first a Migration Plan. At the end of this Blog, you will find a little Excel-Sheet which will help you in these matters.
Plan/Delivery/Maintain
A Project-Migration-Plan contains simple cycle of a Plan, Delivery, and Maintain:
To each phase we have different activities and doings:
Plan:
- Hierarchy Decision
- Hardware Decision
- Operating System Decision
- SQL Version Decision
- Service Accounts
- Security & Permissions
- Network-Topology
- Evaluation Dependency / Service Map
- Site Components / Business Needs
- Role-Based Administration
- What to Migrate
Delivery:
- Freeze - Change management
- Prerequisites & Tools
- Installation of ConfigMgr
- Configuration
- Functionality Site
- Initiate Migration
- Migration Jobs
- Client Installation
- Functionality Migrated Clients
Maintain:
- Migration Data Cleanup
- Demote old Site/Hierarchy
- Training
The better you prepare the better your migration will run. The Side-by-Side Migration gives you an option of Distribution Point Sharing. The idea behind this is that you reuse the Distribution Points from the Source-Site for the new Site. If you have configured Custom-Ports on the Source-Site, then the same Ports need to be configured on the New-Site too. There is also a check if a Distribution Point is eligible to migrate/re-assign.
When you are in the Migration-Phase, and can you use Enable Distribution Point Sharing – with this you instruct the Clients which are migrated to use the Distribution Point from the Source-Site for Content which was migrated. Think about a Subsidiary where you have Distribution Point. You Start Re-Assigning Clients – now you will have for a period of time Clients in this Location which still communicate to the Source Site and Clients which communicate with the new Site. So, you have mixed Clients. When the Clients are all re-assigned to the new Site you can re-assign this Distribution Point to the new Site. Then the DP will be removed from the old Site, and you can start distribution of Content from the new Site to this Distribution.
Quick Reference Guide
- Install the new Server
- Install Roles and Feature
- Install SQL
- Apply latest Cumulative Update
- Install SQL Server Management Studio
- Configure/Install SQL Server Reporting Services
- Install WADK
- Install Windows Features (IIS, RDC, BITS, WDS)
- Set Permission on the old Server (LocalAdmin, SysAdmin)
- Verify AD-Permissions on the System Management Container (Full Control including Sub-Folders)
- Install Configuration Manager latest Baseline
- Update the Site to least the same Version of the Source Site which you want to migrate
- Review Core-Site-Components (Site Component Manager, Management Point)
- Install Additional ConfigMgr Site Server Roles (Endpoint Protection, Software Update Point, Asset Intelligence)
- Review new Components
- Verify Access to the Hierarchy where you want to Start Migration-Jobs (SMB, RPC, DNS)
- Migration-Account/User – FullAdmin MECM old and new Infrastructure, SysAdmin-SQL old Infra.
- Specify Source Hierarchy for Migration
- Start Gathering Task
- Create and Run Migration Jobs (Collections, Packages, Applications, Task Sequences, Compliance Settings, Baselines, Automatic Deployment Rules, Boundaries, Boundary Groups)
- Review MigCtrl.log for Issues
- Reassign-Clients
Reassigning Clients
There are a couple of options on how to re-assign Client from the old Site to the new Site. Of course, you can combine them – to have multiple options is always good.
Option #1 PowerShell-Script:
Function Set-CMSiteAssignmentCode
{
[CmdletBinding()]
Param
(
[Parameter(Mandatory=$true)]
[String]$SiteCodeToSet
)
Try
{
Write-Verbose "Connect to WMI-Class SMS_Client and get current SiteCode"
$CMWMI = [WMIClass]('root\ccm:SMS_Client')
$CurrentSiteCode = $CMWMI.GetAssignedSite()
If ($CurrentSiteCode.sSiteCode -ne $SiteCodeToSet.ToUpper())
{
Write-Verbose "Client is currently assigned to Site: $($CurrentSiteCode.sSiteCode)"
Write-Verbose "Try to execute SetSiteAssignment-Method to Site: $($SiteCodeToSet)"
$NewSiteAssignment = $CMWMI.SetAssignedSite($($SiteCodeToSet))
If ($NewSiteAssignment.ReturnValue -eq 0)
{
Write-Verbose "SetAssignedSite-Method was successfully executed"
Return "SetSiteCode Success"
}
Else
{
Write-Verbose "Error while executing the Method"
Return "Error - ReturnCode: $($NewSiteAssignment.ReturnValue)"
}
}
Else
{
Write-Verbose "Client is already at the Site which has been defined in Parameter"
Return "SiteCode: $($SiteCodeToSet) already set"
}
}
Catch
{
Write-Error "Exception Type: $($_.Exception.GetType().FullName)"
Write-Error "Exception Message: $($_.Exception.Message)"
Write-Error "Exception Stack: $($_.ScriptStackTrace)"
}
}
Set-CMSiteAssignmentCode -SiteCodeToSet TST -Verbose
It is possible to use the Script as a Run-Script – however keep in mind you will not get a Status-Message back.
Option #2 GPO
You can use the ADM-Template from your MECM-Install-Location:
Or Create a GPP to create/set this Registry-Key:
HKLM:\Software\Microsoft\SMS\Mobile Client
ValueName: GPRequestedSiteAssignmentCode
Value: XYZ (your new SiteCode)
Option #3 Reinstall Clients
You can also Reinstall the Clients from the old Site and provide the SMSSITECODE Parameter to the new Site.
Which option you use is up to your preference – but do not remove the Client – otherwise you lose the Execution-History, for Application this is not important because of the Detection-Method – but for Legacy-Packages or Task Sequence Deployments it can have an impact and Reinstallation for Products might occur.
We hope the information in this Blog is helpful and gives you some guidance for your Side-by-Side Migration.
Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.