SCCM 2002 server not in a good place for co-management


Hi Everyone

I am currently working with a customer who has 2002 and want to move to co-management as they move to Modern device management. They are currently moving from one AD domain to another (they have a two way trust setup), the new domain is configured with Azure Cloud and Azure AD Connect to sync AD identities to the cloud.


The SCCM server sits in the old domain however there are some issues with the current environment and it’s not in a healthy state. Examples include:


1. Remote control tools do not work for machines configured in the new AD Domain. work fine in the old domain.

2. Task sequence smsts logs not reporting/coping back to MECM server on completion of build.

3.Deployment of user virtual apps in SCCM fail in new domain, work fine in old domain.


The issue occurring is due to in the past the SCCM server was built from a golden image containing duplicate SIDs, when they only had one domain, everything worked as expected however introducing the new domain, certain functionality of SCCM no longer works on new machines. The login is invalid as the authentication attempt contains a SiD that references multiple machines in the target domain meaning the domain controller cannot return valid credentials. The customer believes that re sysprepping the SCCM server could resolve this issue however the problem is the server will still remain in the old domain and they are looking to move all their environment to the new domain eventually and dispose of the old domain.


Before we enable co-management and cloud enable SCCM on 2006 we have asked the client to resolve these issues. My thoughts are to build a new SCCM server in their new domain and perform a backup of configMgr DB and other data and just restore that onto a new server, this means no other windows server specific config like SIDs will move across and it should mean a nice tidy clean environment. My question is what impact could this have with the existing estate. Would the same server name need to be used for clients to connect or is further config required to make it work by restoring ConfigMgr to new server.


Is there any good documentation around that assists with moving SCCM to a new server?


Many Thanks, happy to provide more detail if required.

3 Replies
Building a new site in the new forest is probably a good idea; restoring a backup of the current site to the new site server is not (and most likely unsupported). Use the built-in migration functionality to migrate everything from the current site to the new one instead. See for details.

@Michiel Overweel Many thanks for the reply


So in a migration scenario, new server, new host name and new Site ID. As part of the migration I assume once all data required is moved away the old server can be decommissioned? 


I am just wondering how existing devices connected to one site ID would then be able to communicate to a new site. 


I just watched the video on the link and it seems a possible way forward. 


Is there a reason why backup and restore would not be supported? I probably prefer that approach as it a simpler method

@isotonic_uk Correct: after completing the migration, the source site can be decommissioned (Complete migration). Before doing that, you'll need to make sure that all clients have been assigned to the new site (Plan client migration). Restoring a site backup to a server in a different domain/forest essentially means that the domain membership for the site server is changed, and that is unsupported (Support for Active Directory domains). To be honest, I'd be surprised if it even works.