Petri Newsletter Sign-up
Office 365 Insider

Here at, we get IT — and so can you. Subscribe today to stay informed and knowledgeable regarding the latest on IT.

    See All Petri Newsletters

    Windows Server 2012: First Five Fixes

    Posted on by Jeff Hicks in Windows Server 2012 with 3 Comments

    I think Windows Server 2012 will fundamentally change the way IT Pros manage their Windows environments. I expect many of you are already kicking the tires on Windows Server 2012 and perhaps are even running it in a limited, testing environment.

    When you first build a new system, and there are a number of ways to do it, I expect you will have a checklist of standard steps. Eventually, you will be like all the cool kids and use a PowerShell workflow, but for now I’m going to assume you will be employing a manual process.

    I assume you will do the following tasks by default when setting up a new Windows Server 2012 system:

    • Configure computer name
    • Configure networking
    • Install features and roles
    • Run Windows Update

    I’m not going to cover those as I think they are pretty self-evident in the Server Manager GUI, but I do have 5 additional “fixes” that I’ve been using. These are things that you may not think of immediately, but they will pay off down the road. My “First Five Fixes” aren’t in any order, but I’m assuming you’ve completed at least the default steps above before moving on to these.

    Note: This article is based on a pre-release version of Windows Server 2012 and is naturally subject to change.

    5. Enable PowerShell Remoting

    Windows Server 2012 relies on PowerShell remoting, and for the most part, it is now turned on and enabled by default. I may eventually change my mind on this one, but for now I like seeing for myself that remoting is enabled. Open an elevated PowerShell session and run the following command:

    You will be prompted for a number of settings. You should be able to accept the defaults as I did in Figure 1.

    Enabling PowerShell Remoting
    Figure 1. Enabling PowerShell Remoting

    But now I have visual confirmation that remoting is enabled and I know what was set. If you want to skip all the prompts, simply run:

    4. Set PowerShell Execution Policy

    Next, at least for the servers I’m setting up, I will likely need to run PowerShell scripts. I need to set my execution policy accordingly. I prefer a setting of RemoteSigned at a minimum.

    As with Enable-PSRemoting, if you want to suppress the prompts, use the –Force parameter.

    3. Update PowerShell Help Files

    Because I’m going to spend a lot of time in Powershell, and I assume you will as well, we’ll need to update the help files. PowerShell 3.0 doesn’t ship with help content, so the first time you ask for help you’ll be prompted to update it if you haven’t already. Now is as good a time as any. In the same elevated PowerShell session, run this command:

    You might get an error depending on what modules PowerShell finds on your server, because some of them haven’t been configured yet to support updateable help, or the files aren’t available yet. But you should be able to run this command:

    This should be a good indication that at least the core files have been updated.

    2. Export Feature Configuration

    Once the initial server configuration is complete, I recommend exporting it to an XML file. This allows you to re-use the XML file later to either rebuild the server, or duplicate the feature set on another server. When you go through the GUI to add a feature, there is an option at the bottom of the screen to export the file. I’ve highlighted it in Figure 2.

    Export Features
    Figure 2 Export Features
    Assuming this is the last configuration, you could click the link and save the xml file. When you want to “import” the settings, use the Install-WindowsFeature and specify the configuration file.

    1. Run Best Practices Analyzers

    Finally, on a fresh install, you’ll see warnings until you run the Best Practices analyzer for each installed role. Instead of going through the GUI and manually launching each one, we can use PowerShell. It is actually quite easy to find the best practices scan for each installed feature.

    I’m turning off the error pipeline because not everything you get from Get-WindowsFeature has a BPA. But now, it is very easy to revise this command and run the scan for each.

    When everything is finished, I can view the results in Server Manager.


    As we gain experience with Windows Server 2012 I expect this list will change slightly and certainly grow. I’ll be adding more content on Server 2012, especially once it is finally released.


    Don't have a login but want to join the conversation? Sign up for a Petri Account