How to consolidate and move to newer versions of windows server?

[RoTheOne]

Hi guys,

 

Thanks for the guides have used them to do a bunch of great things with my SCCM environment.

 

I inherited this system from someone else who set it up and has since left the company. We have 250 windows clients with a mix of Windows 7/8.1/10 across 6 sites.

 

Our SCCM is now running current branch on Windows Server 2008 R2. We use WSUS for windows updates but I would like to move these into SCCM at some point.

 

Our architecture is:

• CAS Server
• Primary Site server (where we are doing all our admin from)
• 5 Distribution Points in other states

 

Having read through the guides here I believe that given our small number of clients we only need to have a Primary site and can do away with having a CAS.

 

So I have two things from all this that I want to achieve.

 

1. Decomission the CAS and move to Primary server only environment with the 5 DPs

2. Migrate from Server 2008 to Server 2012 R2

3. Setup SUP on Primary server (needs to be able to service windows 10 clients so I think best to wait until I upgrade the host server to 2012 R2?

 

I have found some bits of info about all of this but before I start trying to do any of it, I am wondering what advice the experts would give me. Do the three things I am aiming to do make sound logical sense? What order should I approach this in? And would it be easier or better to blow away our SCCM infrastructure and start fresh?

 

 

Thanks

Edited February 24, 2016 by RoTheOne

[ZeZe]

I'm trying to get a document that I read once explaining when and how's about the CAS. But with some precautions if you wish to remove it from your hierarchie - like maybe you can't! But maybe I'm wrong... if I find that I'll let you know...

[ZeZe]

https://technet.microsoft.com/en-us/library/gg712681.aspx#BKMK_AboutSiteTypes

 

Install a central administration site if you require multiple primary sites. However, unless you support more clients and devices than a single primary site can support, you can install a stand-alone primary site and reduce your administrative overhead and avoid unnecessary database replication between a primary site and a central administration site. In a stand-alone hierarchy design, a stand-alone primary site provides the same functionality as a central administration site. Prior to Configuration Manager SP1, this was a permanent decision. Beginning with Configuration Manager SP1, you can expand a stand-alone primary site into a hierarchy with a central administration site, and then add additional primary sites. However, System Center 2012 Configuration Manager does not supported the removal of a central administration site from a hierarchy to convert a hierarchy to a stand-alone hierarchy design.

[nathan_bird]

This is easily acheivable, i've done this with my own production environment (i inherited 1 x CAS and 5 x PS's managing just 5k clients )

 

Here's what i did and it worked seemlessly.

 

1. Built a brand new 2012 R2 Server (use the same Service Accounts to make life easier and make sure you give it the correct AD permissions etc)

2. Installed SCCM with a new Site Code (install 1511 and you'll cover an upgrade at the same time if you havent already done this, mine was a 2012 R2 to 2012 R2 SP1 upgrade)

Optional but I took the opportunity to install my new DB on a SQL 2014 SP1 Cluster (before each site had its own local SQL DB running SQL 2k8 r2 which also got me on the DBA's Christmas card list )

3. Used the built in Migration Tools (Sharing your DP's until you are happy to move them over) to migrate my Task Sequences, Packages, Apps, Client Settings, boundaries etc over to the new environment

4. You then have a number of options for moving over your clients.

I fired a Site Code change script as each PS's clients, once they were reporting to the new site i decomm'd each PS and then the CAS.

 

Basically do a full side by side installation. Took me about 8 weeks as i took my time to do it, didnt want to introduce too much change at once. There was minimal downtime no hiccups which kept my ServiceDesk happy.

 

Obviously this is very high level but if you need any more info. Let me know.

[cervezagallo]

nathan_bird

Exactly the level of detail I was looking for a side by side installation. I haven't start yet. About the Migration Tools, did you use SCCM 2012 R2 SP1 tools or 1511 tools? I am assuming you lost some of the history by changing SQL server. Leaving SQL out of the same SCCM server helps the performance. The site code is located in several registry keys, correct?

 

Minimal downtime is the key!

[nathan_bird]

nathan_bird

Exactly the level of detail I was looking for a side by side installation. I haven't start yet. About the Migration Tools, did you use SCCM 2012 R2 SP1 tools or 1511 tools? I am assuming you lost some of the history by changing SQL server. Leaving SQL out of the same SCCM server helps the performance. The site code is located in several registry keys, correct?

 

Minimal downtime is the key!

 

You will use the tools from whatever version you are migrating to as you set up the Migration Source to your old site at the new site (these are compatible across all 2012/CB versions)

 

I used the following VBS script to update the site code on clients

 

On Error Resume Next

set oSMSClient = CreateObject ("Microsoft.SMS.Client")

if Err.Number <>0 then

wscript.echo "Could not create SMS Client Object - quitting"

end if

'Assign client to Servername

oSMSClient.SetAssignedSite "YOURNEWSITECODE",0

set oSMSClient=nothing

We did lose a slight bit of client history as its a new DB but we were happy with that, we had made it clear SW and HW Inventory information would need to be given time to fully re-sync. So i would say make sure you arent doing this during important SW Audits or License True Ups.

My suggestion would be build a new 1511 site, then upgrade it straight away to 1602. Then migrate. This way you only have 1 Client Upgrade push to perform to your estate (at the time of writing )

I'm already running 1602 in production without issue.