Windows Installer: Logging

These handy reg files for increasing the logging level of Windows Installer came in useful today:


LoggingOn.reg

Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]
"Logging"="voicewarmupx"
"Debug"=dword:00000007[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace]
"Flags"=dword:00000016
"Level"=dword:00000004



LoggingOff.reg

Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]
"Logging"=-
"Debug"=-
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace]


In most cases, the Windows Installer log starts with msi, ends with a .log extension, and
includes a group of characters. For example, the Windows Installer log will have a file name that resembles the following:

msib3a6g.log

You should be able to find it in the %temp% path.

The letters in the value field can be in any order. Each letter turns on a different logging mode. Each letter's actual function is as follows for MSI version 1.1:


v - Verbose output

o - Out-of-disk-space messages

i - Status messages

c - Initial UI parameters

e - All error messages

w - Non-fatal warnings

a - Start up of actions

r - Action-specific records

m - Out-of-memory or fatal exit information

u - User requests

p - Terminal properties

+ - Append to existing file

! - Flush each line to the log

x - Extra debugging information. The "x" flag is available only on Windows Server 2003 and later operating systems, and on the MSI redistributable version 3.0, and on later versions of the MSI redistributable.

"*" - Wildcard, log all information except for the v and the x option. To include the v and the x option, specify "/l*vx".



Sean

WSUS: Clients overwriting each other

I discovered an interesting issue recently where a number of machines that were clones of each other were using the same IDs to report to WSUS and were therefore constantly overwriting each other in the WSUS database.

A quick run of this script against the machines was able to force a change of those IDs and set a registry entry flag so that if the script were run again (such as from a computer startup GPO), it wouldn't reset the IDs again.

Set oShell = CreateObject("WScript.Shell")

sRegKey = "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate"

' suppress error in case values does not exist
On Error Resume Next

' check for marker
sIDDeleted = oShell.RegRead( sRegKey & "\IDDeleted")

' to be sure values is only deleted once, test on marker
If sIDDeleted <> "yes" Then
' delete values
oShell.RegDelete sRegKey & "\AccountDomainSid"
oShell.RegDelete sRegKey & "\PingID"
oShell.RegDelete sRegKey & "\SusClientId"

' Stop and start the Automatic updates service
oShell.Run "%SystemRoot%\system32\net.exe stop wuauserv", 0, True
oShell.Run "%SystemRoot%\system32\net.exe start wuauserv", 0, True

' Run wuauclt.exe with resetauthorizations
Cmd = "%SystemRoot%\system32\wuauclt.exe /resetauthorization /detectnow"
oShell.Run sCmd, 0, True

' create marker
oShell.RegWrite sRegKey & "\IDDeleted", "yes"
End If

We actually chose to run the script on the target machines using SCHTASKS.EXE from the Support Tools. I created a text file containing the names of all of the target machines and simply ran this script:

@echo off
FOR /F %%i IN (WSUS_Fix_Targs.txt) DO (
schtasks /create /tn "%%i_WSUS_SID_Fix" /tr "wscript.exe \\server\share\WSUS_Fix.vbs" /sc once /st 15:00 /ru domain\adminuser /rp userpassword /z /s %%i
)