Category: Troubleshooting

Testing for Blocked UDP Ports

By , April 22, 2013 10:36 pm

Firewalls: A love-hate relationship. When the firewall administrator has the appropriate exceptions in place, it’s mostly protecting the one you love most. But when they don’t, it feels like betrayal.

Alright, so my metaphor is off, but it is frustrating to find that, after hours of troubleshooting, that pesky application performance or availability issue was caused by a missing exception in a firewall somewhere between Host A and Host B. So more often than not, testing for a blocked port is on my troubleshooting short list these days.

So how does one test for a blocked port between two hosts? For TCP/IP ports, there are many options available, including nmap. But assuming the listener is running, I usually use a telnet client to attempt to connect to the port. An elegant test, it is not. But in most cases, it does the job just fine (as long as you have a telnet client installed).

But what about UDP ports? UDP is a different beast because it is a connectionless protocol. In other words, you can send something to the client, but don’t expect to receive a response indication of success in return. It’s true that you can sometimes determine whether a UDP port is open through alternate means, but isn’t necessarily fool-proof. Instead, the method I use is to set up a listener on the UDP port in question on the receiving host and then UDP packets to that host and port from the sending host (that is, the host that typically does the sending the UDP packets). The best part is, I can do it all using two very simple PowerShell scripts. Below are the scripts, followed by instructions.

 Receive-UDPMessage.ps1

#Waits for a UDP message on a particular port.
Param(
[parameter(Mandatory=$True,Position=0, HelpMessage='The host UDP port to send the message to')]
[Int]$Port,
[parameter(Mandatory=$False,Position=1, HelpMessage='If set, the function will continue listening for messages instead of exiting after the first one it receives. ')]
[switch]$Loop=$False
)

function Receive-UDPMessage{
[CmdletBinding(
    DefaultParameterSetName='Relevance',
    SupportsShouldProcess=$False 
)]
Param(
[parameter(Mandatory=$True,Position=0, HelpMessage='The host UDP port to send the message to')]
[Int]$Port,
[parameter(Mandatory=$False,Position=1, HelpMessage='If set, the function will continue listening for messages instead of exiting after the first one it receives. ')]
[switch]$Loop=$False
)
    try {
        $endpoint = new-object System.Net.IPEndPoint ([IPAddress]::Any,$port)
        $udpclient=new-Object System.Net.Sockets.UdpClient $port
        do  {

            Write-Host "Waiting for message on UDP port $Port..."
            Write-Host ""
            $content=$udpclient.Receive([ref]$endpoint)        
            Write-Host "Received: $content" 
            write-host "Received message: $([Text.Encoding]::ASCII.GetString($content))"
            Write-Host "Received from: $($endpoint.address.toString()):$($endpoint.Port)"

        } while($Loop)
    }catch [system.exception] {
        throw $error[0]

    } finally {
        $udpclient.Close()
    }

}

Receive-UDPMessage -Port $Port $Loop

Send-UDPMessage.ps1

#Sends a message to a host on a particular port.

Param(
[parameter(Mandatory=$True,Position=0, HelpMessage='The host to send the message to')]
[String]$Hostname,

[parameter(Mandatory=$True,Position=1, HelpMessage='The message to send')]
[String]$Message,

[parameter(Mandatory=$True,Position=2, HelpMessage='The host UDP port to send the message to')]
[Int]$Port
)

function Send-UDPMessage{
[CmdletBinding(
    DefaultParameterSetName='Relevance',
    SupportsShouldProcess=$False 
)]
Param(
[parameter(Mandatory=$True,Position=0, HelpMessage='The host to send the message to')]
[String]$Hostname,

[parameter(Mandatory=$True,Position=1, HelpMessage='The message to send')]
[String]$Message,

[parameter(Mandatory=$True,Position=2, HelpMessage='The host UDP port to send the message to')]
[Int]$Port
)
Write-Host "Message to send: $Message"
$udpclient=new-Object System.Net.Sockets.UdpClient
$b=[Text.Encoding]::ASCII.GetBytes($Message)
$bytesSent=$udpclient.Send($b,$b.length,$Hostname, $Port)
write-host "Sent: $b"
$udpclient.Close()

}

Send-UDPMessage -Hostname $Hostname -Message $Message -Port $Port

Using these scripts is simple:

  • First, you run Receive-UDPMessage.ps1 on the receiving host like so:
    Receive-UDPMessage Screenshot
    Note: If the script can’t bind to the port because it is being used by another application, it will throw an error. If that happens, you will need to temporarily stop that application.
  • Next, you run Send-UDPMessage.ps1 on the sending host like so:
    Send-UDPMessage Screenshot
  • If UDP port isn’t blocked, the receiving host should get the message the script will end. If it is blocked, you’ll get nothing.
    Receive-UDPMessage-Success

For a sanity check, you can also  try running both scripts on the same host to confirm it works (use localhost for the Hostname parameter).

Before I run off and claim sole credit for these scripts, I need to say that the original idea for them came from this page. I merely refined things a bit. Best of luck with your UDP troubleshooting!

Applying KB2506143 to an offline Windows 7 SP1 WIM = Windows Setup fail

By , January 4, 2013 12:36 pm

We use the offline servicing features of the Windows Automated Installation Kit (WAIK) to patch our images. It’s a great feature that usually saves us time and enables us to update images without constantly unsealing and resealing. But after applying the latest and greatest patches to a base Windows 7 SP1 WIM yesterday and then testing it, I began to encounter this dreaded error during Windows Setup:

Windows could not configure one or more system components. To install Windows, restart the computer and then restart the installation.

Bummer. Fortunately, since the image was serviced offline and nothing else had changed, I could reasonably assume that one of the patches was the culprit. But which one? To find out, I rebooted the system into Windows PE and opened C:\Windows\Panther\setuperr.log. Here’s what I found…

2013-01-03 18:11:12, Error                 CSI    000000fb (F) Done with generic command 8; CreateProcess returned 0, CPAW returned S_OK
    Process exit code 4294967295 (0xffffffff) resulted in success? FALSE
    Process output: [l:117 [117]"ERROR - .NET 4.0 is not installedERROR - CLRCreateInstance call failed, 0x80004001.
ERROR - Initialization failed.
"][gle=0x80004005]
2013-01-03 18:11:12, Error      [0x018007] CSI    000000fd (F) Failed execution of queue item Installer: Generic Command ({81a34a10-4256-436a-89d6-794b97ca407c}) with HRESULT HRESULT_FROM_WIN32(14109).  Failure will not be ignored: A rollback will be initiated after all the operations in the installer queue are completed; installer is reliable (2)[gle=0x80004005]
2013-01-03 18:11:14, Error                 CSI    00000107 (F) Done with generic command 9; CreateProcess returned 0, CPAW returned S_OK
    Process exit code 4294967295 (0xffffffff) resulted in success? FALSE
    Process output: [l:117 [117]"ERROR - .NET 4.0 is not installedERROR - CLRCreateInstance call failed, 0x80004001.
ERROR - Initialization failed.
"][gle=0x80004005]

It turns out that one of the updates that was installed in the offline WIM had a .NET 4.0 dependency, but the base Windows 7 SP1 image does not have .NET 4.0 installed. I would have expected the DISM utility to simply detect that .NET 4.0 was a prerequisite and skip over the update, but apparently it didn’t, or maybe there’s an issue with the update itself. At any rate, there’s no way to inject .NET 4.0 into an offline image – it requires unsealing, installing .NET 4.0, and resealing. Instead, I opted to remove the misbehaving update. To figure out which one it was, I opened setupact.log and looked for additional details that weren’t in the error log. I found these lines prior to one of the errors:

2013-01-03 18:11:12, Info                  CSI    000000f2 Begin executing advanced installer phase 38 (0x00000026) index 59 (0x0000003b) (sequence 98)
    Old component: [l:0]""
    New component: [ml:344{172},l:342{171}]"Microsoft.PowerShell.Commands.Utility-Gac.Resources, Culture=en-US, Version=7.1.7601.16398, PublicKeyToken=31bf3856ad364e35, ProcessorArchitecture=x86, versionScope=NonSxS"
    Install mode: install
    Installer ID: {81a34a10-4256-436a-89d6-794b97ca407c}
    Installer name: [15]"Generic Command"

Using Google-fu, I was able to determine that the failing component was part of KB2506143: Windows Management Framework 3.0 for Windows 7 SP1 and Windows Server 2008 R2 SP1. From there, I just needed to mount the WIM and remove the update using DISM:

dism /image:TEMP\entx64mount /remove-package /packagepath:Updates\x64\Windows6.1-KB2506143-x64.cab

After that, Windows Setup continued happily ever after

ATI Radeon Causes a UAC Prompt at User Logon

By , June 29, 2010 11:36 am

Recently, I encountered a strange issue after adding ATI Catalyst 10.4 Display Drivers to an offline Windows 7 image using the DISM.EXE /Add-Driver command. On systems that had an ATI Radeon video card, a UAC prompt would pop up the first time a user logged on and got to the desktop:

Continue reading 'ATI Radeon Causes a UAC Prompt at User Logon'»

Injecting Intel Matrix Mass Storage Drivers into a Windows XP WIM

By , May 26, 2009 8:33 am

In Classroom and Lab Computing, we use sysprep in our Windows XP imaging process so that we can support the various computer models that comprise the 4000+ computers participating in CLM, both at University Park as well as several other campuses at Penn State. Using the tools and techniques that we have developed, we are able to apply our single OS image to a machine in about 5 minutes using a USB drive. After that, the USB drive can be removed and the machine will continue to build completely unattended. Not only is the process really cool, it saves a lot of time. However, sysprep for Windows XP isn’t perfect, and with newer hardware we have run into a few caveats.

The Problem

While updating our XP image last year, we ran into a snag where the new model (a Dell Optiplex 755) refused to build when SATA operation was set to AHCI in the BIOS. This was due to a missing Intel Matrix Storage driver. Normally, drivers can easily be added to a sysprep image by injecting them into a folder within the image and then adding them to OEMPnPDriversPath in Sysprep.inf. However, these drivers are not applied until midway through the mini-setup process that runs the first time Windows boots. Without having the correct Mass Storage Driver for booting the first time, Windows will blue screen (with stop error 0x0000007B) before it can even enter mini-setup. Now that many of Dell’s newer systems come with eSata ports, it is recommended that AHCI is used for SATA operation. There is a way to insert Mass Storage Drivers when sealing a sysprep image. However, we already sealed our image for this year and wanted to avoid another reseal. Fortunately, there is a way to manually inject the drivers into the image. It’s a bit tedious, but it does work.

Manually Injecting the Intel Matrix Storage Drivers into an Windows XP image

  1. Download the Intel Matrix Storage driver (be sure it’s the latest version) from the Intel website or from the system manufacturer website. If using the Intel website, you will probably need to extract the drivers from the executable. This can be done by calling <filename>.exe -a -0 <folder path>. Folder path is the folder where the drivers will be extracted to.
    • Make sure that you have the following files: iaahci.cat, iaahci.inf, iastor.cat, iastor.inf, and iastor.sys.
  2. Open iaahci.inf with a text editor. First, look in the [version] section for the ClassGUID. Copy and paste this somewhere. Next, look for the [INTEL_HDC] section. You will see syntax similar to this:
    %PCI\VEN_8086&DEV_2681&CC_0106.DeviceDesc% = iaStor_Inst, PCI\VEN_8086&DEV_2681&CC_0106

    The portion of the line that is in red is the HardwareID. Copy and paste the HardwareID portion of each entry in [INTEL_HDC] to a separate line in an empty text file. They will be important later on.
    Note: The [INTEL_HDC.ntamd64] section below, which is below this section, can be skipped. They are the same.

  3. Open iastor.inf and note the ClassGUID.  Look for the [INTEL_HDC] again. The formatting should be the same. Once again, copy and paste each of the HardwareIds to a separate line in an empty text file.
  4. Mount your Windows XP image using imageX (imagex.exe /mountrw <path-to-wim-file> <image index #> <mount-folder-path>) . If using Ghost, you will probably have to apply the image to a separate hard drive. Last time I checked, Ghost couldn’t edit disk images that were in NTFS format. By the way, now may be a good time to look at switching from Ghost to ImageX for capturing and applying your image.
  5. Copy the driver files to the following folders:
    • Copy iaahci.inf and iastor.inf to <mount-folder-path>\Windows\inf
    • Copy iaStor.sys to <mount-folder-path>\Windows\system32\drivers
    • Copy iaahci.cat and iastor.cat to <mount-folder-path>\Windows\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
  6. The HKLM\systemxp\ControlSet001\Control\CriticalDeviceDatabase key

    The HKLM\systemxp\ControlSet001\Control\CriticalDeviceDatabase key

  7. Next, the SYSTEM registry hive from the image must be loaded. Open the Registry Editor (Start->Run->regedit.exe). Click on HKEY_LOCAL_MACHINE and then go to File->Load Hive… browse to <mount-folder-path>\Windows\system32\config and select the file named SYSTEM. When prompted to give the hive a name, type systemxp. The systemxp registry hive should not appear below HKEY_LOCAL_MACHINE.
    Note: At this point, you should take a moment to browse to <mount-folder-path>\Windows\system32\config and make a backup of your SYSTEM file in case the registry changes break something.
  8. Now that the driver files are in the right spot, a registry key must be created for each of HardwareIDs that we retrieved from iaahci.inf and iastor.inf.  The easiest way to do this is to create a .reg file that will add all of the entries to the hive. Create a blank text file and name it IntelMSD.reg. From a text editor, open IntelMSD.reg and set the first line to this:
    Windows Registry Editor Version 5.00

    Next, we need to create an entry for each of the HardwareIDs that we are adding. Here is what the syntax for each entry will look like:

    [HKEY_LOCAL_MACHINE\systemxp\ControlSet001\Control\CriticalDeviceDatabase\pci#ven_8086&dev_2929&cc_0106]
    "Service"="iaStor"
    "ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}"

    The parts in bold are what will be changed for each entry. On the first line, the red text is where the HardwareID for each entry will go. The second line is the same in each entry. The third line is where the GUID associated with that entry will go. The two ClassGUIDs that were retrieved in steps 2 and 3 will be used here. Make sure that the GUID you put is the one that was in the same .inf file as the HardwareID.

    Note: I realize that this part was a bit tricky. You can compare your .reg file with mine here to make sure your syntax is correct. Keep in mind that yours may have more entries, especially if it’s a newer version of the driver. Also, be sure that you have made a backup of your SYSTEM file in case the registry becomes corrupt.

  9. In the registry editor, go to File->Import… and browse to the IntelMSD.reg. This will load all of the registry entries into the systemxp hive. To be sure, you can browse to HKEY_LOCAL_MACHINE\systemxp\ControlSet001\Control\CriticalDeviceDatabase and check for the entries yourself.
  10. In addition to the entries created in CriticalDeviceDatabase, an entry for the iaStor service must be created. This registry file should apply the entries that are needed to HKEY_LOCAL_MACHINE\systemxp\ControlSet001\Services. To import it, go to File->Import… and browse to iaStor.reg.
  11. In regedit, click the systemxp registry hive and then go to File->Unload Hive… This will unload the XP Image SYSTEM hive so that the image can be unmounted.
  12. Unmount the image (or if using Ghost, recapture it). Test it on machines that have AHCI enabled (and use the Intel Matrix Storage Driver).

Other Mass Storage Drivers

Although I haven’t tested this, I am pretty sure that this process will work with other Mass Storage Drivers. The key to getting them to work is being able to read and understand what the inf file is doing. The Intel Matrix driver only required registry edits, and so it was fairly easy to do. For more information on inf file syntax, look at this MSDN page.

SCCM: Content downloaded to the client does not match the content specified in the content source

By , January 11, 2009 3:09 pm

There are some software packages that introduce a lot of interesting complexities that SCCM  2007 gets confused by. One of the applications that I was trying to test and deploy was giving me a particularly interesting problem: all of the clients downloaded the package, but when they checked the content, it did not match the source.

The error, which had an ID of 10057, was found by going to System Status -> Advertisement Status -> <advertisement name> -> Show Messages on the actions pane:

The program for advertisement “SIT00001 has failed because download of the content “SIT00029″ – “Per-system unattended” has failed. The download failed because the content downloaded to the client does not match the content specified in the content source.

Possible causes: The content on the distribution point has been manually modified, or a local administrator on the computer has modified the content in the computer’s hash. Solution: Refresh the content on the distribution point and retry the download.

The solution seemed obvious: update the distribution points. But multiple tries, including recreating the package and advertisement completely, did not fix the problem. Finally, I stumbled upon a forum post that helped me narrow the problem down to one of two scenarios:

Binary Differential Replication – If this is enabled in the package configuration, some packages seem to fail. I’m assuming that they can’t handle this kind of replication and several of the files become corrupt, creating a hash mismatch. This can be turned off by opening up the package properties, going to the Data Source tab, and unchecking Enable binary differential replication. This wasn’t my problem because I hadn’t enabled binary differential replication.

Hidden Files – Apparently, if the package source contains hidden files, SCCM may not calculate the correct hash for the package and clients could encounter an error. I found a quick way to check this using the command line:

  1. Open up a command window in the root director that contains your package source files.
  2. Type Dir /S /A:H and hit enter. Depending on the package, you may be presented with several directories with multiple hidden files.
  3. Trying to remove the hidden attribute on all the files with the GUI would be tedious, so just use this command instead: attrib -H /S
  4. Update the distribution points.

The package finally verified properly and the advertisement completed.


Troubleshooting SCCM and BITS Downloads

By , January 9, 2009 11:58 am

If you’re planning on using System Center Configuration Manager 2007 for its ability to distribute software over the internet and throttle large file transfers to avoid saturating the network, you may end up spending a lot of time scratching your head when packages start downloading to a client and then suddenly stop.

Such was the scenario I experienced while testing BITS with one of the applications we plan to deploy to clients. The client machine would begin the transfer and start the download… and then stop. Even worse, the issue never resolved itself, even when the machine was left running overnight. Since the issue was less-than-obvious (hint: It was not SCCM that was misconfigured) I decided to list a few tips in the BITS troubleshooting process that may be of use to others. Continue reading 'Troubleshooting SCCM and BITS Downloads'»

Deploy Vista install.wim on any drive you like (as long as it’s D:\)

By , December 3, 2008 11:34 am
Source: xkcd.com

Source: xkcd.com

While designing and testing a deployment process for Windows Vista using System Center Configuration Manager 2007 I ran into a seemingly obscure problem: Vista refused to use drive letter C as the OS Volume and instead chose D as the system drive letter. The result is that the root of the system drive was D:\ instead of C:\, which is something that legacy applications are not fond of.

This would seem like an easy problem to resolve. Surely, it is caused by the way the disk is partitioned or perhaps the drive letter that SCCM applies the image to is incorrect. Perhaps it’s a registry setting in the image file that needs to be modified offline. I experimented with all of these things, with no luck. Finally, I came across a technet blog entry that I had missed with previous Google search queries:

Several people have tried to use the install.wim from the Windows Vista installation media in an Install an existing image package task sequence.  They are surprised to discover that, upon completion, the operating system is on the D: drive instead of the C: drive. The short explanation for why this happens is that the operating system volume for the images in install.wim is D:.  In other words, when the image was captured, the reference machine had the operating system on volume D:.  Why this is the case for the install.wim that ships on the Windows Vista installation media is beyond the scope of this blog.

So essentially, you can’t use the install.wim image from Vista in SCCM if you want to use C for the system drive letter. That would have been nice to know….

Panorama Theme by Themocracy