Windows Server 2012 & Features on Demand

If you’re anything like me, typing at a keyboard all day is about all the exercise you get.  I’ll admit it, over the last couple months I’ve packed on a couple pounds.  I just told myself, woman love the stellar I.T. body look.  A gut almost touching the edge of the desk, the hump in the back from bending over the keyboard all day.  The none stop drinking of caffeinated soda.  So how’s a guy like me suppose to drop some weight?  Exercise!  Ha, yeah that’s not going to happen, but I wonder how much liposuction costs?

It’s easy for humans, hook up a hose, and suck out all the fat.  But what about your servers?  Gigs, and gigs of data are taking up hard drive space, and as time goes by, the plumper your server will become.  Soon you’ll be left with barely any free space.  Now what if I told you there is something you can do?  A sort of liposuction for your server.  Thanks to Windows Server 2012 Features on Demand , it’s now possible.

With Windows Server, we have what’s called the WinSxS (Windows Side By Side) folder.   This folder is located in the Windows directory.  (C:\Windows\WinSxS)  The folder contains all the files that are required for a Windows installation of a feature or role.  The advantage of this folder is you can install a role, or enable a feature without the source media.  The disadvantage of this folder is, it makes your server fat!  I’m talking Gigabytes of data just sitting there waiting for the day you install a new role.  But what if that day never comes?  All that good hard drive space going to waste.  Luckily with Windows Server 2012 you can now reclaim that space with PowerShell.

Features on Demand

In Windows Server 2012, you can minimize the footprint of your installation by uninstalling the files from your WinSxS folder.  This ability is called Features on Demand.  The only catch is, if you ever would want to install a feature you removed, then you would need to access the Windows Server 2012 source files.  Okay, lets put our server on a diet.

It’s a fairly simple process to uninstall these roles or features files from disk.

1. Open Windows PowerShell as Administrator.

2. Type the following: Uninstall-WindowsFeature –Name <feature_name> –Remove

3. That’s it!

Okay so for example I would run the following command to remove DHCP WinSxS files.

 Uninstall-WindowsFeature –Name DHCP –Remove 


Run the following, if you would like to remove all the role and feature files that currently are not installed on the local server.

 Get-WindowsFeature | Where-Object -FilterScript { $_.Installed -Eq $FALSE } | Uninstall-WindowsFeature –Remove 


Don’t worry, you can reinstall these feature files at any point.  To do so, run the following PowerShell command.

 Install-WindowsFeature <featurename> -Source wim:<path>:<index> 

How do you know what index number to use?  Simple.

 Get-windowsimage –imagepath <path to wim>\sources\install.wim 


I’m running Windows Server 2012 Datacenter, so I selected “index 4”.  Now if I wanted to reinstall DHCP onto this server I would type the following command:

 Install-WindowsFeature DHCP -Source wim:d:\sources\install.wim:4 


You can alternatively reinstall a feature by using Server Manager. Run the Add Roles and Features Wizard, select what you want to install, and then at the Confirmation screen “specify an alternate source path”.


The –Source option can access the files in there different ways.

  1. Searching the location you specified during either your PowerShell command or during the Wizard.
  2. Group Policy Settings: Computer Configuration\Administrative Templates\System\Specify settings for optional component installation and component repair.
  3. Searching Windows Update

Create a Feature File Store

Before we end, I would also recommend setting up a feature file store.  Instead of searching for the media disk, just copy the Sources\SxS folder from your Windows Server 2012 installation media to a network share.  For example, \\network\share\sxs.  Then when you want to reinstall a feature, just point the –Source to your new network share.

Hopefully you now have a leaner server.  Man, all this weight lost talk has gotten me hungry.  I think its time for a Baconator!

Creating Fine Grained Password Policies

Step right up folks!  Our proven Fine-grained password policies are guaranteed to cure all your password policy problems.  We have complex passwords, for that end user that calls because their WeatherBug plugin isn’t working.  We have simple passwords, for the lazy admin who doesn’t want to type in a long complex password like the rest of his company.  Whatever you need, we have.

Okay, I’m being a little sarcastic, but you get the idea.  Fine-grained password policies are great when you need to have multiple password policies in the same domain.  By the way, I recommend all my customers make their Admin’s use complex passwords that change quarterly.

What should you know about FGPP’s?

First off, your domain functional level must be at Windows Server 2008.  Second, Fine-grained password policies ONLY apply to user objects, and global security groups.  Linking them to universal or domain local groups is ineffective.  I know what you’re thinking, what about OU’s?  Nope, Fine-grained password policy cannot be applied to an organizational unit (OU) directly.  The third thing to keep in mind is, by default only members of the Domain Admins group can set fine-grained password policies.  However, you can delegate this ability to other users if needed.

Create a New Password Settings Object (PSO)

Okay, we talked about what you should know, but let’s now talk about the different ways you can create a Fine-grained password policy.  I’ll admit it, creating a new Password Settings Object on a 2008 Server is cra*…Hmm, I should use a more appropriate word here.  “Not pleasant”  Yeah, let’s go with that.  You have a couple of options, ADSI Edit or PowerShell.  Let’s use ADSI Edit first.

ADSI Edit:

1. Click on Start, Run, type Adsiedit.msc and click on OK.

2. Connect to Default naming context.


3. Expand CN=System,DC=Contoso,DC=com  (Replace DC=Contoso,DC=com with your domain)

4. Right click CN=Password Settings Container and select New, Object…


5. It will launch Create Object wizard.


6. Confirm msDS-PasswordSettings class is selected and click Next.

7. For different attributes, type the values you would like to set.  Below are the samples I used.
cn: TestPSOGroup
msDS-PasswordSettingsPrecedence: 5
msDS-PasswordReversibleEncryptionEnabled: FALSE
msDS-PasswordHistoryLength: 24
msDS-PasswordComplexityEnabled: TRUE
msDS-MinimumPasswordLength: 5
msDS-MinimumPasswordAge: 05:00:00:00 (5 days)
msDS-MaximumPasswordAge: 20:00:00:00  (20 days)
msDS-LockoutThreshold: 0
msDS-LockoutObservationWindow: 0:00:30:00 (30 minutes)
msDS-LockoutDuration: 0:00:30:00(30 minutes)

8. Click Finish to complete the creation of this object.



Now we can set all the same PSO settings using PowerShell as well.  Just remember to import the Active Directory Module into PowerShell first.  “Import-Module ActiveDirectory


New-ADFineGrainedPasswordPolicy -Name "TestPSOGroup" -Precedence 5 -ComplexityEnabled $true -Description "The PSO Test Policy"-DisplayName "Tes tPSO Group" -LockoutDuration "0.00:30:00" -LockoutObservationWindow "0.00:30:00" -LockoutThreshold 0 -MaxPasswordAge "20.00:00:00" -MinPasswordAge "5.00:00:00" -MinPasswordLength 5 -PasswordHistoryCount 24 -ReversibleEncryptionEnabled $false

Windows Server 2012:

With Windows Server 2012, you can now use the Active Directory Administrative Center to create new PSO’s.  It’s extremely simple, and if you use Fine-grained password policies, you should upgrade to WIndows Server 2012 A.S.A.P.

1. Open Server Manager Dashboard, click on Tools Menu, and click Active Directory Administrative Center.

2. Navigate to the Password Settings Container. (Domain > System > Password Settings Container)


3.  You can now either right click, and select New, and then Password Settings.  Or on the right side of the screen under Tasks select New, and then Password Settings.

4. Complete the dialog box and then click OK.


That was easy!

Apply your new Password Settings Object

So after we go though the trouble of setting up a new PSO, I guess we should apply it to someone or some group.  With Windows Server 2008, you will once again use ADSI Edit.

Windows Server 2008:

1. Click on Start, Run, type Adsiedit.msc and click on OK.

2. Connect to Default naming context.

3. Expand CN=Password Settings Container,CN=System,DC=Contoso,DC=com  (Replace DC=Contoso,DC=com with your domain)

4. Right click on the TestPSOGroup object in the details pane and select Properties.

5. Click the Attribute Editor tab and select msDS-PSOAppliesTo attribute from the list of attributes.

6. Click Edit.

7. Click Add Windows Account

8. Type the account\group name in the Select Users, Computers, or Groups dialog and click OK.

9. Click OK in the Multi-valued Distinguished Name with Security Principal Editor dialog box.

10. Confirm correct value is set for msDS-PSOAppliesTo attribute.

11. Click OK.

Windows Server 2012:

In Windows Server 2012 adding members to your PSO is extremely easy.  In the same screen where you created the Password Setting, click the add button.  After that, Type the account\group name in the Select Users, Computers, or Groups dialog and click OK.



Password Settings Precedence

When we created our Password Settings Object, we set the “Password Settings Precedence”.  The Password Settings Precedence is a number you assign to the PSO incase multiple PSOs are applied to a user or group object.


PSO-A with a Precedence of “5”
PSO-B with a Precedence of “6”

You have both Password Settings Objects (PSO-A & PSO-B) applied to the same user.  Which PSO would the user inherited?  The answer is “PSO-A”, since it has the lower Precedence number.

What if both PSO’s have the same precedence number?  In that case, the PSO with the smallest globally unique identifier (GUID) is applied.

It is recommended that you assign a unique Password Settings Precedence value for each PSO that you create.

Hopefully now you feel comfortable working with Fine-Grained Password Policies, and you will use them for good and not evil.  Overall you should try and limit the number of PSO’s defined.  This is due to the additional overhead for your admin’s in creating and managing PSO’s.  Along with explaining to end users why Sue’s password policy is different then Ed’s policy.