Join David M. Franklyn for an in-depth discussion in this video The upgrade process, part of Microsoft System Center Configuration Manager Essential Training.
- [Instructor] So, let's talk about upgrading and the upgrade process. Before we discuss it though, we should know the difference between a migration and an upgrade. A migration refers to the process of replacing an earlier version of Configuration Manager with a newer version and from one server into another, or onto another, usually a newer server. So for a short period of time, both servers are running side by side and we move, or migrate, the data, the databases and all the objects to the newer system.
And in the long run is part of life cycle management, you'd want to do this unless the earlier version hardware is still new, as eventually older systems wear out and warranties expire. So imagine this, you have Configuration Manager 2012 R2 version and that goes back and was first released around 2014, so it's a few years later now. How long is the warranty on the hardware you put it on? And generally speaking, hardware is fairly robust nowadays. It's going to last a long time, but warranties will be a less period of time than let's say the hardware will survive.
And at that point, you want to consider do I get a new warranty for this hardware, which might cost more money because it's older and it's used or do I just want to get new hardware, which may be the cheaper way to go in the long run when we look at it from a budgeting process. And at that time, then we could clearly consider migration as the best option. And personally, I think it's the best option also for those reasons, for older systems wear out, warranties expire. If I'm going to put in a whole new system that's vitally important to my organization, it's a critical need system, then I want it to be on the best possible hardware with the best possible warranties.
So that part of it is covered. In any case, an upgrade refers to the process by which an existing site server is moved from one version to a newer version on the same computer. Now upgrades are usually fully supported and are tested in many configurations before being released, usually. In an upgrade, data on the server is transformed at the database level and all data and metadata are preserved. This is true in the broad view of things, not just Configuration Manager, but for almost every system.
If you're going from, for example, Windows Server 2012 R2 to Windows Server 2016, you can upgrade it or you can do a migration. In any case, most administrators will consider the migration to be the better way to go. Again, for the same reasons I cited previously. But upgrades can be done and are done by a considerable number of people for various reasons, such as they don't want to recreate file shares that are extensively done, they have configurations that have been perfected, and again, are extensive and they don't want to change those.
They might've even had an older operating system on fairly new hardware, so it's still covered. But in any case, it comes down in Configuration Manager to which version of the current branch you upgrade to. The larger the gap, if you will, let's say if we're now going from 2012 R2 all the way to current branch 1702, then the more things you'll have to check and contend with. So prior to upgrading, and this will be part of your planning to upgrade, there are many, many things we need to check.
So first thing you want to do is check out your environment. Now hopefully you have good documentation about the environment. You known where every site system role is, every database is, you've been deleting aged data and all the other stuff you would do in the normal monitoring and site maintenance tasks, you've backed up and all the other things that you might need to do, and everything is going well. You need again to review it to make sure that you know exactly what's running on what, and this comes down to written documentation most of the time, 'cause you're not necessarily going to have this in the top of your head.
You could, but again, to have a checklist, to have it written down to know exactly what you're doing, what you have, because you're going to be upgrading all of it as you go through this process. The next thing we want to do is make sure that the computing environment meets the configuration support or prerequisites that we have. In most cases, you're going to find the current branch prerequisites are very similar to Configuration Manager 2012 R2. So as far as RAM goes, as far as the operating system requirements you might have, you might be going to Server 2016, more or less at the same time.
You might want to do an upgrade there first of the operating system, then an upgrade of Configuration Manager on top of that, but keep in mind, those are two separate upgrades and each one has their own particular prerequisites and things we need to do before upgrading them. You want to review the prerequisites for every single site system role. Now, when we first install we have our management point, we have out distribution point, we have our database server, and then from there, we start adding additional site server roles.
We might not do this all on one computer. In many cases, as we said before, we can have a database server on a separate computer so that we can provide high availability to the database by using fail over clustering. In that case then, we've got to consider okay now I have two computers, actually more than that because if you have a fail over cluster you'll have separate nodes on that, but you have multiple computers with different roles that you'll have to ensure the prerequisites were made on in total.
The next thing we want to do is look at the site in the hierarchy statuses. Make sure there's no issues. I think at one time in a demonstration in this course, I actually went into the components status to check something and I had a red X in the SMS site hierarchy component. Now I didn't check it out because I had taken these servers down and up a couple of times when they might not have talked to each other or been available for a check and that could be the reason. I never really went in and checked it out because it wasn't part of that demonstration.
But nevertheless, you don't want any red X's in there. You want to go into them, you want to find out what's going on, and fix it or at least document clearly that it's not an issue you have to worry about. Even so, you want to make sure that's not going to cause the upgrade to fail. Then if there's any updates you need, get those updates installed. And that would apply to all the different site server roles whether they're local or remote. Then we want to ensure if we have any particular roles that are not supported on the later version, that is the current branch version from the earlier version, then you want to remove those.
If you're doing database replicas over to management points, you want to disable that. You don't want that to be going on while you're trying to do the upgrade. It doesn't mean you need to get rid of it, it's just disable it while you're doing the upgrade process. You want to disable any site maintenance tasks you have going on while you do the upgrade again. As we've shown before, some of these maintenance tasks are set to automatically go off, like every night, or once a week, or something like that. You want to go in there and disable them.
You don't want them going off when you're doing the upgrade. So hopefully when you do your upgrade, if it's a very simple rather than a complex installation, you can get it done in an shorter period of time and then of course once it's finished, you can re-enable anything. But if you have a number of site server roles that you're going to upgrading, so we're doing more than one now, technically speaking, then you want to make sure those tasks are disabled for that time period. Here's an important one. Back stuff up, back up everything.
Have the latest backup. Now it's not put here in the beginning. It's put in here towards the end because you want to make sure you've fixed all the things we've just looked at, all these previous bullets. So if you're going to do a backup, you don't want to back it up when you're still having issues and component status, you've still got red X's and things that you need to fix. You want to have a backup when hey everything's good now, let's get a good backup of this so if we have to retreat, so we have basically a back out plan, if we have to retreat, we could restore things exactly to the point where we started this upgrade.
So a very important thing to do is a backup once things are perfected. Now another thing you could do is once you've done that backup, test it. Make sure that you can restore it before you proceed further. Because what would happen if you did a backup and for whatever reason the required data or something you need wasn't there? And while this is very unlikely to occur given our modern systems and the checks that they do when they run stuff, it is not impossible and it has happened to people.
Remember Murphy's Law. If things can go bad, they will. Beyond this, you want to go back in and check as much documentation about doing site upgrades as you can, the review considerations. Much of this is heavily documented on Microsoft's TechNet and Docs, D-O-C-S pages. So Microsoft has had the TechNet site for many, many, many years now. But they've started up a new high level site called Docs, docs.microsoft.com and what they've done there is they've provided all the documentation, basically their entire library.
Now I'm not going to say the entire library because who knows what's not there, but just a huge amount of things and they've also provided a hyperlink on the side of any page or especially major page you visit that you can then download as a PDF. And it will go through the entire document set and all the hyperlinks that link to other pages and put them together into one overall document. So for example, when you go to the current branch page, the main current branch page in the Docs top level, then there's a download to PDF hyperlink there and you will get a document of about 1,100 pages.
And I must tell you that it is so extensive, it's such a wonderful resource. So it is, I think, even a better resource than a lot of printed books or digital copies of books you can get about system center current branch. But you can check that. Another consideration you want to do is if you have any customization, especially of your configuration.mof other MOF files or MIF files, then you want to make sure you back those up as well and back those up separately.
While site backup should get all your files, you want to make sure you have separate copies so when you go back in and you see they're missing you can just pop them back in from your previous backup of those individual files. It might be a little easier to do that then to do a full restore of an entire backup. Reboot all your site system servers. Why? Well, there are things that can be turned off. One thing that is needed between especially servers in a multisite hierarchy is the remote registry services available and running on all of them.
And that is one of the services that sometimes will just show up as stopped. Now I haven't researched this fully, so I can't tell you all the reasons why it would stop, but if it's not running and you're trying to do any type of let's say add another site whether it be a primary or secondary, that will often be your point of failure. So by restarting and causing all the services to correctly start based on their start profiles, so for example, some services are required to start automatically on restart, and that will flush it out.
You wouldn't have to go to each individual computer's services console and check to see what's not running that should be. Your restart will do that. So it's a very good thing to do. Now, what happens when we run the upgrade? How is this process going to take place? In the case of an upgrade, it's going to be very much an install because you're going to get the bits from the installation media, whatever you have, whether it's an ISO digital file or on a virtual machine or it's an actual DVD or USB stick or whatever you're using, you're going to bring up the splash screen and you're going to run the install just as we have done on many of our site creations that we've gone through in this course.
So, one other thing you can do, there is a prerequisite checker that's part of the install that you'd run from the install on the splash screen. However, there is separate software to run the prerequisite checker. Also, if there's any additional prerequisite files and redistributables, then you want to get them. Now when you do the install from the splash screen, it actually does that. It downloads the prerequisite files. That's part of the process. You can have these separately if you wish to speed it up a little bit.
When you do an initial download there's a lot more files than the subsequent ones that you would do for other sites. What about your server and client languages? We've encountered that several times in installing and to make it easier for our demonstration purposes, we've just selected English on both. But if you're running a global empire, as we had in the previous demonstrations with a very large center of our business in Seoul, South Korea and a smaller part in Singapore then you might want to consider additional languages.
So for those countries obviously you'd have Korean. You might have Mandarin Chinese, even Cantonese Chinese language and others, Malay and things like that depending on the location that you're putting them in at least for the clients. So the idea is when someone goes to the Configuration Manager icon in the Control Panel it's now showing in their language, makes perfect sense, right? But in any case, many things are done at the server level in English and you can probably find a lot more documentation on it, so consider having English and the other native languages as well.
If you are upgrading a multisite environment then I'm here to tell you, this is going to make it more difficult. It always is going to make it more difficult 'cause rather than doing one difficult thing, you're doing many difficult things over and over again at each site. And that case then, you probably, and one good idea is to create a dummy site that is a site that doesn't have any clients or you can add a couple of clients. A great idea to do this is a virtual environment with virtual machines since they're so easy to bring up and discard when you're done, but setup a test deployment.
Perhaps you could use a backup of your actual site and then restore it to this dummy site if you will if this test site that you have isolated and then try an upgrade on that. See how it goes, see if you get any errors. Rectify those errors until the point that you can run it very smoothly in this environment that you setup that mimics yours, and then it's going to be so much easier. So, I don't think I need to add this point, but I will that doing anything in Configuration Manager is a lot of work and requires a lot of patience.
Things don't happen as quickly as we might like and then things show up after a period of time once all of the processing, especially in multiple sites the replication is completed between the different site servers, especially when you have a central administration site and multiple sites. So you're going to be upgrading them. You might want to start at the lowest possible level and work your way up with your last upgrade being your CAS site. And don't forget the Configuration Manager consoles.
They will be upgraded to the newer version that you're going to, your current branch version, whatever the version year date is. So in that case, you really want to just ensure that the checkbox for install the Configuration Manager console is still part of the overall install that you're doing from the splash screen. And you want to check also the version of your console to see if it did change. And finally, the clients. So the clients of course, any client software you pushed out, the client agents you pushed out running on the client will need to be upgraded.
The best thing to do, of course, is to simply let the new install version of Configuration Manager upgrade the clients by just going in and checking in the client installation settings that they will be upgraded, not just installed for the first time.
- Planning and deploying a standalone primary site
- Ensuring domain and site server prerequisites
- Planning and expanding a standalone primary site
- Planning and deploying a multiple-site hierarchy
- Planning resource discovery and client deployment
- Managing content and replicating data in Configuration Manager
- Configuring Internet and cloud-based client management
- Advanced monitoring
- Upgrading to Configuration Manager current branch