Extended Validation (EV) with an Internal Certificate Authority

As IT Pro’s, we know that Extended Validation or EV on web server certificates doesn’t actually add a security layer or harden our web servers in any way but it does give users the warm fuzzy feeling that the website they are using is definitely trustworthy and given that we want our users to believe everything we do internally in IT is trustworthy, it would be great to have our internal web services use Extended Validation certificates for user facing websites.

If you are using a Windows Active Directory Certificates Services (ADCS) certificate authority for issuing your certificates then the great news is that we can do this and it can be made to work in an existing environment so you don’t need to build a new Root CA or setup new servers for it to work, we just need to create a new Certificate Template and a Group Policy Object in the domain.

Configure the Certificate Authority

The first step is to create the Certificate Template. On your ADCS server where you issue your Web Server certificates, open the Certificate Authority MMC console. From the console, right-click on the Certificate Templates folder and select Manage.

Manage Certificate Templates

Once you have clicked this, another window will open with the list of Certificate Templates configured in the environment. Find the Web Server certificate, right-click it and select the Duplicate Template option.

New Template Properties

At the Properties for New Template dialog, enter a display name that is appropriate such as “Web Server with EV” or “Web Server Extended Validation”. From here, click the Extensions tab.

New Template Properties Extensions

On the Extensions tab, highlight the Issuance Policies list item and select Edit. At the window which appears, select the New button to add a new Issuance Policy.

EV Issuance Policy

Give your new issuance policy a name such as “EV Issuance Policy” and if you have one (which you should do for production) enter your Certificate Purpose Statement URI. If you don’t know what a Certificate Purpose Statement (CPS) is then I would suggest the TechNet article Certificate Policies and Certificate Policy Statements as a first primer however in a nutshell, it’s a webpage which gives people information about how the certificates can be used.

Before you hit OK on the New Issuance Policy dialog, note the final field OID. Copy this OID to your clipboard and keep it their for the time being or better yet, save it to a text document in a safe place as we need this for the steps later.

Once you have this, hit OK on the dialog and change any other settings on the template you may need to such as the validity period, the key length or whether you want to allow the private key to be exported. Once you have created the new template, we need to configure the CA to be able to issue it.

CA Certificate Template to Issue

As shown above, back in the Certificate Authority console, right-click on the Certificate Templates folder and this time, select New followed by the Certificate Template to Issueoption. From the list of templates, select the new template you just created for Web Server with Extended Validation.

After this, the Certificate Authority is configured with a new template that can be used for Extended Validation and the CA is configured to issue certificates based on that template however it’s no good having the certificates if the clients do not know to trust it to the extent required to display the green address bar.

Configure Group Policy in Active Directory

With the CA configured, we need to configure clients to trust this certificate for Extended Validation and the best method for this is going to be Group Policy. If you have an existing Group Policy to apply certificate related settings then use that policy otherwise create a new one and link it either at the root of your domain to apply it to all computers on the domain or to a particular OU if you only want it to apply to sub-set of clients. Just for clarity, I would not recommend putting certificate related settings in the Default Domain Policy nor would I recommend putting any settings into that policy. The Default Domain Policy and the Default Domain Controllers Policy should be left untouched and new policy objects should be created for any settings you want to apply.

In your Group Policy Object, expand the view in Computer Configuration followed by Security Settings, Public Key Policies and finally Trusted Root Certification Authorities. If you are using an existing policy, you should have here a valid copy of the public key portion of the certificate for your Root CA. If you are creating this as a new policy, you will need to import the public key portion of your Root CA certificate.

GPO Trusted Root Certificataion Authorities GPO Trust Root CA Extended Validation Properties

Once your certificate is added, right-click it and select the Properties. From the properties, you need to select the Extended Validation tab. On this tab, add the OID that you earlier copied or saved to a text document. Any OIs in this list are considered trusted for Extended Validation when a certificate contains the Issuance Policy matching that OID and the certificate issued by a CA that is part of the issuing or subordinate chain below the specified Root CA.

Once you have applied the GPO to your clients, you can issue a new certificate for a web site with the Web Server Extended Validation template and when browsing to that site from a client computer which both trusts your Root CA and understands the OID applied to the Issuance Policy, you will get the green address bar.

Website with EV Certificate

WMI Filter Features on Demand GPO

Last week, Yung Chou from Microsoft put up a post about using Group Policy to provide Features on Demand for Windows Server 2012 R2 and how this can help in restricted environments where servers don’t have access to Windows Update to retrieve on-demand features such as .NET Framework 3.5 or where you don’t want to be left manually providing UNC paths to operating system media.

This is certainly true, and even if you aren’t in a restricted environment this is worthy of doing because it makes it much easier for administrators to add certain roles and features to Windows Server however the one point that was missed from the post is that you will probably want to WMI Filter this Group Policy Object so that only Windows Server 2012 R2 operating systems will be able to read it and apply the policy setting.

I’m not going to walk through the process of creating a WMI Filter and applying it to a GPO as that’s pretty simple stuff but finding the right query to craft can sometimes be a challenge so here you go:

SELECT ProductType, Version FROM Win32_OperatingSystem WHERE (Version LIKE "6.3%") AND (ProductType = "2" OR ProductType = "3")

This query will pick out Windows Server 2012 R2 with the Version LIKE 6.3% syntax however this alone would also resolve true on Windows 8.1 client machines so the addition of ProductType equals 2 or 3 means that only server types will be matched.

This filter can be used for targeting any GPO that requires Windows Server 2012 R2 specifically. If you wanted to craft a WMI Filter which explicitly calls out Windows 8.1 instead then simply replace ProductType 2 or 3 with ProductType equals 1.

 

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.

Windows Server 2012 Essentials Folder Redirection on Windows 8.1

As all good IT Pros have done, I’ve upgraded my home client computers from Windows 8 to Windows 8.1. You have upgraded your machines to Windows 8.1 right?

As I frequently proclaim and preach on here, I run Windows Server 2012 Essentials on my home network, acting as my DNS Server, DHCP Server in addition to the out of the box features that you can get from Windows Server 2012 Essentials like roaming profiles, folder redirection, automated computer backups and network file sharing (all of which I use).

When I was building out a test environment this week to practice how I might migrate from Windows Server 2012 Essentials to Windows Server 2012 R2 Essentials without the benefit of a second server with 19TB of available storage to hand (how many homes do have 19TB of storage let alone a spare 19TB) I was experiencing an issue.

As part of my testing, I built a Windows 8.1 Pro virtual machine to simulate a desktop or laptop client computer. I built a Windows Server 2012 Essentials server as a second virtual machine on which I recreated my group policy settings and a mock up of my Storage Pool and Storage Spaces on my production server. After installing the Windows Server 2012 Essentials Connector on the Windows 8.1 client and logging in for the first time as a user configured to use roaming profile and folder redirection, I noticed that the roaming profile was working but the folder redirection was not.

I spent a while pouring through event logs on the client wondering why folder redirection wasn’t working, looking at GPMC (Group Policy Management Console) wondering if I’d done something silly like moved a link on a GPO preventing it from working until the penny dropped. Windows Server 2012 Essentials applies a WMI Filter named SBS Group Policy WMI Filter to the SBS Group Policy Folder Redirection GPO which is created when you implement Group Policy via the Server Dashboard.

Windows Server 2012 Essentials Original WMI Filter

This WMI Filter is setup as SELECT * FROM Win32_OperatingSystem WHERE (Version LIKE “6.1%” or Version LIKE “6.2%”) AND ProductType = “1”. For those who are now also dropping the penny or those who can’t make head nor tail of a WMI Filter, Windows 8.1 increments the operating system version number from 6.2 (Windows 8) to 6.3 (Windows 8.1), therefore the GPO isn’t applying to any of the Windows 8.1 machines on my network because this filter limits the scope of the Group Policy Object to explicitly Windows 7 and Windows 8 operating systems.

The solution to making this work is pretty simple in that we just need to update the WMI Filter so that it includes Windows 8.1 as we know that basic features like roaming profiles and folder redirection are going to work so I’m not worried about something breaking here.

I’ve decided to change my WMI Filter to include operating systems greater than or equal to Windows 7 rather than add another or statement to include Windows 8.1 For me, the WMI Filter now reads SELECT * FROM Win32_OperatingSystem WHERE (Version >= “6.1%”) AND ProductType = “1”.

Windows Server 2012 Essentials New WMI Filter

 

After making the changes and running a gpupdate command on a Windows 8.1 client computer, the group policy magically springs back into life and things start working. Firstly, I’m amazed that I haven’t noticed this being a problem on my home clients which I guess is a testament to my gigabit throughout home network pushing the files directly back to the server rather than caching them locally with Offline Folders first. Secondly, I’m surprised that this hasn’t been updated with a patch or update to Windows Server 2012 Essentials but perhaps this is a cattle prod for customers to upgrade to Windows Server 2012 R2 Essentials?

Office 365 Setup and Windows Server 2012 Essentials

Something which I’ve never really talked about here is email. Me and my family currently consume Outlook.com via Windows Live Domains on both my blog domain richardjgreen.net and our personal domain name. Windows Live Domains really feels like something out of a Land Before Time movie these days. It hasn’t seen an update in years and frankly, I wonder what the shelf life of it is going forwards, leaving me to think that the options will be Outlook.com, Office 365 or bust. Not wanting to be stuck on a potentially end of the road email platform, left trying to move the mail service for my family on day zero, I started looking at options a few months back.

With Windows Live Domains being free, if I was going to pay for email, I needed it to not cost the earth, as low as possible really. At the same time, I didn’t really want anything more from a feature set than I get with Outlook.com via Windows Live Domains.  All I want is a flat service to match that of Windows Live Domains and Outlook.com. With me being such a softie, the option was really only going to be Office 365, it was just a question of what tier and flavour of it.

Windows Server 2012 Essentials which I use to run our home environment has native integration for Office 365 which means it would be super easy for me to manage which for me is great as the less time I spend managing our home solution, the more time I can spend blogging, working on other things and spend more time with the family themselves.

Exchange Online vs Office 365

This really confused me when I started looking into Office 365 and using the Windows Server 2012 Essentials integration features for Office 365 sometime ago. For me and my family, I am only interested in email. I’m not after Lync or SharePoint services as we just wouldn’t use them. I was concerned that if I signed up for Exchange Online Plan 1 which was my target option that the integration wouldn’t work. As it turns out, you just need to think of everything as Office 365. Exchange Online, Exchange Online Protection, Lync Online, Enterprise Plans; all of them fall under the banner of Office 365 so I now knew that Windows Server 2012 Essentials wasn’t going to care if I was on Exchange Online Plan 1 or if I was on an Enterprise 4 agreement.

Extending the Windows Azure Tenant into Office 365

Because I use Windows Azure Backup to backup our data from Windows Server 2012 Essentials already and because this blog is hosted on Azure, I already had a tenant setup on an onmicrosoft.com domain which I wanted to reuse so I needed to extend my tenant so the one tenant would work across Windows Azure and Office 365 services. To do this, I logged into office365.com using the account which I setup as the tenant global administrator when I configured Azure Backup on Server 2012 Essentials. I was greeted with a message that I didn’t have any licenses or any domains setup, but the login worked most importantly.

Buy a Service Plan

Before you can credibly do anything, you need a plan. I wrote this post after I set it all up and lucky I did really. When I first went through the motions, I added a domain richardjgreen.net and was wondering why I couldn’t do anything with it, not even validate it. It looks like you can’t even validate a domain to start configuring users until you have at least one license available to use.

As it’s just me on my blogs domain right now, I paid up for a single license of Exchange Online Plan 1. This gives me a 50GB mailbox, all of the Exchange features I want like OWA and Exchange ActiveSync and at £2.60 a month per user excluding VAT, the price is sweet enough for me also.

To buy a license or more, all you need to od is to hit the Purchase Services link on the left navigation. This presents a whole host of options for Office 365, Exchange Online services to buy and some add-on services also such as Exchange Online Protection and Exchange Online Archiving. Add a credit card detail on file, click buy and it’s as simple as that.

Adding Custom Domains

Adding a new domain is a simple matter of clicking Domains from the left navigation and then clicking the Add a Domain button then follow the instructions which follow into setting up DNS. I had both of my domains added within a matter of a couple of mouse clicks and keystrokes.

Configuring the DNS Settings

As part of the process of adding the domain, you need to do two things:

  • Verify you own the domain for starters
  • Add DNS records for your services

The first step is verification which in my case, I completed by adding an MS= TXT record in my providers DNS management console. I tried to do this but I received an error “richardjgreen.net has already been verified for your account, or for another Microsoft Online Services account.”. I new I was going to see this but not quite at which stage.

This is caused by the fact that my richardjgreen.net domain was currently configured to use Windows Live Domains for email service. I logged into domains.live.com, deleted all of the mailboxes in Outlook.com for the domain and then deactivated the service. This was the most nerve racking part of the process as I’ve read that other users doing the same thing have had issues rattling on for months to get this to clear out of the system properly.

In my usual style, I kept trying the Office 365 portal to verify the domain and 15 minutes after deactivating Windows Live Domains, Office 365 pinged into life, allowing me to verify the domain.

With the first step now done, I needed to configure the service records as directed. I needed three records for my Exchange Online service: An MX record for mail delivery, a TXT record for the SPF (Sender Policy Framework, required to allow receiving servers to trust the Sender ID of outlook.com and Office 365 to deliver email on my domains behalf) and a CNAME record for Autodiscover to allow devices to be configured automatically for my mailboxes in Office 365.

If you use a DNS management agency which Microsoft have steps with then you can get direct instruction for doing this if you are little uncomfortable with DNS or if you are with GoDaddy then there is the option for an automated setup through some kind of API channel with Microsoft.

After adding the records to my DNS, it took about 10 minutes for Office 365 to pickup the new records and complete the domain setup.

Enable Office 365 Integration in Server 2012 Essentials

From my Windows Server 2012 Essentials machine, this part should have been really easy but it turned out to be a nightmare.

From the Essentials Dashboard, click Email from the home screen and then select Integrate with Microsoft Office 365. The dashboard will open a wizard for you to enter your Office 365 Tenant Global Administrator account if you already have an account as I do otherwise you have the option to initiate a free trial using an E3 subscription.

The Office 365 integration with Server 2012 Essentials is neither DirSync nor is it ADFS. If you elect to use Office 365 with Lync and SharePoint you will not get the AD FS Single Sign-On (SSO) experience as you would with a full deployment. The integration here I would describe as light. When you provision users on-premise, make changes to Office 365 licenses or mailboxes through the Dashboard, the changes are pushed up to Office 365 via a web channel which you can see from the logs (explained later).

Password synchronisation does occur so that your on-premise password and Office 365 password are in alignment however. I found this happened really quickly and my Windows Phone would report a password change required on the Office 365 email account on the phone within about a minute or so of the password change on-premise.

When you enable the integration, one of the things that occurs is that it forces you to enable Strong password mode on-premise which results in passwords at least eight characters in length and passwords using symbols and all the tricks in the book. Whilst I agree this is something you should be doing, if you are a small business or a home user availing of the services of Office 365 like myself, this isn’t perhaps going to be ideal. Luckily, the password policy in Office 365 is actually less strict than this. I have gone under the covers using Group Policy Management Console (GPMC) in my setup and slightly amend the Default Domain Policy GPO and all my passwords sync okay still.

The Office 365 Integration Service Gone Bad

After I ran the initial setup integration for the first time, I stopped getting any data in the dashboard. I thought it may have been a result of some pending Windows Updates so I installed those and restarted but it was still broken. I found that the problem was that the Office 365 Integration service was stopped. I started in manually and it stopped immediately with a stack trace error in the Application event log which wasn’t particularly cool.

I tried to disable the integration so that I could then re-enable it, but it appears that any operation regarding the integration requires the service to be functional. I tried to re-run the configuration but I was informed that it was already configured and I would need to disable it first which didn’t help me.

The way I got around this was to force the service to be disabled via the registry. Open Registry editor and navigate to HKLMSOFTWAREMicrosoftWindows ServerProductivity. From here, delete the key MailService and then restart the dashboard application. Doing this makes it think that the Office 365 Integration is disabled even though the dashboard will show the green tick to indicate that it’s configured. Simply re-run the configuration wizard at this point and all appears to be working now.

The Office 365 Integration Service Gone Bad Mark II

After the above happened and it all looked like it was working, I wasn’t getting password sync up to Office 365 although the Dashboard was functional to a point of allowing me to configure mailboxes. I found that the Password Sync service generates a log file in C:ProgramDataMicrosoftWindows ServerLogsSharedServiceHost-PasswordSyncProviderServerConfig.log.

Upon reading this file, I was seeing WCF errors and unhandled exceptions every few seconds which hinted to me that even though I had been able to repair the integration as far as the service health and the Dashboard were concerned, something was still amiss. I opted to this time, use the Dashboard to disable the integration, restart the server and re-configure the integration as I was now able to do this with the service for the Office 365 Integration running okay.

After removing it all and adding it again, everything worked as intended.

Configure Users

You can either do this via the Windows Server 2012 Essentials Dashboard or directly in Office 365. I’d recommend doing it in the Dashboard if you are using Essentials otherwise you have a second step to link the cloud mailbox to the on-premise user account.

To setup a user, very simply, go to the Users tab in your Dashboard. Click the user you want to activate for Office 365 and select the Assign Office 365 Account option from the tasks on the right. Pick the email address for the user using either the onmicrosoft.com or the vanity custom domain you have configured and then click Next. If you have a license available to allocate to the user, it will be setup for you. If you don’t have a free license slot then you’ll need to buy one from the site office365.com.

One thing worthy of noting is that once you enable a user for Office 365 in this way, Windows Server 2012 Essentials will set the change password on next logon flag for the user to force them into a password change with a new password for the cloud which can then by synchronised up to Office 365 for that single password login experience.

ExRCA is Your Friend

Through all of this, testing everything is working is critical. Office 365 does a good job of telling you when you’ve got things configured properly, but ExRCA or the Exchange Remote Connectivity Analyzer is better as it’s a tool dedicated for the job. Visit http://exrca.com and click the Office 365 tab and run any of the tests you like to make sure things are working. Some tests need only your domain name to verify settings such as DNS records whereas others need a credential to simulate a synthetic transaction to a mailbox or account.

I found when testing my setup that everything is reported as working but Autodiscover fails every time. When you drill into more information this is caused because the certificate name presented by the CNAME redirect from autodiscover.richardjgreen.net to autodiscover.outlook.com means that the outlook.com certificate doesn’t have my domain name on it. My Outlook and Windows Phone clients still Autodiscover the service correctly so I think this is a by-product of the Office 365 configuration and not a problem as I’ve found literally hundreds of other people asking about failed Autodiscover tests on the TechNet forums.

Client Experience

One thing I discovered which isn’t hugely clear in the documentation is that I wasn’t able to configure Outlook 2013 or my Windows Phone for ActiveSync until after I had logged in for the first time at office365.com using the account I issued my license to and configured the mailbox. You are prompted with a couple of questions such as confirming your name and time zone logging in for the first time.

After doing this online piece, Windows Phone started to sync the mailbox using ActiveSync okay, and Outlook 2013.

What’s Next

Well first I have some mail service consumers to address. I’ve got quite a few family members using Windows Live Domains with Outlook.com on our personal family domain name which I don’t fancy paying for Office 365 for so I’m going to have those tough conversations over do they want to pay for their own Office 365 mailbox or do I help them move to Outlook.com natively using a non-vanity domain. Whichever way it happens, I’m going to be looking at manual mail migrations out of Outlook.com to Office 365 for these users as there isn’t a migration path for this right now.

One thing I will be doing once I move my personal family domain over to Office 365 is implementing the Outlook Group Policy .admx files to allow Outlook to auto-configure the email address from Active Directory on first-run so that my wife and, in the future, kids don’t have to manually enter those details. It’s something I have come to expect from enterprise environments so I feel I owe them that simplicity factor enterprise computing can bring.

The kids have mail addresses right now but they aren’t live, they are aliases on our mailboxes as parents so I’m going to be looking at shared mailboxes for these to make them one step closer to full service mailboxes and I’m also going to be looking into settings up some MRM policies in Office 365 to apply to our mailboxes to keep them trim and reduce the amount of overwork we have to do to maintain the storage of it although frankly, with a 50GB mailbox, do I care?

Longer term, I may look at the option to spend an extra 65 pence a month per user and sign up to Exchange Online Protection to stem the flow of nasty emails as not everyone is as savvy as someone in IT and that’s why these services exist. It’s another one of those things for me where 65 pence per month could potentially lead to hours and entire evenings saved, not having to repair a PC after a virus got installed via an email attachment.

In more posts to come, I’ll show how I’m configuring some of the features and settings in Office 365 and I’ll talk about how I plan to upgrade my estate to Windows Server 2012 E2 Essentials to get some of the new integration and management features for Office 365 in the dashboard along with other new features.

 

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.

Controlling Configuration Manager Clients Across WAN Links

At work this week, we encountered an issue when a package I created for Adobe Reader 10 went mandatory in Configuration Manager. We service retail stores connected via slow WAN links back to our head offices. When I first joined the company, on a monthly basis when new Windows Updates were released into the wild, our network team would come down upon our team, fire wielding whilst we raped and pilaged the lines to stores.

Configuration Manager gives you the power to create BITS (Background Intelligent Transfer Service) policies to throttle the bandwidth that will be consumed by SCCM client transfers for packages and patches, however the problem with Configuration Manager is that it’s policy is not granular, it is singular which means to apply a policy of 32KB/s which we needed to do to facilitate stores, you would also be limiting the speed of head office clients connected to 100 Megabit or 1 Gigabit high speed LAN connections.

Group Policy also gives you the ability to configure BITS throttling policies and in actual fact, Group Policy gives you more options to control the granularity plus the fact that you can link Group Policies to OUs and not just entire domains, or sites, allows us to control the speeds in a more appropriate way.

In a Group Policy Editor window from Group Policy Management Console (GPMC), navigate to Computer Configuration, Administrative Templates, Network, Background Intelligent Transfer Services (BITS). From here, enable the Limit the Maximum Network Bandwidth for BITS Background Transfers setting and configure the speeds and times as you need. You can also configure an out of hours policy which we make use of, limiting the store clients to 32KB/s between 8am and 6pm daily, but allowing them to expand to 256KB/s overnight when the store is closed, not making VoIP calls or trying to transact credit cards.

This worked great and the next time we deployed patches we had no complaints from the stores, but instead, we had a problem at the head office. The problem had not been manifested previously as we had to delay patch deployments before the packages reached everyone, but the issue we experienced now was that due to the length of time a Configuration Manager client was connected to the Distribution Point downloading packages, we were now seeing prolonged connections to the IIS site on the Distribution Point and lots of 64KB/s connections makes lots of bandwidth – We were now actually consuming all of the bandwidth at the head office site, causing inter-site applications between our two head offices to crawl.

We found a solution to this problem in IIS. The solution probably isn’t recommended by Microsoft or any System Center consultants out in the wild, but it works for us and causes no side-effects that we’ve witnessed in the year or so that it has been in place, so it has withstood the test of time.

Using IIS Manager on the Distribution Point server, expand the Default Web Site. From the Actions pane on the right hand side of the interface, select Advanced Settings. From the Advanced Settings dialog, expand the Connection Limits group under the heading Behaviour. By default, IIS accepts a number of connections so large is may as well be infinite. We calculated that based on our free capacity on our link at the head office, taking into account the traffic required for LoB applications, we could handle about 20Mbps of client traffic. We divided the 20Mbps into 64KB/s BITS setting out which gave us a number of 320. Setting the IIS connection limit to 320 and restarting the site in IIS, we saw an instant reduction in Distribution Point server network activity and also the drop we needed on the site link.

As I have mentioned above, this was done over a year ago. In this time, we’ve had not a single complaint from stores, head office users or our network team that there are network contention issues due to SCCM traffic, nor have we seen any apparent SCCM client issues such as clients never properly reporting due to connection retry limits being reached. This isn’t to say that this fix is for everyone: You would need to factor in things like how many total clients do you have in an SCCM site, and if a client was back of the IIS queue, would it be waiting for a connection for so long that it would timeout, or do you need to be able to rapidly deploy high threat updates regardless of the impact to other LoB applications?

Since implanting these changes, we’ve had two Microsoft SCCM RAP assessments and neither have produced red or amber health status problems due to the changes to BITS and IIS, so I think we found ourselves a winner.

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.