Windows Server 2012 R2 is the sixth version of the Windows Server family of operating systems. It was unveiled on June 3, 2013 at TechEd North America, and released on October 18, 2013. A further update, formally designated Windows Server 2012 R2 Update, was released in April 2014. It is a cumulative set of security, critical and other updates. Windows Server 2012 R2 was succeeded by Windows Server. Next, we will choose the version of Windows Server 2012 R2. In our case, we are going from Windows Server 2008 R2 Standard Edition to Windows Server 2012 R2 Standard Edition. Afterwards, we read the EULA from top to bottom, since it is very important.
There are basically two approaches when it comes to server upgrades for going to Windows Server 2012 R2 – performing an in-place upgrade, or creating a new server and migrating over the applications/data. While some administrators are adamant that proper server upgrades –must- be done this way, or that way, truthfully, both approaches come with their own share of advantages and disadvantages. Perhaps the biggest advantage of doing an in-place server upgrade is that most upgrades can be completed in a mere two hours or less; which includes not only the upgrade itself, but also the time necessary to install all applicable Windows Updates, post-upgrade. The alternative of creating a new server and migrating over the applications/data, is typically going to take FAR longer to accomplish (but in some cases, may still be the wisest choice!). Today, we’re going to focus on some of the pesky things that might cause you some grief when doing an in-place upgrade from Windows 2008 R2 to Windows 2012 R2.
I’ve probably done about 20 of these in-place upgrades over the last year or two. So far, the vast majority of them are completed with little headache and virtually no post-troubleshooting required. Please note however, IF your server is:. Bloated with useless and unnecessary software/applications/data -or-. Experiencing technical issues or performance problems -or-. Is one of those “mystery” servers that hardly anyone knows anything about then I’d strongly advise against doing an in-place server upgrade on that server.
However, if you believe your server is still a good candidate for an in-place upgrade, here are some important things you should know about BEFORE doing an in-place upgrade in hopes of making your life as an IT administrator easier. WSUS If the server you’re planning on doing an in-place upgrade directly to Windows Server 2012 R2, and the server is currently running the WSUS (Windows Server Update Service) role version 3.2 (Windows 2008 R2 and earlier), you MUST uninstall the WSUS role before upgrading. If you do not, your WSUS installation will be completely broken afterwards and there is no known fix from Microsoft. The only known resolution is to format the drive and reinstall the operating system from scratch. I learned that one the hard way on my first upgrade. In some unexplained cases, certain MMC snap-ins will be broken post-upgrade.
This has happened to me on occasion for the File Server Resource Manager MMC snap-in, and the Network Policy Server MMC snap-in (Figure 1). The generic error message received will usually be “MMC could not create the snap-in”. This issue can be easily fixed by uninstalling the role, rebooting your server, and reinstalling the server. The configuration settings you previously had for that server role will NOT be lost however. When uninstalling and reinstalling FSRM, you still retain your quota templates as well as folder/user quotas that had been defined. When uninstalling and reinstalling NPS, the policy settings and RADIUS clients you had configured will also remain and won’t be lost.
Windows Firewall If you typically turn off the Windows Firewall services on your server, be aware that after an in-place server upgrade, you may suddenly find that the Windows Firewall services are now enabled and therefore blocking specific applications from properly running on your server. This doesn’t seem to happen every time you perform an in-place upgrade, but it’s happened enough for me to take note of it during my routine post-installation checks. In a couple days, I will post up for this article, where we will continue to identify more of those pesky quirks and gotchas that often make our lives as network or server administrators rather frustrating, often leading to us endlessly searching Google for resolution to these irritating and nonsensical post-upgrade problems. Related article.
Amazon Elastic Compute Cloud (Amazon EC2) allows customers to deploy Microsoft Windows Server 2012 R2 in a fast and dependable environment to run any compatible Windows-based solution. Using Amazon EC2 with Windows Server 2012 R2 is similar to using EC2 with prior versions of Windows Server. EC2 running Windows Server 2012 R2 provides seamless integration with existing AWS features like Amazon Elastic Block Store (EBS), Amazon CloudWatch, AWS CloudFormation, AWS Elastic Beanstalk, Amazon Virtual Private Cloud (VPC), Elastic Load Balancing, and Amazon Relational Database Service (RDS). Windows Server 2012 R2 instances are available in all Regions. The AWS Free Usage Tier includes Amazon EC2 instances running Microsoft Windows Server 2012 R2.
Customers eligible for the AWS Free Usage Tier can use up to 750 hours per month of t1.micro instances running Microsoft Windows Server for free. For more information about the AWS Free Usage Tier, please visit the page.