GPO

Preparing Certificates and GPOs for System Center Update Publisher

If you are using Configuration Manager to manage and patch your client estate then you already know that it’s great to have your Software Updates in the same console as your Application Delivery and the way in which Configuration Manager 2012 R2 manages Software Updates is a big leap on usability over Configuration Manager 2007 however the missing piece of the puzzle for many is managing non-Microsoft updates and for that, we need to enlist the help of a free product from Microsoft called System Center Update Publisher.

Before we start anything with Configuration Manager, WSUS or SCUP however, we do have the small matter of prerequisites to cover off and in this case it requires a certificate and a Group Policy setting or two. The certificate we are interested in is a Code Signing certificate which unless you are familiar with signing PowerShell scripts that you author, you may not have come across previously and your internal CA may not be setup to issue. You can buy these certificates for Code Signing from an external third-party CA if you wish but it is easiest and best done internally as after all, the code you are going to be signing is for updates to your internal clients.

Creating the Code Signing Certificate Template

On your Certificate Authority, we need to configure it to issue a Code Signing certificate. You can either use the native Code Signing template or you can create a custom template just for SCUP so that you can limit the scope of the certificate template to selected users or a group of users accordingly. If you want to create a new template then duplicate the existing Code Signing certificate for the purpose.

Once you have decided on the template to use, configure the CA to issue the certificate. In my lab, my template is called SCUP Code Signing and the security on the template limits users in an Active Directory Group called SCUP Code Signing Users to being able to Enroll the certificate which prevents users, malicious or otherwise from requesting the certificate.

SCUP Code Signing CA Template

Request the Code Signing Certificate

Once you have configured everything on the CA, you need to request a certificate based on this template. Using the Certificates MMC snap-in for your user account, you can request to enrol the certificate from your Active Directory Enrollment Policy.

SCUP Code Signing Certificate Request

If you based your new Certificate Template on the Code Signing template or you used the Code Signing template, you don’t need to enter additional information and the request will be built from Active Directory user attributes. Once you have created the certificate, you need to export it twice. For the first export, export the certificate only in .cer format and do not export the private key. This portion of the certificate will be used in the Group Policy Object shortly. The second export is required to be in .pfx format and include the private key and is used in SCUP for configuring it once installed.

Configure the Trusted Publishers Group Policy Setting

Once you have issued the certificate and you have exported it twice; once as a .cer file and once as a .pfx file, we need to configure the Group Policy for the Trusted Publishers. Put simply, in order for your client PCs to install updates that are not signed by Microsoft, the clients need to trust the updates. In order for the updates to be trusted, they need to be signed with a certificate that the clients trust. Having a certificate from your internal CA isn’t enough for this though. Once you have a certificate, a client will trust it as it is from a Trusted Root Certification Authority but it will not be trusted for code signing unless added to the appropriate certificate store.

Using ether a new Group Policy Object or an existing object which contains your other Certificate Services related settings, we need to add the .cer certificate exported earlier to the policy.

Trusted Publishers GPO Setting

Within the Group Policy Object, expand the Computer Configuration folder and then drill into Security Settings followed by Public Key Policies. Within the Public Key Policies folder, open the Trusted Publishers folder. In here, you need to import the Code Signing certificate .cer file that was previously exported. Doing this allows your clients to trust updates signed with this certificate for the publishing of software and applications.

Make sure you use the .cer export and not the .pfx export here as we only want the clients to have and trust the public key portion of the certificate. Distributing the .pfx would give these clients the private key also and that would be bad to have sent throughout the entire environment on every machine linked with the GPO.

Next, we need to change one setting in relation to the Windows Update Agent on the clients. In the same GPO or in another GPO if you have one dedicated to Windows Update related settings, navigate to Computer Configuration, Administrative Templates, Windows Components, Windows Update. Here, you need to change the status of the Allow signed updates from an intranet Microsoft update service location setting from Not Configured to Enabled. This second setting allows the Windows Update Agent to actually detect and download updates from your WSUS and SCCM environment if they are not signed by Microsoft and this setting is paired with the Trusted Publisher certificate above to make non-Microsoft updates trusted on the client.

With these all the above completed, you are now set and ready to deploy System Center Update Publisher and a follow-up post I will be publishing soon will cover the SCUP installation and setup.

Repairing the DirectAccess Group Policy WMI Filters

When you configure your first DirectAccess server in an Active Directory domain, the wizard will automatically create for you two Group Policy Objects. One of these policies applies to the DirectAccess servers and the other to the DirectAccess clients. I’m in the process of setting this up on my Windows Server 2012 R2 Essentials server so my server is latest and greatest as far as operating system version goes and even to date, it appears that the WMI Filter created for the Group Policy Object has not been updated.

Here is the WMI Filter in it’s default state:

SELECT * FROM Win32_ComputerSystem WHERE PCSystemType = 2
SELECT * FROM Win32_OperatingSystem WHERE (ProductType = 3) OR (Version LIKE ‘6.2%’ AND (OperatingSystemSKU = 4 OR OperatingSystemSKU = 27 OR OperatingSystemSKU = 72 OR OperatingSystemSKU = 84)) OR (Version LIKE ‘6.1%’ AND (OperatingSystemSKU = 4 OR OperatingSystemSKU = 27 OR OperatingSystemSKU = 70 OR OperatingSystemSKU = 1 OR OperatingSystemSKU = 28 OR OperatingSystemSKU = 71))

As you can see, that’s a pretty long filter, one which is going to take some time to enumerate on a client. Secondly, the filter only calls out Version 6.1 and 6.2 which like a previous post I wrote about the problems with the WMI Filter in the Windows Server 2012 Essentials Client GPO WMI Filter, it excludes Windows 8.1 (Version 6.3).

These aren’t the only problems though. ProductType = 3 means server (per MSDN WMI Win32_OperatingSystem guidance at http://msdn.microsoft.com/en-us/library/aa394239(v=vs.85).aspx) which means that the policy will never apply to a client machine as intended. The OperatingSystemSKU filter section means that this policy is valid for all sorts of crazy product SKUs that we just aren’t interested in (a full list of SKUs can be found at http://techontip.wordpress.com/tag/operatingsystemsku/).

I’ve modified this query down so that it will apply to Windows 7 and upwards instead of explicit versions and also simplified it so that it only applies to the SKUs that we might actually be interested in.

Simply clear out the current filter and replace it with the following:

SELECT * FROM Win32_ComputerSystem WHERE PCSystemType = “2”
SELECT * FROM Win32_OperatingSystem WHERE (ProductType = “1” AND Version >= “6.1%”) AND (OperatingSystemSKU = “4” OR OperatingSystemSKU = “27”)

Now, the policy will apply to computers of class PCSystemType 2 which defines a mobile computer, ProductType 1 which defines a workstation device, Version 6.1 or higher covering Windows 7 and onwards and lastly, defines OperatingSystemSKU as 4 or 27 which singles out Enterprise and Enterprise N editions of Windows client operating systems.

Deploying Windows Server 2012 Primary Computer Setting

For companies (or homes) using roaming profiles and folder redirection, Microsoft gave you are great new feature in Windows Server 2012 called Primary Computer. This feature hasn’t been talked about that much although it really should have been. The Primary Computer feature allows you to define the primary computer for a user in Active Directory on a user object. Once applied to a user account it prevents the distribution of their roaming profile on non-primary devices and for folder redirection, disables the ability to sync the folders with Offline Files for non-primary devices.

So What is the Benefit

This is ideal for several reasons. Firstly, it helps to reduce profile corruption for roaming profile users when roaming between machines which may be running different versions of Windows or different architectures. Also for roaming profile users, it greatly improves logon and logoff times for non-primary devices. If a user is logging on to a kiosk computer for example, they don’t need their roaming profile and they probably just want to access a service or application quickly so why wait for it? For users of folder redirection, this means that the user is able to access their files when the computer is on the network and can access the file share resource which hosts those redirected folders, but they are non cached using Offline Files. For the business, this is a great security benefit as it means that somebody logging on to a temporary machine isn’t going to be caching all of those files, files which they could potentially leave on the train or in an aeroplane overhead locker. For laptops which typically have small hard disk capacities this is useful for both roaming profile and folder redirection scenarios as it means that you aren’t pulling down potentially gigabytes of data to the local machine clogging up the disk.

Implementing Primary Devices Using Active Directory Administration Center

First, launch the Active Directory Administrative Center and navigate your OU structure to find the computer object for the computer that you want to make primary for a given user, or if you already know the machine name, use the search feature to locate it.

Primary Computer Finding Distinguished Name

From the computer account object, scroll down to the bottom of the view and select the Attribute Editor tab. Scroll through the list of attributes to find the distinguishedName attribute and select the View button to show the full DN.

Primary Computer Copy Distinguished Name

On the String Attribute Editor, right click the pre-highlighted text and select the Copy option from the context menu. Cancel out of the Attribute Editor and cancel out of the computer object view.

With the DN of the computer now in the clipboard, find the user that you want to make this the primary computer for either by searching or again, navigating your OU structure.

Primary Computer Set User msDS-PrimaryComputer

On the user account, do as we did with the computer account a moment ago, scroll down and select the Attribute Editor tab. Scroll through the list of attributes until you locate the msDS-PrimaryComputer attribute then click the Edit button. Right-click in Value to Add box and select Paste from the context menu to paste in the DN of the computer then select the Add button.

Click OK to close the Multi-Valued String Editor dialog then click OK to exit out of the user account properties. Your work here is done.

Implementing Primary Devices Using PowerShell

Out of the box, there is actually no neat way of implementing Primary Devices using PowerShell. To do it, we have to plug a few Cmdlets together. Firstly, get the attributes for the computer and store them in an object. $Computer = Get-ADComputer Computer1 (where Computer1 is the name of the computer). Next, we map the computer that we just stored in the $Computer object to the user. Set-ADUser User1 -Add @{‘msDS-PrimaryComputer’ = “$Computer”} (where User1 is the name of the user). With those two Cmdlets out of the way, the partnership between the user and the computer should now be done, but we can verify this with the following Cmdlet. Get-ADUser User1 -Properties msDS-PrimaryComputer

Configuring Folder Redirection and Roaming Profiles

Now that we’ve setup Primary Computer attributes for some users, it would probably be a good idea if our Group Policy settings for Roaming Profile and Folder Redirection actually honoured these settings and only transferred out the data to the users’ primary computers. The setting for Folder Redirection is available as both a User Setting and a Computer Setting in Group Policy whereas the Roaming Profile setting is only available as a Computer Setting. Because of the fact you can’t apply both of these policy settings from a single policy if you decide to use user targeting, my advice is to apply this as a computer policy. It makes good sense to keep these two settings together as it means you can see that you are applying the Primary Computer setting to both roaming profiles and folder redirection in one view and it means you can give your Group Policy Object a meaningful name like Primary Computer Roaming Settings or the like.

From the Group Policy Management Console, navigate to the Computer Configuration > Administrative Templates > System. From the System node, you will find the Folder Redirection and User Profiles nodes.

Inside the Folder Redirection node, enable the Redirect folders on primary computers only policy setting. Inside the User Profiles node, enable the Download roaming profiles on primary computers only setting.

Active Directory and the Case of the Failed BitLocker Recovery Key Archive

This is an issue I came across this evening at home (yes, just to reiterate, home), however the issue applies equally to my workplace as we encounter the same issue there.

One of the laptops in my house incorporates a TPM Module which I take advantage of to BitLocker encrypt the hard disk and using the TPM and a PIN. This gives me peace of mind as it’s the laptop used by my wife who although doesn’t currently will likely start to take her device out on the road when studying at university.

Historically, I have used the Save to File method of storing the recovery key, storing the key both on our home server and on my SkyDrive account for protection, but as of our new Windows Server 2012 Essentials environment, I wanted to take advantage of Active Directory and configure the clients to automatically archive the keys to there.

The key to beginning this process is to download an .exe file from Microsoft (http://www.microsoft.com/en-us/download/details.aspx?id=13432). I’m not going to explain here how to extend the AD Schema or modify the domain ACL for this all to work as that is all explained in the Microsoft document.

Following the instructions, I created a GPO which applied both the Trusted Platform Module Services Computer Configuration Setting for Turn on TPM Backup to Active Directory Domain Services and also the setting for BitLocker Drive Encryption Store Computer Configuration Setting for Store BitLocker Recovery Information in Active Directory Domain Services.

After allowing the machine to pickup the GPO and a restart to be sure, I enabled BitLocker and I realised that after verification in AD, nothing was being backed up. Strange I thought, as this matches a problem in the office at work however we had attributed this problem at work to a potential issue with our AD security ACEs, but at home, this is a brand new Windows Server 2012 with previously untouched ACEs out of the OOBE.

After scratching my head a little and a bit more poking around in Group Policy, I clocked it. The settings defined in the documentation are for Windows Vista. Windows 7 and Windows 8 clients rely on a different set of Group Policy Computer Configuration settings.

These new settings give you far more granular control of BitLocker than the Windows Vista settings did, so much so, that Microsoft elected that the Windows Vista settings would simply not apply to Windows 7 or 8 and that the new settings needed to be used.

You can find the new settings in Computer Configuration > Administrative Tools > Windows Components > BitLocker Drive Encryption. The settings in the root of this GPO hive are the existing Vista settings. The new Windows 7 and Windows 8 settings live in the three child portions: Fixed, Operating System and Removable Drives.

Each area gives you specific, granular control over how BitLocker affects these volumes, including whether to store the key in AD DS, whether to allow a user to configure a PIN or just to use the TPM and probably the best option second to enabling AD DS archive in my opinion is whether to allow the user to select or whether to mandate that the entire drive or only the used space is encrypted. The Operating System Drives portion gives you the most options and will likely be the one people want to configure most as this is ultimately what determines the behaviour when booting your computer.

I’m sure you’ll agree that there’s a lot of new settings here over Vista and that this gives you much greater flexibility and control over the settings, but with great power comes great responsibility. Make sure you read the effects and impact of each setting clearly and that you test your configuration and if possible, backup any data on any machines which you are testing BitLocker GPOs against in the event that the key isn’t archived to AD DS and that you enter a situation where you need, but don’t have that recovery key available.

App-V Hidden Drive Letter ADM File

In our environment, our users love their drive letters, and they do so to the Nth degree. As part of a change control process, myself and a colleague have scheduled the deployment of the App-V Client across our business estate to allow us to begin provding the users with user-centric real-time streamed applications to meet their business needs.

We today discovered the true nature of our Nth degree network drive letter because after some review, it became aparent that not a single letter (beyond the usual C, D, E for local disks) was free for company-wide use which caused us pain on the inside. We came to the conslucsion that people in our business very rarely use floppy disk drives anymore, and even less people (zero to my best guess) use a second floppy disk drive, which means that the B: drive would be available across the estate.

Using the Microsoft App-V ADM file for Group Policy (available for download from http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=25070), I re-configured our GPO to force the clients to use the B: drive instead of the App-V default Q: drive. I tested the configuration change on my own machine (ICT dogfooding for everyone), and also streamed a couple of applications to verify the drive letter change didn’t cause any issues, and I came to an idea. If the App-V virtual file system is inaccessible by the user because of the ACLs that App-V applies to it, and because the user has no reason to be meddling in the App-V virtual file system drive, why, display it to them?

I took a look at the Windows Explorer, Hide these specified drives in My Computer policy in the User Configuration portion of Group Policy however for reasons beyond me, Microsoft only gave you a very limited set of options in this policy (Hide A, Hide A and B, Hide A, B and C, or Hide All Drives). This policy was probably useful in the legacy days where you only wanted to restrict use of local floppy disk drives, however it’s not very useful in the 21st century.

The way around this, is to build your own custom ADM file to change the options for disabling the drive letters.

I have this evening created a custom ADM file for such a purpose, and in my example, the file is crafted to allow you to hide the B drive, or no drives, however you can add as many options to this file as you like.

How you configure the file to restrict particular drives is based on a binary value using a reverse alphabet table. Details for calculating this can be found on the Microsoft Support article Using Group Policy to Hide Specific Drives (http://support.microsoft.com/kb/231289). If you aren’t ocomfortable trying to do this in your head, you can simply copy and paste the table out of the article into Notepad and do your working in there.

Simply add the ADM file to an existing GPO and link it to an OU which contains users in AD, and you’re all set.

If you want to only restrict a single letter, then you can simply edit my file by modifying the label for, and the binary value for the BOnly item. The file is shared and free for you to download from my Windows Live SkyDrive account. I’m also happy to take comments or answer emails with questions about how to modify the file.

The Tiny and The Behemoth

Last week I was having a discussion with a colleague (@LupoLoopy) regarding Group Policy processing times and the ago old question of do you create a small handful of behemoth GPOs, or do you create lots of small targetted GPOs for specific purposes?

In this iteration of the debate, I was on the side of small and targetted and my colleague was on the side of the behemoth.

After the discussion, I did a bit of online digging, and turned up a post on the TechNet Magazine at Microsoft by Darren Mar-Elia, a Group Policy MVP. The outcome of the article is that, in his opinion, and based on research by using User Environment timers for monitoring the processing of Group Policy objects, small and targetted seems to be the best strategy.

When a GPO is updated with a change by an administrator, the client will have to process all of the settings within the GPO to determine which settings have changed and determine which settings it needs to apply, however in small and tightly targetted GPOs, there are much fewer settings per GPO which means even in a high churn Active Directory environment, fewer client-side settings need to be re-evaluated.

In largely static environments where there is a very low rate of churn, it could be entirely suitable to use fewer larger GPOs to apply larger configuration setts in bulk, however this will depend on the environment, and following the advice in the link below will allow you to determine the best scenario for your environment.

For anyone interested in reading the full article, you can see it at http://technet.microsoft.com/en-us/magazine/2008.01.gpperf.aspx.

Domain Problems in Windows 7 RC1

So it seems there are some problems with Domain Membership in Windows 7.

I formatted, installed and joined a Windows 7 RC1 x86 machine at home to the domain at home over the weekend, and me being me, I have quite a lot of GPO’s that apply.

After joining the clients to the domain, if you enter the username and password to logon, once the logon process begins, an error is shown that explorer.exe cannot start. There is a thread running on the TechNet forums for this issue.

Some of the posts on the TechNet forums seem to suggest the Restricted Groups component is at fault here, when trying to control the Administrators groups members on the client, however I don’t believe this is the issue.

For the client in question, I added a new OU called WindowsSeven and moved the client to this OU after setting the Block Policy Inheritance setting. After doing this the client logged in ok. After this I wanted to get the AV software deployed to the client, so I linked my software deployment GPO’s to the new OU, and at reboot the explorer.exe error returned.

I’ve since moved the client back down to Vista, but I will be building a Windows 7 VM to play with which policies may be causing the issues – Keeping you posted as always.

The Case of the Broken Default Domain Policy

So over the last couple of days, I decided as part of my server virtualization project at home with my new hard disks, I would rename the domain to something more suitable.

I found a tool on the Microsoft site called rendom.exe along with a few other tools for renaming a domain. I read all of the instructions and had a plan set out for doing it, and the process was fairly painless due to only having one Domain Controller, so there was no need to wait for forest and domain replication to take place.

Read more…