Brian Desmond's Blog

How to Integrate Office Communications Server 2007 R2 with Exchange 2010

Brian Desmond — Sun, 07 Mar 2010 21:43:14 GMT

One of the new features of Outlook Web App (OWA) in Exchange 2010 is the ability for OWA to act as an IM client if you have Office Communications Server (OCS) in your environment. Once configured, you’ll be able to see and manage your buddy list, manage presence, as well as participate in IM conversations while logged in to OWA. Configuring this integration requires a number of steps on each of your Exchange 2010 Client Access Servers (CAS’). Many of the changes discussed in this blog post will cause brief service interruptions so it is highly recommended that you perform this work during a maintenance window where these interruptions are tolerable.

You’ll need to download two packages in order to proceed:

The web service provider
The latest ucmaredist.msp rollup package (currently January 2010)

You can simply run the first download on one machine as it will extract the contents to C:\WebService Provider Installer Package (by default). Inside of this folder will be a number of installers which you’ll need to execute (in order) on each of your CAS servers:

Visual C++ Redistributable (vcredist_x64.exe)
Unified Communications Managed API (ucmaredist.msi)
OCS Service Provider (cwaowassp.msi)

Finally, you’ll need to patch the UC Managed API by installing ucmaredist.msp.

Note: If you have User Account Control (UAC) enabled on your CAS servers, you should execute all of these packages from an elevated command prompt.

Once these packages are installed, you’re ready to configure OWA for integration with OCS. You’ll need to have the name of the OCS Pool which you plan to have your CAS servers connect to on hand as well as some information about the certificate on each CAS server which will be used to secure communications between the CAS server and OCS. Specifically, you’ll need to collect the certificate issuer string as well as the certificate’s serial number. You can do this using the following PowerShell command:

Get-ExchangeCertificate | fl Subject,Issuer,SerialNumber

You should get text returned back similar to the following:

Subject : CN=mail14.briandesmond.net, OU=IT, O=“Brian Desmond Consulting, LLC”, L=Chicago, S=Illinois, C=US
Issuer : CN=DigiCert Global CA, OU=www.digicert.com, O=DigiCert Inc, C=US
SerialNumber : 478C52B6B53E467F9331BB8CB4B2BDB8

Note: If you are using different certificates on each CAS server in your array, you’ll need to collect this data individually on a per CAS server basis.

Make note of the issuer and serial number values for the certificate. You’ll need to tell OWA to use this certificate for communications with OCS. To do this, browse to C:\Program Files\Microsoft\Exchange\V14\ClientAccess\Owa and open the web.config file with notepad. Scroll down and find the following section:

<add key="IMPoolName" value="" />
<add key="IMCertificateIssuer" value="" />
<add key="IMCertificateSerialNumber" value="" />

These are the three values you’ll need to populate for OWA to make the connection to OCS. The first value should be the FQDN of the OCS pool you want to connect to, and the following two values should be copied out of the Get-ExchangeCertificate spew collected earlier as shown below:

<add key="IMPoolName" value="ocspool01.briandesmond.net" />
<add key="IMCertificateIssuer" value='CN=mail14.briandesmond.net, OU=IT, O="Brian Desmond Consulting, LLC", L=Chicago, S=Illinois, C=US' />
<add key="IMCertificateSerialNumber" value="47 8C 52 B6 B5 3E 46 7F 93 31 BB 8C B4 B2 BD B8" />

Warning: There are three extremely important things you need to do when customizing the configuration settings shown above:

If your certificate’s issuer includes any double quotes (as mine does), you must enclose the data in single quotes instead of the default double quotes as shown above.
You must insert the spaces in between each octet in the serial number as shown above.
You must remember to update these values when you renew or replace the certificate on a CAS server.

Once OWA is configured, you’ll need to configure your OCS pool to trust the CAS servers. To do this, access the OCS Administration Pool, and open the Front End Properties of the pool (right click the pool, Properties>Front End Properties). On the Host Authorization tab, add an entry reflecting the certificate you configured in the web.config file in the previous step. You’ll also want to check the “Treat As Authenticated” and “Throttle As Server” checkboxes as shown below:

In order for this change to take effect immediately, you may need to restart the services on your OCS Front Ends. Doing this will disconnect any currently connected clients so it may instead be advantageous to wait for caches to refresh. The final step is to enable OCS IM integration for the OWA virtual directory. To do this, run the following PowerShell command:

Get-OwaVirtualDirectory -Server YourCasServer | Set-OwaVirtualDirectory -InstantMessagingType OCS

Users who are enabled for OCS should see their buddy list as well as a jelly bean to manage presence next time they login:

In summary, there are four key steps you’ll need to take in order to enable OCS integration with Outlook Web App in Exchange 2010. First, you’ll need to download the service provider and latest rollup for the components in the service provider download. Next, you’ll need to install the components downloaded on each Client Access Server. You’ll then collect certificate information from each CAS server and configure that information along with your OCS pool information in the OWA web.config file. Finally, you’ll add the CAS certificate to the list of trusted hosts in OCS and enable OCS integration on the OWA virtual directory.

Converting HyperV Snapshots to Dumps

Brian Desmond — Tue, 02 Feb 2010 00:07:19 GMT

Microsoft has had a tool internally for a while that would convert a saved state or snapshot of a HyperV virtual machine into a dump that you could open with the Windows debugging tools. This is really pretty handy sometimes when troubleshooting. The good news is this tool is now publically available here.

BlackBerry Enterprise Server and Exchange Server 2010 Throttling Policies

Brian Desmond — Mon, 01 Feb 2010 02:28:27 GMT

One of the new features in Exchange Server 2010 is the concept of Client Throttling Policies. In summary, Client Throttling Policies are designed to limit the amount of system resources a given user can consume and in turn impact performance for other Exchange users. Out of the box there is a default throttling policy (use the Get-ThrottlingPolicy cmdlet) applied to all users:

RunspaceId                     : ba3cdf92-fc9f-4a70-a912-2cf225e6d573
IsDefault                      : True
EASMaxConcurrency              : 10
EASPercentTimeInAD             :
EASPercentTimeInCAS            :
EASPercentTimeInMailboxRPC     :
EWSMaxConcurrency              : 10
EWSPercentTimeInAD             :
EWSPercentTimeInCAS            :
EWSPercentTimeInMailboxRPC     :
EWSMaxSubscriptions            :
EWSFastSearchTimeoutInSeconds : 60
EWSFindCountLimit              :
IMAPMaxConcurrency             :
IMAPPercentTimeInAD            :
IMAPPercentTimeInCAS           :
IMAPPercentTimeInMailboxRPC    :
OWAMaxConcurrency              : 5
OWAPercentTimeInAD             :
OWAPercentTimeInCAS            :
OWAPercentTimeInMailboxRPC     :
POPMaxConcurrency              : 20
POPPercentTimeInAD             :
POPPercentTimeInCAS            :
POPPercentTimeInMailboxRPC     :
PowerShellMaxConcurrency       : 18
PowerShellMaxCmdlets           :
PowerShellMaxCmdletsTimePeriod :
ExchangeMaxCmdlets             :
PowerShellMaxCmdletQueueDepth :
RCAMaxConcurrency              : 20
RCAPercentTimeInAD             :
RCAPercentTimeInCAS            :
RCAPercentTimeInMailboxRPC     :
MessageRateLimit               :
RecipientRateLimit             :
ForwardeeLimit                 :
CPUStartPercent                : 75
AdminDisplayName               :
ExchangeVersion                : 0.10 (14.0.100.0)
Name                           : DefaultThrottlingPolicy_f017f530-3edf-4c59-9955-d94bb7892fb0
DistinguishedName              : CN=DefaultThrottlingPolicy_f017f530-3edf-4c59-9955-d94bb7892fb0,CN=Global Settings,CN=
                                 GreenOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=green,DC=briandesmond,D
                                 C=net
Identity                       : DefaultThrottlingPolicy_f017f530-3edf-4c59-9955-d94bb7892fb0
Guid                           : af1aeaac-4d88-43da-92df-24c0924d4ad8
ObjectCategory                 : green.briandesmond.net/Configuration/Schema/ms-Exch-Throttling-Policy
ObjectClass                    : {top, msExchGenericPolicy, msExchThrottlingPolicy}
WhenChanged                    : 10/10/2009 5:44:29 PM
WhenCreated                    : 10/10/2009 5:44:11 PM
WhenChangedUTC                 : 10/10/2009 10:44:29 PM
WhenCreatedUTC                 : 10/10/2009 10:44:11 PM
OrganizationId                 :
OriginatingServer              : BRIAN-GRDC02.green.briandesmond.net
IsValid                        : True

As you can see, most of the valuesa re null, however each of the services has a *MaxCurrency property. These define the maximum number of connections a given user can have to that service. For example, the EASMaxConcurrency value limits a given user to a maximum of ten Exchange ActiveSync connections. Each of the values is documented in the Set-ThrottlingPolicy cmdlet documentation. Of particular note to this discussion is the RCAMaxConcurrency value which defines the maximum number of concurrent connections a given user can have to the RPC Client Access service. The RPC Client Access service is new in Exchange 2010 and it handles all MAPI connections to Exchange.

BlackBerry Enterprise Server (BES) uses a single service account to proxy all of the connections to Exchange on behalf of BlackBerry users. The side effect of this is that it’s quite likely that BES will need to have more than twenty (default limit) connections open to Exchange at a given time. If you review the documentation from RIM, they recommend setting the RCAMaxConcurrency value to null (equivalent to unlimited) for all users. This is really not a great idea at all.

Instead, what you can do is define a new Client Throttling Policy without an RCAMaxConcurrency value and apply it directly to the BES service account. The PowerShell script below does just that. The script assumes that your BES service account is called “BESAdmin”. If it isn’t modify the script accordingly.

New-ThrottlingPolicy "BES Throttling Policy" -RCAMaxConcurrency:$null
Set-Mailbox besadmin -ThrottlingPolicy "BES Throttling Policy"

You can easily confirm that the new policy is applied to the BESAdmin account by inspecting the properties of BESAdmin mailbox:

Get-Mailbox besadmin | fl Name,ThrottlingPolicy

You should see results similar to the following:

Name : BES Admin
ThrottlingPolicy : BES Throttling Policy

How to Create an ActiveSync Device Report

Brian Desmond — Sun, 31 Jan 2010 23:42:00 GMT

Exchange logs quite a bit of info about ActiveSync device partnerships and you can use this to create reports about the utilization of mobility features in your organization. Getting this data requires a couple of intermediate steps before you can export it to a CSV for processing in something like Excel (or another script). The PowerShell script below will export all of the ActiveSync device relationships in your organization. Keep in mind that this will include old relationships which are no longer active. Depending on how large your organization is and the number of device relationships out there, it may take a little while for the script to run.

Note: If you have a mixed version organization (e.g. Exchange 2007 and Exchange 2010), you’ll need to run the script twice. Once in the Exchange 2007 Management Shell and once in the Exchange 2010 Management Shell. The cmdlets used here are not backwards (or forward compatible). I’ve provided two versions of the script - one for Exchange 2007 and one for Exchange 2010.

Exchange 2007 Version

$devices = @()
$mailboxes = Get-CASMailbox -ResultSize:Unlimited | Where-Object {$_.HasActiveSyncDevicePartnership -eq $true -and $_.ExchangeVersion.ExchangeBuild -ilike "8*"}

foreach ($m in $mailboxes) 
{
	$devices += Get-ActiveSyncDeviceStatistics -Mailbox $m.Identity
}

$devices | Export-Csv DeviceStats.csv

Exchange 2010 Version

$devices = @()
$mailboxes = Get-CASMailbox -ResultSize:Unlimited | Where-Object {$_.HasActiveSyncDevicePartnership -eq $true -and $_.ExchangeVersion.ExchangeBuild -ilike "14*"}

foreach ($m in $mailboxes) 
{
	$devices += Get-ActiveSyncDeviceStatistics -Mailbox $m.Identity
}

$devices | Export-Csv DeviceStats.csv

You can open the exported CSV in Excel from here and generate reports based on that. There is quite a bit of information in the report including some personally identifiable information (PII) for the devices so keep that in mind before redistributing the raw data file.

Small Update to Redirection Blog

Brian Desmond — Sun, 31 Jan 2010 22:40:00 GMT

Last week, I posted about how to redirect HTTP connects to Exchange 2010 OWA to HTTPS. There was a small issue in the post which I’ve now corrected. If you explicitly disabled HTTP Redirection for the OWA virtual directory, you would break the /exchange, /public, and /exchweb virtual directories which redirect to /owa.

If you browse to https://owa.customer.com/exchange, you might see the following event in the Application log of your CAS server:

Log Name:      Application
Source:        ASP.NET 2.0.50727.0
Date:          1/31/2010 2:20:16 PM
Event ID:      1310
Task Category: Web Event
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      CAS01.green.briandesmond.net

Description:
Event code: 3008
Event message: A configuration error has occurred.
Event time: 1/31/2010 2:20:16 PM
Event time (UTC): 1/31/2010 10:20:16 PM
Event ID: 1dd0ff95241040a48b5acc09bff2e3ad
Event sequence: 32
Event occurrence: 31
Event detail code: 0
Application information:
Application domain: /LM/W3SVC/1/ROOT-2-129092586348966635
Trust level: Full
Application Virtual Path: /
Application Path: C:\inetpub\wwwroot\
Machine name: CAS01
Process information:
Process ID: 2268
Process name: w3wp.exe
Account name: IIS APPPOOL\DefaultAppPool
Exception information:
Exception type: ConfigurationErrorsException
Exception message: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS. (C:\Exchange\ClientAccess\owa\web.config line 31)
Request information:
Request URL: http://localhost/exchange/default.aspx
Request path: /exchange/default.aspx
User host address: 127.0.0.1
User:
Is authenticated: False
Authentication Type:
Thread account name: IIS APPPOOL\DefaultAppPool
Thread information:
Thread ID: 19
Thread account name: IIS APPPOOL\DefaultAppPool
Is impersonating: False
Stack trace:
   at System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean ignoreLocal)
   at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject)
   at System.Configuration.BaseConfigurationRecord.GetSection(String configKey)
   at System.Web.Configuration.RuntimeConfig.GetSectionObject(String sectionName)
   at System.Web.Configuration.RuntimeConfig.GetSection(String sectionName, Type type, ResultsIndex index)
   at System.Web.Configuration.RuntimeConfig.get_Identity()
   at System.Web.HttpContext.SetImpersonationEnabled()
   at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)

To resolve this, open the web.config file for OWA. The path is in the event. I highlighted it in red boldface font above so you know where to look. Inside of the web.config file, search for and remove this line:

<httpRedirect enabled="false" />

Warning: Improperly editing the web.config file for OWA could render it entirely inoperable. I highly recommend that you save a backup prior to making any changes to the file.

Redirecting OWA URLs in Exchange 2010

Brian Desmond — Sun, 17 Jan 2010 22:52:00 GMT

One of the things I’ve been doing for as long as I can remember is redirecting requests that don’t go to https://owa.customer.com/owa (or /exchange) to the correct URL. So, if someone goes to http://owa.customer.com or https://owa.customer.com, they get redirected to the correct (secure) URL. Historically I’ve always done this with two components:

A custom website listening on Port 80 on each CAS server
A default.aspx file in the root of the Default Web Site redirecting to /owa

This approach no longer works with Exchange 2010 CAS because the PowerShell virtual directory actually operates over Port 80 (authentication is Kerberized). If you try and tinker with this, you’ll start getting errors from Remote PowerShell like this:

VERBOSE: Connecting to cas01.customer.com
[cas01.customer.com] The WinRM service cannot process the request because the request needs to be sent to a different machine. Use the redirect information to send the request to a new machine. Redirect location reported: https://owa.customer.com/owa/PowerShell. To automatically connect to the redirected URI, verify "MaximumConnectionRedirectionCount" property of session preference variable "PSSessionOption" and use "AllowRedirection" parameter on the cmdlet.
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportRedirectException
+ FullyQualifiedErrorId : PSSessionOpenFailed

In order to work around this, you need to use the HTTP Redirection feature in IIS (the default.aspx trick mentioned above should work too), as well as remove the requirement for SSL at the top level Default Web Site object. You have to be careful doing this because when you set settings on the web site, IIS will push them down to any virtual directory below which does not explicitly set that setting itself. To setup the redirect, select the Default Web Site in IIS Manager, and open the HTTP Redirect option under IIS. Complete it like this:

Warning: It’s very important that you check the checkboxes exactly as shown in the screenshot above!

Once this step is complete, you need to remove the enforced redirect from each of the virtual directories under the Default Web Site. To do this, select each virtual directory individually, and then open the HTTP Redirect property and uncheck the “Redirect requests to this destination” checkbox. You’ll need to do this on the following virtual directories:

aspnet_client
Autodiscover
ecp
EWS
Microsoft-Server-ActiveSync
OAB
PowerShell
Rpc

Note: The Exchange, Exchweb, and Public virtual directories should redirect to /owa.

If at this point you simply browse to http://cas01.customer.com, you’ll get an HTTP 403.4 error. This is because SSL is required at the top-level website. In order to get the redirect working, we need to disable SSL for the toplevel website while leaving it enabled for the relevant child virtual directories.

Select the Default Web Site and open the SSL Settings properties. Uncheck the Require SSL checkbox as shown below:

Like the redirection settings, this change will be inherited down the tree for any virtual directory which does not explicitly set the setting independently. Ensure that SSL is required for the following virtual directories:

Autodiscover
ecp
EWS
Microsoft-Server-ActiveSync
OAB
owa
Rpc

Warning: If you require SSL for the PowerShell virtual directory, you will render Remote PowerShell inoperable!

Once you’ve configured the redirection and SSL settings, open a command prompt and run iisreset. At this point you should be able to browse to http://localhost on the CAS server and get redirected to https://owa.customer.com/owa. These steps were tested on Windows Server 2008 R2. While they should be similar under Windows Server 2008, they may not be identical.

McAfee EPO and NLB Clusters

Brian Desmond — Sun, 17 Jan 2010 21:31:21 GMT

I rolled out McAfee agents to about ten servers yesterday and four of them wouldn’t show up properly in the console. I did the usual troubleshooting with this, played with cmdagent, and didn’t really get far. What I did eventually notice is that while two of my machines would show up as Managed in the console, the other two simply refused. The wierd behavior here is that if I went in cmdagent and resent all the properties of the missing servers, suddenly the other two would disappear from the console. I did a bit of research and it appears that McAfee generates the client identifier based on the machine’s MAC Address.

This piece of information was the ticket here. The machines in question are in two Windows Network Load Balancing (NLB) clusters. The high level summary of how NLB works is that it shares a MAC address amongst all the machines in the cluster. McAfee was using this MAC to generate agent identifiers and was coming up with duplicates in both clusters. I did a bit of research and McAfee has an article in their knowledge base as to how to deal with this with a workaround.

When you go to create the registry value described in the article, McAfee prevents it because they’re hooking things and making sure you don’t touch their part of the registry. This is implemented in the Access Protection Policy for VirusScan. If you look at the VirusScan log, you’ll see a line like this and the corresponding regedit error:

1/17/2010 12:26:02 PM Blocked by Access Protection rule DOMAIN\bdesmond C:\Windows\regedit.exe \REGISTRY\MACHINE\SOFTWARE\Wow6432Node\Network Associates\ePolicy Orchestrator\New Value #1 Common Standard Protection:Prevent modification of McAfee Common Management Agent files and settings Action blocked : Create

To work around this, I edited my Access Protection policy and disabled blocking for the three “Prevent modification of McAfee files and settings” rules highlighted below:

2009 in Review

Brian Desmond — Tue, 29 Dec 2009 08:44:00 GMT

2009 has been pretty busy for me all things considered. I’ve been all over the place visiting with customers and doing conferences. I took a few minutes to add up a couple of spreadsheets and came up with some numbers:

Countries	9
US States	7 (plus District of Columbia)
US Cities Visited	32 (approx)
Airplanes	81
Miles Flown	150,882 (approx)
Hotels Visited	32 (approx)
Hotel Nights	135
Days on the Road	181

Already off to four states in the first couple weeks of the year and the conference schedule is starting to line up. Happy New Years!

Installing WinPcap Silently

Brian Desmond — Sun, 29 Nov 2009 03:06:17 GMT

A standard part of my server build I do everywhere is installing WireShark. WireShark of course requires WinPcap. While you can install WireShark silently, it conveniently doesn’t install WinPcap, rendering it useless. I used to work around this by installing NMap as part of the build since NMap does include WinPcap in its’ silent install. Unfortunately this seems to have broken under Windows Server 2008 R2.

The good news is you can work around this with the hackish but effective AutoIt. Below is my AutoIt script for installing WinPcap 4.1.1.

; ==========================================================================
; NAME: WinPcap AutoIt Installer
; 
; AUTHOR: Brian Desmond, brian@briandesmond.com
; DATE  : 11/28/2009
; ==========================================================================
#RequireAdmin

Run("WinPcap_4_1_1.exe")
WinWaitActive("WinPcap 4.1.1 Setup")
Send("!n")
WinWaitActive("WinPcap 4.1.1 Setup", "Welcome to the WinPcap")
Send("!n")
WinWaitActive("WinPcap 4.1.1 Setup", "License Agreement")
Send("!a")
WinWaitActive("WinPcap 4.1.1 Setup", "Installation options")
ControlClick("WinPcap 4.1.1 Setup", "Installation options", "[CLASS:Button; INSTANCE:2]") ; hack to click the install button
WinWaitActive("WinPcap 4.1.1 Setup", "Completing the WinPcap")
Send("!f")

Note: This depends on the version number strings in the WinPcap setup. If it changes, you’ll need to tweak the script above accordingly.

I just compiled this to an EXE using the AutoIt compiler and it worked just fine.

Installing Dell Update Packages on Windows Server 2008 R2

Brian Desmond — Sun, 29 Nov 2009 02:41:51 GMT

Despite the release notes in the PE2950 2.6.1 BIOS, “Added support for the Microsoft(R) Windows Server(R) 2008 R2 operating system”, the install package doesn’t actually work properly. It has a prompt telling you that it’s running on an unsupported OS. This completely invalidates the silent install capability. This problem seems to extend to all the other install packages.

Fortunately, this is pretty easy to work around with the built in Application Compatibility settings in Windows. You just need to set the executable to the Windows Server 2008 (Service Pack 1) compatibility mode:

Since I’m running all these packages as part of an unattended build, I went ahead and set all of the packages to the WS08 SP1 compatibility mode on a test machine and then exported the registry key that has these settings. To do that, export HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers to DellCompat.reg. Next, you can run reg import DellCompat.reg and import the settings which will enable the packages to function correctly.

For reference, I put all of the update packages in C:\DellSrc. The batch file below imports the registry changes, installs all of the latest (as of 28-Nov-2009) drivers and firmware for a Dell PowerEdge 2950 running Windows Server 2008 R2, and installs OpenManage Server Administrator 6.1.

reg import c:\dellsrc\DellCompat.reg
c:\dellsrc\PE2950_BIOS_WIN_2.6.1.EXE /s
c:\dellsrc\BMC_FRMW_WIN_R202152.EXE /s
c:\dellsrc\ESM_FRMW_WIN_R149431.EXE /s
c:\dellsrc\RAID_FRMW_WIN_R216024.EXE /s
c:\dellsrc\RAC_FRMW_WIN_R209365.EXE /s
c:\dellsrc\RAID_FRMW_WIN_R216021.EXE /s
c:\dellsrc\NIC_DRVR_WIN_R236633.EXE /s
c:\dellsrc\NIC_DRVR_WIN_R234753.EXE /s
c:\dellsrc\NETW_FRMW_WIN_R239524.EXE /s
c:\dellsrc\BMC_FRMW_WIN_R202152.EXE /s

start /wait msiexec /i c:\dellsrc\openmanage\SysMgmt.msi ADDLOCAL=BRCM,INTEL,IWS,OMSM,RAC5,SA /qb

Here is the DellCompat.reg registry script:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\DellSrc\\PE2950_BIOS_WIN_2.6.1.EXE"="WINSRV08SP1"
"C:\\DellSrc\\BMC_FRMW_WIN_R202152.EXE"="WINSRV08SP1"
"C:\\DellSrc\\ESM_FRMW_WIN_R149431.EXE"="WINSRV08SP1"
"C:\\DellSrc\\NETW_FRMW_WIN_R239524.EXE"="WINSRV08SP1"
"C:\\DellSrc\\NIC_DRVR_WIN_R234753.EXE"="WINSRV08SP1"
"C:\\DellSrc\\NIC_DRVR_WIN_R236633.EXE"="WINSRV08SP1"
"C:\\DellSrc\\RAC_FRMW_WIN_R209365.EXE"="WINSRV08SP1"
"C:\\DellSrc\\RAID_FRMW_WIN_R216021.EXE"="WINSRV08SP1"
"C:\\DellSrc\\RAID_FRMW_WIN_R216024.EXE"="WINSRV08SP1"