Configuring IIS Redirects for HTTPS with the SCOM 2007 R2 Web Console

Whilst working with the SCOM 2007 R2 Console today, I saw that on our SCOM RMS server, the Default Web Site in IIS was running still and occupying Port 80 for no good reason, while the SCOM Console was relegated to Port 51908 which isn’t very user friendly. Additionally, the site was in the clear with no SSL, so I wanted to make the site secure.

Step 1 was to disable the Default Web Site and stop it from starting automatically. Once this is done, remove the Binding for Port 80 from the site to make that port available for use. Once you have done this, you can follow the steps per my previous post Redirecting Non-HTTPS Traffic to HTTPS for SharePoint 2007. Although the post in entitled for SharePoint 2007, it applies to any server running Windows Server 2008 or 2008 R2 with IIS 7 or 7.5, just you need to rename the websites that you create accordingly.

Once complete, users will be able to type the server name which hosts your SCOM Web Console, without needing to append the default port number, and they will be automatically redirected to Port 443 for the HTTPS version of the site, instead of an IIS error stating that they need to use the HTTPS version.

System Center Operations Manager 2007 R2 Web Console Authentication

Whilst working on something un-related today, i discovered a problem with our SCOM 2007 R2 Web Console at work – When I tried to connect to the site, I was prompted for my credentials and I provided my domain logon, but it kept coming back at me until eventually, I got a HTTP 30 Unauthorised error.

A lot of blogs and forum topics online including some at Microsoft (Example: will recommend that you configure Kerberos Delegation for the computer account which hosts the Web Console, using the credentials of the SCOM SDK Service Account.

This is my eyes was a bit of a dirty hack, and the cleanest and most obvious solution had to lie in IIS and its Authentication schemas.


Sure as could be, the OPWebConsoleApp Application Pool in IIS was configured with ApplicationPoolIdentity which in English means it’s not no permissions on the network, or has no access to the domain to verify domain credentials.

My solution to the problem is as follows.

Firstly, create a new Application Pool in IIS. Call it what you like, but this will be hosting your Operations Manager Web Console, so best to name it accordingly. I named mine SCOM 2007 R2 Web Console. I also elected not to have the Application Pool start immediately, as we need to configure the credentials on the Pool first.


Right-click on the new Pool, and select Advanced Settings. Under the Process Model group, there is an item called Identity – Click the … button on the right of the line to open the next dialog. Change the Identity to Custom Account and specify the username and password for a domain service account which can host the Pool, then click OK button you get back to the Application Pools list in IIS.

Now you can start the Pool by right-clicking and select Start. If the Pool fails to start, you need to verify that your credentials specified for the Pool were correct, and that you don’t have a Group Policy preventing that account from running as a service or such.

Now, right-click on the existing OPWebConsoleApp Applications Pool and select View Applications.


Right-click on each of the applications, and select the Change Application Pool option. You will be given a list of available Pools, and select the one which you just created.

Once complete, you need to restart Web Sites, however the easiest thing to do, is from an elevated command prompt type iisreset which will reset all of the Pools and Web Sites.

Assuming you have Windows Authentication enabled on the Operating Manager 2007 WebConsole Web Site (which you should by default) then you should now be able to successfully access the site using Single-Sign On (SSO) with no requirement to enter credentials.

For bonus points, you can be a friendly, security conscious administrator an set the site to Require SSL Encryption and create a new IIS Web Site to redirect Non-SSL users to the SSL site.

A New Breed of Blog

As time goes by, I feel more and more integrated into the Primark collective, getting my teeth into more new and exciting things. As time goes by, I foresee this blog evolving somewhat, not in its purpose, but in content, as I am exposed more to Exchange 2007 and likely 2010 in the future, SharePoint 2010 and the System Center family including Operations Manager, Configuration Manager and probably Service Manager and Data Protection Manager around the corner too.

I hope you enjoy the new material as and when it arrives.


Accessing BitLocker Recovery Keys in Active Directory

For years, admins have had the ability to store user certificates in Active Directory to help with things like EFS file encryption. One of the more recent technologies from Microsoft is BitLocker Drive Encryption.

To be able to archive the keys to Active Directory instead of storing the keys manually to USB, you need to extend the schema which forms part of the deployment of BitLocker, but when trying to manage BitLocker on-going, you need to be able to access the keys which have been saved.

These keys can be found stored in the Computer objects in Active Directory Users and Computers on a Windows 7 computer with the RSAT (Remote Server Administration Tools) once the BitLocker Password Recovery Viewer feature is enabled.

The problem you will sooner discover is that this in itself isn’t enough to give you access to the new tab in ADUC to see the keys, because the DLL file isn’t registered to allow it to work. To obtain the functionality that you want, you need to enter the command regsvr32 bdeaducext.dll to register the DLL.

Restart ADUC, and you will now have a new tab available on your computer objects for BitLocker Recovery.

Using Group Policy Restricted Groups

Since starting work at Primark, I’ve learnt tonnes, and loving it. Today however, was the exception in that I tried to demonstrate something to a colleague about how to use Restricted Groups in a Group Policy Object ‘in reverse’, but I couldn’t recall how to do it, leaving me feeling somewhat inadequate.

Under normal use, the Restricted Groups component of a Group Policy object allows you to restrict the membership of a particular group to selected members. The most common use case for this is at the end-user desktop level to ensure that no users are able to add themselves by hook or crook to the local Administrators group (assuming you don’t give your users Administrator permissions in the first place).

imageThe flip of this is that in some circumstances , more commonly on servers, you may want to supplement the Administrators group with additional members, but not remove any existing additions to the group.

To achieve this configuration, right-click on the Restricted Groups list item in the MMC Console and select Add Groups. When asked to specify the name of the group you wish to add, under normal circumstances, you would enter the name of the group that you want to control permissions (Eg. Administrators), however in this example you enter the name of the group that you want to add to Administrators.

When the dialog appears, in the “This group is a member of” section, add the Administrators group.

This change is normal configuration allows you to add specified groups to existing groups as desired.