Category Archives: Microsoft

Posts concerning news and beta programs from Microsoft. Also, posts dealing with Microsoft products, such as the Xbox 360.

While working on a new System Center Configuration Manager 1511 server that I was building, I noticed that each of the Component Status logs were returning 0 messages for the previous 1 day. If I set the threshold back to 1 week, I could see events, but they had completely stopped a few days earlier. Something was preventing new logs from being created.

The Component Status logs are found under the Monitoring node, by expanding System Status and then selecting Component Status. The odd thing about this was that the icons and status seemed to be updating correctly, suggesting that the data for the logs was still being collected and processed, but SCCM could not display the logs.

The events written to statmgr.log looked something like this (in part):

*** exec sp_InsContentDistributionStatus N'', N'RTM00405', 0, 72057594038182832, 2361, '02/18/2016 07:04:10.240', N'\\\dfs\Packages\Microsoft\Updates\Windows 7 Server 2008 R2 Office 2010 Patch Tuesday Updates 2015\95289d79-38a1-44a3-a2a7-5f54febcb70b', N'95289d79-38a1-44a3-a2a7-5f54febcb70b', N'95289d79-38a1-44a3-a2a7-5f54febcb70b', N'30', N'69', N'';	SMS_STATUS_MANAGER	2/19/2016 10:54:34 AM	4648 (0x1228)
*** [22001][8152][Microsoft][SQL Server Native Client 11.0][SQL Server]String or binary data would be truncated. : sp_InsContentDistributionStatus	SMS_STATUS_MANAGER	2/19/2016 10:54:34 AM	4648 (0x1228)

The corresponding .sql file in Microsoft Configuration Manager\inboxes\\retry\ looked something like this (in part):

exec sp_InsContentDistributionStatus N'', N'RTM00405', 0, 72057594038182832, 2361, '02/18/2016 07:04:10.240', N'\\\dfs\Packages\Microsoft\Updates\Windows 7 Server 2008 R2 Office 2010 Patch Tuesday Updates 2015\95289d79-38a1-44a3-a2a7-5f54febcb70b', N'95289d79-38a1-44a3-a2a7-5f54febcb70b', N'95289d79-38a1-44a3-a2a7-5f54febcb70b', N'30', N'69', N'';

As I looked through the .sql files containing the problem transactions, I noticed a pattern appear. Each .sql file contained a stored procedure named “sp_InsContentDistributionStatus”, and each of these stored procedures involved the source path to a Microsoft update in one of my Software Update Deployment Packages.

Nothing about the arguments to the stored procedure looked out of place, and in fact matched very closely to stored procedures that ran successfully once the jam in Microsoft Configuration Manager\inboxes\\retry\ was cleared.

I did some Googling and formulated a course of action to restore most of the missing log entries until I had time to troubleshoot the root cause.

  1. Open an elevated command prompt to the \\retry\ location. For example, on my server, where I have installed SCCM to the D: drive, the directory is located at:
    D:\Program Files\Microsoft Configuration Manager\inboxes\\retry\
    You’ll probably find dozens, if not hundreds of .sql files in this location.
  2. Sort the files by date in descending order, to see the oldest at the bottom of the list, using the command:
    dir /o:-d
    This file contains the query that is blocking later transactions.
  3. Open the SCCM server’s statmgr.log in cmtrace.exe and leave it open. On my server, this file is located at:
    D:\Program Files\Microsoft Configuration Manager\Logs\statmgr.log
  4. Search the log for the file name of oldest .sql server in the \retry\ directory. Depending on how long the problem has existed you may or may not find entries around the failure to submit the transaction.
  5. Move the oldest .sql file from the \retry\ directory into another location. This file will not be processed, and as such will result in some data loss, but it will allow you to proceed.
  6. Start the Configuration Manager Service Manager, expand Components, and then query, stop, query, start the SMS_STATUS_MANAGER component.
    You should see activity in the statmgr.log as it begins to process the failed transactions, but it should be able to successfully process the transactions that were queued up behind the problem query.
  7. Monitor the statmgr.log for failures. If another back-logged .sql file contains an invalid query, the statmgr.log will report the failure, and you will be able to capture both the events surrounding the failure and the .sql file containing the failed transaction for analysis.
  8. Repeat the process of moving each failed .sql file out of the \retry\ directory, then restarting the SMS_STATUS_MANAGER component until all of the back-logged .sql files have been processed.

As a first step to attempt to resolve the problem, I deleted the Software Update Deployment Package and then rebuilt it from the source path. The .sql files did not build up in Microsoft Configuration Manager\inboxes\\retry\, and the problem where the component status messages stopped being display did not recur. So, unfortunately, I seem to have fixed the problem by going straight to the nuclear option, and missed out on any opportunity for finding the root cause. While I don’t have an explanation about why the stored procedure errored out, I’m posting this description of my experience in hopes of helping others. If you can explain the cause of the problem, please do post a comment.

I have found error ID 40, with the description “The event logging service encountered an error when attempting to apply one or more policy settings.” is written to the System event log when the Group Policy setting “Specify the maximum log file size (KB)” under “Windows Components/Event Log Service/System” is configured (either enabled and set to a valid size or disabled).

Log Name:      System
Source:        Microsoft-Windows-Eventlog
Date:          2/18/2016 11:44:46 AM
Event ID:      40
Task Category: None
Level:         Error
Keywords:      Service availability
User:          LOCAL SERVICE
The event logging service encountered an error when attempting to apply one or more policy settings.
Event Xml:
<Event xmlns="">
    <Provider Name="Microsoft-Windows-Eventlog" Guid="{FC65DDD8-D6EF-4962-83D5-6E5CFE9CE148}" />
    <TimeCreated SystemTime="2016-02-18T17:44:46.789855700Z" />
    <Correlation />
    <Execution ProcessID="1140" ThreadID="5600" />
    <Security UserID="S-1-5-19" />
    <ChannelPolicyApplicationError xmlns="">
      <Error Code="5">

The same error will appear when the Group Policy setting “Specify the maximum log file size (KB)” is configured under “Windows Components/Event Log Service/Application” or “Windows Components/Event Log Service/Security”.

Unfortunately, the SCM Windows 10 TH2 – Computer GPO (which I like to use as a baseline security GPO) sets the maximum log size for the Application, Security and System logs, and because disabling the setting in a GPO with a lower link order does not prevent the errors from appearing, I have to choose between changing the Microsoft security baseline GPO and living with the errors in the event log. I have decided to modify the GPO and set the three maximum log size settings to Not Configured, and then change the size of the System event log using the command “wevtutil sl System /ms:33554432”, the Application event log with “wevtutil sl Application /ms:33554432” and the Security event log with “wevtutil sl Security /ms:201326592” during the SCCM OSD task sequence.

The outcome is that the logs are configured to their recommended sizes, as specified in the SCM GPO, but GP is not enforcing the log size. I feel like this is an acceptable workaround, as it avoid the errors in the System event logs, sets the logs to the Microsoft-recommended size, and standard users will not be able to change the maximum log size via the Log Properties page.

I was running into a problem with the installation of Microsoft .NET Framework 4.5.2 during an SCCM 2012 SP1 build and capture Task Sequence, both in Windows 7 and Windows 8.1, wherein the installer was running but the log files were not being created.

I was using the Application model in SCCM and executing the offline installer executable with the command line “NDP452-KB2901907-x86-x64-AllOS-ENU.exe /q /norestart” through a VBScript wrapper script.

When the application failed during the task sequence, the error in smsts.log read, in part:

Execution status received: 4 (Application failed to install )
Installation failed.
Install application action failed: 'Microsoft .NET Framework 4.5.2'. Error Code 0x80004005
Install Static Applications failed, hr=0x80004005
Process completed with exit code 2147500037
Failed to run the action: Microsoft .NET Framework 4.5.2. 
Unspecified error (Error: 80004005; Source: Windows)

If I ran my installation wrapper script from the ccmcache subdirectory while logged on as the local administrator account, the .NET Framework 4.5.2 installation ran successfully.

According to the MSDN page .NET Framework Deployment Guide for Administrators, log files are written to “%temp%\Microsoft .NET Framework 4.5*.txt” and “%temp%\Microsoft .NET Framework 4.5*.html”, but neither of these logs existed on my Windows 7 and Windows 8.1 systems after the installation failed.

However, a log file at C:\Windows\Temp\dd_NDP452-KB2901907-x86-x64-AllOS-ENU_decompression_log.txt caught my eye. The contents of this decompression log read:

[5/22/2014, 16:42:35] === Logging started: 2014/05/22 16:42:35 ===
[5/22/2014, 16:42:35] Executable: C:\Windows\ccmcache\1\NDP452-KB2901907-x86-x64-AllOS-ENU.exe v4.5.51209.34209
[5/22/2014, 16:42:35] --- logging level: standard ---
[5/22/2014, 16:42:35] Successfully bound to the ClusApi.dll
[5/22/2014, 16:42:35] Error 0x80070424: Failed to open the current cluster
[5/22/2014, 16:42:35] Cluster drive map: ''
[5/22/2014, 16:42:35] Considering drive: 'A:\'...
[5/22/2014, 16:42:36] Drive 'A:\' is rejected because of the unknown or unsuitable drive type
[5/22/2014, 16:42:36] Considering drive: 'C:\'...
[5/22/2014, 16:42:36] Considering drive: 'D:\'...
[5/22/2014, 16:42:36] Drive 'D:\' is rejected because of the unknown or unsuitable drive type
[5/22/2014, 16:42:36] Drive 'C:\' has been selected as the largest fixed drive
[5/22/2014, 16:42:36] Directory 'C:\26169df5670339bdf66775485ff857\' has been selected for file extraction
[5/22/2014, 16:42:36] Extracting files to: C:\26169df5670339bdf66775485ff857\
[5/22/2014, 16:42:36] Error 0x80004005: Failed to extract all files out of box container #0.
[5/22/2014, 16:42:36] Error 0x80004005: Failed to extract
[5/22/2014, 16:42:36] Exiting with result code: 0x80004005
[5/22/2014, 16:42:36] === Logging stopped: 2014/05/22 16:42:36 ===

I Googled the rather generic error messages from the decompression log a little bit and didn’t find anything helpful, although I did find some recommendations to 1) extract the file using 7-Zip and then run the setup.exe, which I did not want to do, or 2) use the traditional Package/Program method, which I considered. On the day that I was going to give up on the Application model and just create a Package, I did a little more Googling on installing .NET Framework 4.5 through an SCCM task sequence and found a thread on the Technet forums that describes the problem exactly and gives a working solution:

.NET 4.5.1 Install only works when running on a UI session

The resolution described in the thread is to edit the properties of the Deployment Type to enabled “Run installation and uninstall program as 32-bit process on 64-bit clients.” (This setting is found on the Programs tab.) I modified the Deployment Type properties to run the installer as a 32-bit process and indeed it did install successfully during the task sequence.

For the Detection Rule, I chose to use a registry setting must exist:

HKLM\SOFTWARE\Classes\Installer\Products\6414876250E69FF3395387C6C7F05BEB\ProductName = Microsoft .NET Framework 4.5.2

Using the registry to determine the installed version of .NET Framework is rather tricky, but for versions of .NET Framework 4.5 and later, see How to: Determine Which .NET Framework Versions Are Installed.

Best of luck.

P.S. I expect, but will have to validate, that this method of running the installer as a 32-bit process might help with other applications that fail to install during a task sequence but run successfully via Software Center or Application Catalog when a user is logged on.

This post is a collection of some of the more commonly used command line utilities when doing basic troubleshooting in a Windows domain environment.

To open a command window within a directory from Windows Explorer, hold the Shift key and right-click on the directory, then choose “Open command window here”.


Displays the name of the current directory or changes the current folder.

Used within a command window to change the current active directory, allowing navigation through the computer’s mapped drives and their directory structures.


Displays the current directory path.

Moves to the root of the current drive.

cd /d e:
Moves to the E: drive from another drive. It’s also possible to move to a different drive by typing only the drive letter followed by a colon, ex: D:

Moves to the parent directory of the current directory (move up one directory toward the root).

cd “People to sue next”
Moves from the current directory into the subdirectory named “People to sue next”. A handy trick is to just type the first few characters of the directory name, and then hit the tab key to auto-complete the rest of the directory name from the first alphabetical match found, and even wrap it in double quotes if it contains spaces. For example, the same command as above can by typed: cd peop <tab>

If the current directory contains multiple matches for the characters typed, hitting tab again will cycle to the next match.

The tab method can be used more than once, to chain together a series of directories. For example, to move to the C:\Users\Public\Documents directory from a command prompt at the root of C:, one can type: cd u <tab> p <tab> d <tab> <tab> <enter>


Displays a list of a directory’s files and subdirectories.


Displays the directories and files in the current directory.

dir /s
Displays the directories and files in the current directory and all sub directories.

Dir can also be used to search for a file, and in many cases it works better than the Windows Explorer search.

dir c:\findme.txt /s
Displays a list of all instances of a file named “findme.txt” on the C: drive. It’s also possible to navigate to a location, such as the root of C:, and type: dir /s findme.txt to search that location and all subdirectories for a file named “findme.txt”.

Wildcards are allowed in the form of an asterisk. For example, type: dir c:\*.doc /s to search the C: drive for all files with a .doc or .docx extension (I’m not sure why it also locates .docx files, when there is no wildcard specified at the end of the extension, but it does).

Another command line utility for searching for files is where, but the syntax is slightly more complicated.


Refreshes local and Active Directory-based Group Policy settings, including security settings.

If you absolutely must reapply all settings, you can use the /force switch. After reading about the difference between gupdate and gpupdate /force, I now feel that gupdate is sufficient to reapply group policy nearly all of the time, and the /force switch shouldn’t automatically be used.


Reapplies group policy.


Displays Group Policy settings and Resultant Set of Policy (RSOP) for a user or a computer.


gpresult /r
Displays RSoP summary data, which includes the last time group policy was applied, from which server group policy was applied, and the groups for which the current user is a member.

gpresult /h gpreport.html
Generates a report of the applied group policy settings and saves it in HTML format as a file named gpreport.html. When generating a report as a user that is not a local administrator, either supply a full path to a valid location for gpreport.html, or navigate to a location (like the Public Documents directory) before running the command, or else the utility may be unable to create the report due to insufficient rights to the current directory.


Displays all current TCP/IP network configuration values and refreshes Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS) settings. Used without parameters, ipconfig displays the IP address, subnet mask, and default gateway for all adapters.


Display the computer’s IP address and default gateway, for each network adapter.

ipconfig /all
Displays full TCP/IP information, including the MAC address, DHCP server, and DNS servers, for each network adapter.

net use

Connects a computer to or disconnects a computer from a shared resource, or displays information about computer connections. The command also controls persistent net connections. Used without parameters, net use retrieves a list of network connections.


net use
Lists all of the computer’s connections (mapped network drives).

net use e: \\ComputerName\ShareName
Maps the E: drive to the ShareName shared resource on the ComputerName computer. To map the local E: drive to the C: drive (which is a hidden share) of a remote machine named Loomer, type: net use e: \\loomer\c$

net use e: /delete
Removes the connection currently mapped to the local E: drive.

If you are connecting to a network share that your regular account does not have rights to access, you will be prompted for a username. You will need to also supply the domain, ex: domainusername


Displays information that you can use to diagnose Domain Name System (DNS) infrastructure.


nslookup <ipaddress or computername>
Queries the local computer’s default DNS name server for information on the specified IP address or computer name. Supply either piece of information and nslookup will return both pieces. It’s also possible to specify a particular DNS name server to be queried, which is useful when troubleshooting whether DNS is propagating/replicating correctly.


Verifies IP-level connectivity to another TCP/IP computer by sending Internet Control Message Protocol (ICMP) Echo Request messages. The receipt of corresponding Echo Reply messages are displayed, along with round-trip times. Ping is the primary TCP/IP command used to troubleshoot connectivity, reachability, and name resolution.

You can use ping to test both the computer name and the IP address of the computer. If pinging the IP address is successful, but pinging the computer name is not, you might have a name resolution problem.


ping <ipaddress or computername>
Makes four attempts to contact the computer at the specified IP Address or with the specified computer name, and reports back whether the machine could be contacted and the time taken for the request to travel to the remote computer, be acknowledged, and the acknowledgement received by the local computer.

ping <ipaddress or computername> -t
Repeatedly attempts to contact the remote computer until interrupted by pressing Ctrl+Break or Ctrl+C. This is sometimes called a persistent ping.


Displays detailed configuration information about a computer and its operating system, including operating system configuration, security information, product ID, and hardware properties, such as RAM, disk space, and network cards.

The systeminfo command also reveals installed hotfixes and some information about the computer that isn’t readily available in Device Manager or other MMC Snap-ins, such as the BIOS version.


Displays information about the local computer.

systeminfo /s computername /u domainuser
Displays information about a remote computer named computername.

systeminfo /s computername | find “System Model:”
Retrieves information about a remote computer named computername, but pipes the output of systeminfo to the find command, which returns only the line containing the string “System Model:”. This output in the command window shows only “System Model:” followed by the model of the remote computer.

The systeminfo report can be sent to a text file, ex: systeminfo > systeminforeport.txt

Bonus commands


Returns the media access control (MAC) address and list of network protocols associated with each address for all network cards in each computer, either locally or across a network.


getmac /v
Shows MAC addresses for the local computer.

getmac /s computername /u domainusername /v
Shows MAC addresses for a remote computer named computername while authenticating as a different user.

(Need to test this.)


Sends a message to a user (this may be turned off in many environments). Run msg /? for usage information.

Microsoft has a nifty tool called Orca.exe that lets you directly edit options within msi installer files and msp patch files.

Orca.exe is a database table editor for creating and editing Windows Installer packages and merge modules. The tool provides a graphical interface for validation, highlighting the particular entries where validation errors or warnings occur.

This tool is only available in the Windows SDK Components for Windows Installer Developers. It is provided as an Orca.msi file. After installing the Windows SDK Components for Windows Installer Developers, double click Orca.msi to install the Orca.exe file.

Orca.msi was originally included in the Windows Installer 4.5 SDK, which is no longer available as a stand-alone download. Orca.exe version 5.0.7693.0 and other tools for working with msi files are part of the Microsoft Windows SDK for Windows 7 and .NET Framework 4 (or for previous versions, try the older Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1). The package that includes Orca.msi is available as an a la carte selection from the Microsoft Windows SDK web installer. Proceed through the web installer wizard and then select only the “Debugging Tools for Windows” under “Common Utilities” for the minimum install. Orca.Msi will be saved to “C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\”.

If you prefer a massive download just to get a 2 MB executable, the entire Microsoft Windows SDK is available as a 1.4 GB ISO from Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1 (ISO).

Should Windows 7 be old news to you, you can try the Windows Software Development Kit (SDK) for Windows 8. (I have no idea what’s in there.)

It’s often useful to know what logical and physical drives are available to Windows, and sometimes this needs to be done from the command line.

Logical drives

Here’s a handy command to return a list of logical drives in Windows.

wmic logicaldisk get caption,description,drivetype,providername,volumename

The Win32_LogicalDisk WMI class represents a data source that resolves to an actual local storage device on a computer system running Windows. While Caption, Description, DriveType, ProviderName, and VolumeName are useful in most cases, more properties are available, and a complete list is available at The output will be formatted as a table, the properties will be the column headings, and they will be placed into alphabetical order.

Caption is the drive letter of the logical disk. The Name property also returns the drive letter.

Description is the type of disk. For example: Local Fixed Disk, CD-ROM Disc, or Removable Disk.

DriveType is returned as an integer that corresponds to the type of disk drive the logical disk represents (and this matches the Description, making DriveType sort of superfluous).

0 = Unknown
1 = No Root Directory
2 = Removable Disk
3 = Local Disk
4 = Network Drive
5 = Compact Disc
6 = RAM Disk

ProviderName is the network path to the logical device.

VolumeName is the volume name of the logical disk.

Physical drives

And here is a command to return a list of physical drives.

wmic diskdrive list brief /format:list

The Win32_DiskDrive WMI class represents a physical disk drive as seen by a computer running Windows. Like the Win32_LogicalDisk WMI class, it has lots of properties, as listed at

For simplicity, though, and ease of reading in command window, wmic diskdrive list brief /format:list does the trick, particularly in combination with wmic logicaldisk.

During the development of our Windows 7 image with Office 2010, we began seeing a problem around our users’ Outlook 2010 profiles on the pre-production builds. On occasion, after logging into a machine for the first time, our users would be prompted to choose an Outlook profile upon the first launch of Outlook. Every time the Choose Profile dialog box was presented, it had only a single option in the profile name menu, and that option was always “BACKUP OF Outlook”, where Outlook was our customized profile as configured in a .PRF and applied via the Office OCT.


We were not using .PST files and we were not using Windows Roaming Profiles, but we were using Group Policy logon and logoff scripts to roam certain portions of our user profiles, including the entire registry key at [HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles]. With 20/20 hindsight, it’s clear that this unwanted behavior was not happening when we logged into a machine for the first time as a brand-new user (ie, while also preventing the logon script from merging the Profiles key from another machine into HKCU before Outlook was opened), but before a pattern had emerged, we considered the problem to be intermittent.

We were building machines using System Center 2012 Configuration Manager and using the Microsoft Office Customization Tool for configuring our .MSP and .PRF files. We were familiar with Active Setup and recognized that Outlook was doing a similar first-run process to set up a profile for what it thought was a new user. When it discovered that an Outlook profile already existed, it created a new profile named “BACKUP OF Outlook” and offered the user a Choose Profile dialog box with this profile as the only choice, presumably because “BACKUP OF Outlook” was not yet set to be the default profile.

Observed symptoms

When the logon script had roamed a user profile from another machine by importing the Profiles key, and before Outlook was launched for the first time, our Profiles key looked similar to this (the snippet has had the juicy bits removed):

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles]

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook]

After Outlook had been launched and the Choose Profile dialog box had been presented, the registry looked similar to this:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\DeletedProfiles]

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\DeletedProfiles\Outlook]

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles]

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook]

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\BACKUP OF Outlook]

The changes we noted were that a new profile named BACKUP OF Outlook had been created, a new DeletedProfiles key had been created, our desired profile had been flagged for deletion via a subkey under DeletedProfiles, and the DefaultProfile string value under the Profiles key that had been pointing to our profile had been deleted.

If we launched Outlook but cancelled out of the Choose Profile dialog box, closed Outlook, and put the Profiles key back to the state before Outlook was launched, we could then relaunch Outlook without issue. It had no objection to using the roamed profile on the second launch or any subsequent launches. The problem might arise if this user roamed the Profile key to yet another machine, but we had not yet identified a pattern or means of reproducing the problem.

Complicating factors

This was happening during a time of rapid development, when the Office OCT was being changed frequently, and machines were hitting the floor with different Office builds. The users logging into these machines were not always aware of all of the changes between builds, and in many cases we were not roaming the user’s profile in an attempt to get a ‘clean’ test of the new build. These factors contributed to the difficulty in establishing a pattern or recognizing commonalities.

A decent amount of time was spent researching problems with Outlook profiles in general, and this research turned up a few forum threads ( that indicated the problem stemmed from the .PRF file. (We also found some mentions of an “undocumented” property named BackupProfile in the .PRF: and We experimented briefly with making changes to the .PRF as hinted at in these threads, but felt that such trial-and-error experimentation was not the best use of our time.

The epiphany

A tip passed along by one of our Kraft Kennedy consultants lead to the break-through.

When 32-bit Office is installed with an .MSP generated by the OCT, a GUID-named key is created under [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\User Settings] that contains a value named Count with a data of 1. For example:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\User Settings\{75BB133B-F5DD-423C-8321-3BD0B50322A5}]

Much like Active Setup, when Outlook launches, it looks for a corresponding key in [HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\User Settings], also with a
value named Count with a data of 1. If the matching key is not found, Outlook does its first-run process, applies the .PRF, and then writes the GUID-named key to HKCU so that the first-run behavior doesn’t happen on that machine again.

In our case, each time we made a change to the OCT and cooked up a new OSD image in SCCM, the GUID-named key under HKLM changed. When a user from an old machine roamed to one of these new machines (or when a user initially on a new machine roamed to an older one), the GUID-named keys did not match and the first-run behavior fired off.

The resolution

Now that we better understood what was happening, we could evaluate a few ways to handle the situation. One way was to detect whether the user already had a default profile, and then add the current machine’s HKLM GUID key to her HKCU. Another way was to try to get a better handle on the .PRF and configure it to not create the backup, even when the first-run behavior was triggered. The latter seemed preferable, because we weren’t sure that avoiding the first-run behavior entirely was desirable. We suspected that there might be an advantage to allowing Office’s first-run process to play out, for example, if future changes to the OCT were made that needed to be added to the user’s environment.

After some communication with Microsoft, we made two changes to our .PRF that suppressed the creation of the BACKUP OF profile. The first change was to add BackupProfile=False to the Section 1, General area. The second change was to use UniqueService=Yes in the Section 4, Service1 area.

The corrected .PRF, in part, looks like this:

;Automatically generated PRF file from the Microsoft Office Customization and Installation Wizard

; **************************************************************
; Section 1 - Profile Defaults
; **************************************************************



; Section 4 - Default values for each service.


Some final thoughts

I would note that we are using BackupProfile=False, while many of the forum threads on the subject (incorrectly?) reference the property value as No, as in BackupProfile=No.

This “undocumented” BackupProfile property is actually quite well-documented, and even highlighted as important, in the TechNet article at

A TechNet blog post from August, 2010, at is dedicated to a problem with multiple Exchange accounts that is resolved by making the same two changes to the .PRF. The blog post helpfully points out that the manually edited .PRF file must exist in the same location as the .PRF originally used with the OCT:

NOTE: If Outlook/Exchange settings in the MSP file need to be edited in the future, the custom PRF file created to work around this issue must be copied to the same location as it was when originally imported into the OCT (i.e., C:\Custom14.PRF) on the machine that you’re running the Office Customization Tool on when modifying the MSP file.

The work yet to be done

Without further testing, it remains unclear whether the BackupProfile=False instruction, possibly in combination with other options in the .PRF, causes settings in the .PRF to be merged into the existing Outlook profile, or whether the presence of an existing profile means Outlook just doesn’t do anything with the .PRF.

Customize Outlook profiles by using an Outlook Profile (PRF) file
An existing profile can be either overwritten or updated when a new .prf file is executed. Several settings control how the new settings are applied:

The OverwriteProfile setting can be set to Yes, Append, or No. To update existing profiles, set the value to Append. This preserves the existing profile and updates the sections that have been changed. To overwrite existing profiles with a new profile, set the value to Yes. To prevent overwriting an existing profile, set the value to No.

The ModifyDefaultProfileIfPresent setting can be set to True or False. When set to True, Outlook will modify the default profile even if the new and existing profile names are different.

I would also like to better understand how the GUID-named key gets its name. The TechNet article on the Office Customization Tool in Office 2010 seems to possibly allude to the GUID being a timestamp.

Every time that you save a customization file in the OCT, the tool updates the customization file’s sequencing number with the current computer date and time stamp and generates a new update globally unique identifier (GUID).

As it seems to be the subject of some debate, I want to point out that Microsoft supports applying Setup customization .msp files to existing installations of Office 2010. I suspect, but have not attempted to confirm, that this would generate additional GUID-named keys.

Sure, Wbemtest.exe is pretty neat, and it gets points for being built-in.

Microsoft's Wbemtest.exe displaying a WMI query

Microsoft’s Wbemtest.exe displaying a WMI query

But when it comes to building WMI queries for use in scripting languages, Microsoft’s WMI Code Creator is even slicker.

The WMI Code Creator tool allows you to generate VBScript, C#, and VB .NET code that uses WMI to complete a management task such as querying for management data, executing a method from a WMI class, or receiving event notifications using WMI.

Microsoft's WMI Code Creator displaying a WMI query and VBScript

Microsoft’s WMI Code Creator displaying a WMI query and VBScript (click for full-size)

The tool also allows you to browse through the available WMI namespaces and classes on the local computer to find their descriptions, properties, methods, and qualifiers.

The WMI Code Creator utility can be downloaded from at WMI Code Creator v1.0.

I wanted to use BGInfo to display only the IPv4 address(es) of a workstation. BGInfo’s built-in IP address ouput returns both IPv4 and IPv6 formatted addresses, but you can use the output of a VBScript as a data source for a custom field. Starting with the nice script provided in the comments of the TechNet forum thread at: WMI Query to retrieve only active IPv4 address, I’ve made a few aesthetic changes so that the IPv4 addresses of active network adapters are displayed in a single column.


strMsg = ""
strComputer = "."
intCounter = 0

Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\" & strComputer & "rootcimv2")
Set IPConfigSet = objWMIService.ExecQuery("Select IPAddress from Win32_NetworkAdapterConfiguration WHERE IPEnabled = 'True'")

For Each IPConfig in IPConfigSet
 If Not IsNull(IPConfig.IPAddress) Then
 For i = LBound(IPConfig.IPAddress) to UBound(IPConfig.IPAddress)
  If Not Instr(IPConfig.IPAddress(i), ":") > 0 Then
	If intCounter > 0 Then
		strMsg = strMsg & vbcrlf & vbtab & IPConfig.IPAddress(i)
		strMsg = IPConfig.IPAddress(i)
	End If
	intCounter = intCounter + 1
  End If
 End If

Echo strMsg

Ideally, I’d be able to report whether the IP address was attached to a wired or wireless adapter, but that is beyond the scope of this particular project.

But, in the event that someone wants to do something that sophisticated, Microsoft’s WMI Code Creator v1.0 would be a very good place to start.

The WMI Code Creator tool allows you to generate VBScript, C#, and VB .NET code that uses WMI to complete a management task such as querying for management data, executing a method from a WMI class, or receiving event notifications using WMI.

Hint: look at the Description property of the Win32_NetworkAdapterConfiguration class.

I recently discovered that IE9 remembers the Compatibility View setting for a domain name, but does not remember the setting for an IP address, if the browser is closed and the option to “Delete browsing history on exit” is checked. The “Delete browsing history on exit” on is found under the General tab in Internet Options.

If you choose to view a website in Compatibility View, as a convenience to you, Internet Explorer will remember this choice and use Compatibility View the next time you visit the site. You can clear the list of websites you’ve chosen to display in Compatibility View by using the Delete Browsing History feature in Internet Explorer or the Compatibility View Settings dialog box.

Update: Hmm, actually. I think I’m wrong about this, or there’s more to it than meets the eye.