Hi Jeff,

I would add to the list the following :


-          Client Settings to be created for each specific configuration

-          RBAC to allow users into the Console

-          Collection Tree that need to be possibly re-thinked because of the 
above RBAC (mainly limiting collections)

Regards,

Jérémy SI HASSEN | InepSol | Architecte Configuration Manager, Poste de Travail 
et Data Protection Manager | +33 6 63 23 22 11 | 
[email protected]<mailto:[email protected]>
[btn_in_20x15]Jsihassen on Linkedin<http://fr.linkedin.com/in/jsihassen>

From: [email protected] [mailto:[email protected]] On 
Behalf Of Jeff Poling
Sent: jeudi 30 juillet 2015 00:27
To: [email protected]
Subject: [mssms] Domain migration and ConfigMgr

In an environment where a domain migration is being performed, I need to get 
ConfigMgr up and running in the new domain.  Just as a sanity check, are these 
the general items that need addressed?

New ConfigMgr Primary Site installed with new site code

Site publishing configured in new domain (System Management container created, 
new site server with full permissions, schema extended, etc.)

Required roles installed

Boundaries and Boundary Groups configured

ConfigMgr objects migrated and/or re-created (collections, 
packages/applications, task sequences, SCEP policies, etc.)

Client migration:
- Uninstall client
- Disjoin PC from existing domain
- Join new domain
- Install client from new SCCM primary site

Test site assignment, application deployment, OSD, etc.

In terms of other prerequisites to consider:

The content source location for applications, packages, drivers, etc. needs to 
be in the new domain (or possibly accessible via a trust might work as well)

Network access account and client push accounts at minimum will be needed in 
the new domain



Thanks,


Jeff


Sent from my Windows Phone




Reply via email to