Configuring the “Compatibility” tab

This post discusses how to configure options on the Compatibility tab for a given executable by making modifications through the registry.

There are two different ways to go about doing it, making a change for an executable for all users on a system and making a change for an executable for a single user.

When you configure an executable to run in compatibility mode, Windows XP and 7 will store that configuration change either under HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers (If the change is only for a particular user.) or HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers (If making the change for all users.) Under the Layers key, the OS creates a String value for each executable and then assigned the compatibility properties to the value of that string. For example, if you had an executable living under C:\Program Files\Adobe\Reader\AdbRd.exe and you wanted Windows 7 to run the executable in Windows XP SP3 compatility mode, you would create the following string.

Value Name: C:\Program Files\Adobe\Reader\AdbRd.exe
Data: WINXPSP3

After that string is in place, depending on where you placed the string (System or User) the next time the executable is launched it will run under Windows XP SP3 compatibility.

In addition to just defining the OS compatibility, you can also specify all the additional options that you would see on the compatibility tab using that same string value. Below I’ve listed the available options and how you would call for that option to be enabled.

Windows XP Options

Windows 95 = WIN95
Windows 98/ME = WIN98
Windows NT 4.0 SP5 = NT4SP5
Windows 2000 = WIN2000

Run in 256 Colors = 256COLOR
Run in 640 x 480 screen resolution = 640X480
Disable visual themes = DISABLETHEMES
Turn off advanced text services for this program = DISABLECICERO

Windows 7 Options

Windows 95 = WIN95
Windows 98/ME = WIN98
Windows NT 4 SP5 = NT4SP5
Windows 2000 = WIN2000
Windows XP SP2 = WINXPSP2
Windows XP SP3 = WINXPSP3
Server 2003 SP1 = WINSRV03SP1
Server 2008 SP1 = WINSRV08SP1
Windows Vista = VISTARTM
Windows Vista SP1 = VISTASP1
Windows Vista SP2 = VISTASP2
Windows 7 = WIN7RTM

Run in 256 colors = 256COLOR
Run in 640×480 screen resolution = 640X480
Disable visual themes = DISABLETHEMES
Disable desktop composition = DISABLEDWM
Disable display scaling on high DPI settings = HIGHDPIAWARE
Run this program as an Administrator = RUNASADMIN

 

When wanting to use any of the additional options other than the OS mode, you simple need to add the option on to the value data. For example, if you wanted an executable to run under Windows XP SP3 mode and also run as an Administrator, the value would look like the following. “WINXPSP3 RUNASADMIN” Luckily, the order you provide these values in doesn’t matter. So even though on the compatibility tab the run as administrator option is always at the bottom, you can specify it first and then maybe specify the run in 256 colors option last.

Quest ActiveRoles ADManagement Checker, Installer, Enabler.

The following script can be ran at the beginning of another script in order to verify that the Quest Active Roles AD Management pack is installed on a system prior to the script failing because it’s missing.

$QuestDetails = Get-WmiObject Win32_Product | Where {$_.Name -match 'Quest ActiveRoles Management Shell for Active Directory'}
$OperatingSystem = Get-WmiObject Win32_OperatingSystem
if ($OperatingSystem.OSArchitecture -eq '64-bit')
{
    if ($QuestDetails -eq $null)
    {
    $installer = "\\server\dp\smspkg\cho001c0\Quest_ActiveRolesManagementShellforActiveDirectoryx64_151.msi"
    Start-Process -FilePath msiexec -ArgumentList /i, $installer, /passive -Wait
    }
}
if ($OperatingSystem.OSArchitecture -eq '32-bit')
{
    if ($QuestDetails -eq $null)
    {
    $installer = "\\server\dp\smspkg\cho001c0\Quest_ActiveRolesManagementShellforActiveDirectoryx86_151.msi"
    Start-Process -FilePath msiexec -ArgumentList /i, $installer, /passive -Wait
    }
}

Write-Host "Successfully verified prerequisites."

if ( (Get-PSSnapin -Name Quest.ActiveRoles.ADManagement -ErrorAction SilentlyContinue) -eq $null )
{
    Add-PSSnapin Quest.ActiveRoles.ADManagement
    Write-Host "Successfully enabled the Quest AD Management Tools."
}

Write-Host "Begining to execute the script."

               

Report on users that haven’t logged on in the past X days

The following script will search and report user accounts that haven’t been logged in with within the past X number of days.

Add-PSSnapin Quest.ActiveRoles.ADManagement
Set-QADPSSnapinSettings -DefaultSizeLimit 0
function Pause ($Message=”Press any key to continue…”)
{
Write-Host -NoNewLine $Message
$null = $Host.UI.RawUI.ReadKey(”NoEcho,IncludeKeyDown”)
Write-Host “”
}
$numberofdays = Read-Host "Please enter the number of days you would like to audit."
$Date = (get-date).adddays(-$numberofdays)
Get-QADUser -SearchRoot 'domain.com/Managed/User Accounts/User Production Testing/temp' | where {$_.LastLogonTimeStamp -lt $date} | Format-Table name, LastLogonTimeStamp
Pause

               

PowerShell Snapin’s

To use cmdlets from products like Exchange or Quest AD Management tools, you have to first load the snapin. The below commands are for each of the snapin’s that I use regularly. The first two Exchange related snapins are for Exchange 2007.

Add-PSSnapin Quest.ActiveRoles.ADManagement

 

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin

 

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Support

 

Report on users created in the past X number of days

The following PowerShell script will show you all the user accounts that have been created in a defined number of days.

Add-PSSnapin Quest.ActiveRoles.ADManagement
Set-QADPSSnapinSettings -DefaultSizeLimit 0
function Pause ($Message=”Press any key to continue…”)
{
Write-Host -NoNewLine $Message
$null = $Host.UI.RawUI.ReadKey(”NoEcho,IncludeKeyDown”)
Write-Host “”
}
$numberofdays = Read-Host "Please enter the number of days you would like to audit."
$Date = (get-date).adddays(-$numberofdays)
Get-QADUser -SearchRoot 'domain.com/OU' | where {$_.whencreated -ge $date} | Format-Table name, whencreated
Pause

               

Add the ability to pause a PowerShell script

PowerShell doesn’t support the Pause command out of the box, but by doing the following you can add support for it.

First, run the following command at some point in your script prior to needing to use the Pause command.

function Pause ($Message=”Press any key to continue…”)
{
Write-Host -NoNewLine $Message
$null = $Host.UI.RawUI.ReadKey(”NoEcho,IncludeKeyDown”)
Write-Host “”
}

After the above has been processed in the script, you can use the pause command and it will display the text “Press any key to continue…” and then wait for you to press a key before continuing.

Adding drivers to WIM’s

The following will allow you to add additional drivers to Windows Vista/7, and Server 2008. (Also ConfigMgr/MDT boot media.)

First create a directory on your C: drive called images. Within that folder create a folder called Drivers, offline, and Source. Next open up the Deployment Tools Command Prompt. At this point you need to copy the wim file you want to modify to the C:\images\source folder. In this example we’ll say we’re trying to add additional drivers to an RTM Server 2008 R2 boot.wim. Now put all the drivers you want to add in the C:\images\drivers folder. They need to be actual drivers with the inf files, not just executables that install the drivers.

Now at the command prompt, type

Dism /Get-WimInfo /WimFile:C:\images\source\boot.wim

It will now display all the images contained within boot.wim. Note the name of the image that you want to add the drivers to. When you run this command against a Server 2008 R2 boot.wim you should see the following.

Now you need to mount the wim image that you want to add drivers to. Run the following command.

Dism /Mount-Wim /WimFile:C:\images\source\boot.wim /Name:”Microsoft Windows PE (x64)” /MountDir:C:\images\offline

Now you have two different possible command to run for adding drivers. The first command will only add the driver you specify. The second command will add all drivers in the Drivers folder and in sub directories.

Dism /Image:C:\images\offline /Add-Driver /Driver:C:\images\drivers\intelraiddriver.INF

 

Dism /IMage:C:\images\offline /Add-Driver /Driver:C:\Drivers /Recurse

If you need to add an unsigned driver run the following command.

Dism /Image:C:\images\offline /Add-Driver /Driver:C:\images\drivers\unsigneddriver.INF /ForceUnsigned

Once you’ve added all the drivers you need, run this last command.

Dism /Unmount-Wim /MountDir:C:\images\offline /Commit

At this point you can copy your boot.wim file back into the Server 2008 R2 installation source and you’ll have a boot.wim with all your drivers. I would also recommend adding the drivers to install.wim as well.

Hide drive letters in Explorer

The following will allow you to hide the drive letter from Explorer without hiding the drive itself. This would be useful if you wanted users to remember drive names (descriptions) rather than drive letters.

First navigate to HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer. Once there, create a DWORD and name it “ShowDriveLettersFirst”. You then give it one of the values below.

0 – Show all drive letters after drive description

1 – Show local drive letters after description and show network drive letters before drive description

2 – Display no drive letter at all

4 – Show all drive letters before the drive names

Finding old workstations in Active Directory

You can run the following command on a Server 2003 DC to find all the computer accounts that have been inactive for 5 weeks or more.

dsquery computer “OU=XP Machines,OU=Workstations,DC=domain,DC=local” -limit 0 -inactive 5 >C:\5weeks.txt

You can then use the following command to take all the computers that you found with the above command and move them to another OU.

For /F “delims=$” %c in (‘Type C:\oldcomputers.txt’) Do DSMove %c -newparent “OU=DisabledWorkstations,DC=domain,DC=local”

Exchange 2010 OWA and Mobile Devices unable to Reply, Reply to All, or Forward messages

I recently ran across a known bug with Exchange 2010 SP1. The issue was with OWA and Mobile devices. They were unable to Reply, Reply to All, or Forward messages. From OWA you would receive a message similar to the one below, titled “An unexpected error occurred and your request couldn’t be handled”. About halfway down the error message you would see the text “must be a valid domain name”.

Mobile devices would notice that all messages other than new messages they tried sending out would be stuck in their Outbox.

Ends up the issue is with the one of your Accepted Domains. You can’t have any spaces in the “Name” field of an Accepted Domain. Doesn’t matter if it had been working for several months without any problem or not… has to be renamed without any spaces.

For myself, this issue popped up for one of my clients running SBS 2011. They had a default Accepted Domain that had the name of “Windows SBS External Domain”. (3 spaces in that…) By simply running the powershell command below, I was able to rename the Accepted Domain to not include any spaces. After about 15 minutes (or a reboot of the Exchange Server…) the issue went away. Any messages in the Outbox on mobile devices will then be processed.

Set-AcceptedDomain -Identity “Windows SBS External Domain” -Name “WindowsSBSExternalDomain”