This HOWTO covers how use the free 180 trial version of Windows Server 2012 R2 to build a reusable template for lab and development purposes.
The objective of the steps below are as follows:

• Ensure that whenever we need to deploy a new Windows Server for testing, it will always have the latest updates and customizations
• Each deployment will be sysprepped ensuring there are no SID conflicts when using multiple machines
• Allow for the latest updates and new customizations to be be added in the future without impacting already deployed test machines
• New Server 2012 R2 VMs including fresh domain controllers and domain joined member servers must be spun up as quickly as possible with as little user intervention as possible
• The process must allow for an unlimited number of Syspreps to take place
• This entire guide must be repeated every 6 months as we are using the free trial version of Windows Server 2012 R2
• Any machines deployed during the 6 month trial period will reset and start from their own 180 day counter independent of the source
• The implement will leverage the linked clone snapshot feature found in VMware Workstation

Overview

The idea behind this build is to provide the fastest possible way to build new Windows 2012 R2 Active Directory lab environments.
I’m aware there are other solutions available but I wanted to see what I could accomplish using nothing more than the 180 day trial ISO, VMware Workstation and PowerShell.
The configuration may seem a little complex but once these steps are in place, it becomes hilariously easy and fast to deploy new test servers at home for testing.
The idea is to build out a new VM using the trial, snapshot it, sysprep it and then use PowerShell scripts to automatically build new Domain controllers and join to the domain using Desired State Configuration.

Read more

I found myself curious if I could get my entire lab environment to build itself from scratch in a 100% automated fashion including deploying and configuring Active Directory.

All of the cmdlets to perform these tasks already exist in PowerShell and are trivial to perform individually.  But what happens if you want to combine them together?  In order to do that, you have to be able to manage restarts and be able to continue your script where it left off.  That turns out to be a non-trivial problem for traditional PowerShell scripts.  As I was researching how I might accomplish this, I stumbled across something called “Desired State Configuration” or DSC.  I’ve heard it talked about constantly over the last year or two and all of the major PowerShell bloggers have stated that it is the concept to learn after you’ve got the basics of PowerShell down.  I’ve never had a reason to look into it though… until now.

The first thing I did was start watching the Microsoft JumpStart series on DSC.  I just assumed it would be a module’s length but to my shock and surprise, Microsoft created an entire course on just DSC and that course is 2 full days – equal to that of the JumpStart for PowerShell itself!  The next thing that jumped out at me is that at the beginning of the video series, one of the hosts and inventor of PowerShell, Jeffrey Snover said:

“DSC is not just a priority at Microsoft, it is THE priority at Microsoft.”  That may sound like hyperbole coming from most people but remember that Jeffrey Snover is now the Technical Lead Architect for Windows Server.  So even accepting he probably meant his team specifically, that’s still a big deal for those working in IT as most of our time is spent with the products he is responsible for.

With that backstory out of the way, what exactly is Desired State Configuration and why should you care?  Here is what I’ve been able to piece together so far.  DSC is a mechanism for you to define how a server or servers should be configured.  Notice I did not say how specifically to configure them.  This is the first thing that took me a while to wrap my head around.  In DSC, you never define HOW to configure a server, only WHAT you want the final product to look like.  Think of DSC more as a manager than a programmer.

The way this is accomplished is Microsoft (and others) create something called “resources” which are effectively large, complex PowerShell modules that are written by professional programmers that contain all of the logic and error handling and dependency management that is almost always missing from amateur scripts.  You then use a special subset syntax of PowerShell to declare what you want and PowerShell will go out and do it for you.

Read more

Imagine this scenario.  You have a SharePoint 2007/2010/2013 server in your environment along with an Exchange 2007/2010/2013 server.  You have configured email-enabled lists in your SharePoint environment by leveraging an SMTP server configured on your SharePoint server along with a send connector on your Exchange server.  Everything works great and people can email an address and have their content automatically added as a SharePoint list entry.

Then you migrate to Office 365 in a full cutover migration, obsoleting your Exchange on premises server.  Your email to list functionality breaks.  What now?

I found myself in this exact situation and had to come up with a solution.  Here is what I came up with.  I won’t be covering every step here and instead will only consider high level requirements.  If you need more specific detail, please ask in the comments.

First, if you have performed a cut over migration, you likely don’t need the firewall rule you had for port 25 to your Exchange server anymore.  So the first thing to do would be to modify that firewall rule and redirect traffic for it from your Exchange server to your SharePoint server.

From there, you can do the following:

1) Modify your existing Exchange contact that is used for email to list functionality.  Change the email address from [name]@sharepoint.domain.com to [name]@domain.com where domain.com matches your primary production domain.
Next, if you are using some type of Directory Synchronization tool, perform a sync to Office 365.

Read more

Imagine for a moment you have just deployed Office 365 in your environment using a cutover migration.  Everything is working well and you’ve now decided to grant access for your users to use Skype for Business.  (I so hate that name).

You find that some users are not appearing in the Skype For Business Users control panel.  You scratch your head and Google until you come across this excellent article:

http://blog.rickzeleznik.com/2014/07/29/issues-provisioning-lync-online-users-after-dirsync/

It basically tells you that at some point in the past, someone deployed either Office Communications Server or Lync server in your environment and the users that aren’t showing up have their msRTCSIP Active Directory attributes populated which is confusing Skype for Business.  The article goes on to show you how to clear the attributes.

Now imagine you test this process and it works and solves your problem.  But then you slink into your chair when you realize you may potentially have hundreds of users to update and each user has as many as 14 attributes each that need to be modified.

That’s the situation I found myself in.  If you’ve seen any other posts on this site, you already know how I solved this – PowerShell!

I figured I’d share my solution in the event anyone else is in this situation.  This is very rough code designed to solve the immediate problem and as a result I’d suggest that you have some comfort with PowerShell before attempting to use this code.

Read more