and other brilliant error messages

Category Archives: Windows

Background

The Windows 7 driver for the GMA 500 GPU has not been updated for nearly two years now (v2030 from September 2010). According to this document Intel will only support and continue to maintain the EMGD driver going forward. This is a driver for Linux and Windows primarily for embedded systems, but unfortunately its target audience is system manufacturers and not end users (it’s distributed as a driver build kit). You need quite a detailed technical understanding of the hardware you’re creating the driver for, in particular the LCD panel specifications. Sony are unlikely to provide new driver builds for a three year old laptop, and it will most likely be needed for Windows 8 compatibility. I seem to remember reading that the Windows 8 Release Preview will not accept the GMA 500 Windows 7 driver. The EMGD driver does also have one big advantage in that it includes an OpenGL ICD, which the Windows 7 GMA 500 driver has always lacked.

Thanks in part to ‘viewtiful’ on the Pocketables forum having shared the DTD details for the 1600×768 panel, several people (myself included) had built prior versions of EMGD for the VAIO P, but no one was able to get the LCD backlight working correctly. The onscreen control provided by Sony Shared Library has 8 different levels, and it would turn off the backlight completely at levels 1-3. Experimenting with building new drivers is an extremely slow and painstaking process, especially when you’re not very clear on which values may need tweaking, but I’m pleased to say that I finally got all 8 brightness levels working this evening. And rather than keeping that knowledge secret, I’m sharing it here so that other Vaio users can build their own EMGD drivers for future release versions.

Download

Method

Download and install Intel EMGD (version 1.16 from November 2012 is the latest at the time of writing). Launch the emgd-ced shortcut it has created on your desktop. This will start the java builder application.

Firstly create a new DTD called 1600×768@60Hz with settings as shown. Don’t worry about the greyed out values at the bottom of the screenshot – they’re not used.

Next create a new configuration called 16x7Sony like so:

Define the LVDS port name as MID (the name the regular GMA 500 driver uses), select the options as shown, taking care to select the custom DTD you just created:

In that same screen, click the Attributes button and set the Inverter Frequency to 300. Many thanks to Kirk over at the Intel Embedded Communities Forum for helping me to home in on this being the crucial setting. There are several mentions in the EMGD documentation of a reference value of 20300 which turns out to be incorrect for the VAIO P’s screen. I spent hours searching high and low in vain for a datasheet for this LCD panel (a Toshiba LT080EE04000). Eventually I discovered on the Notebook Review forum that a user called jeonghun had created an EMGD 1.10 build crucially with all eight backlight levels working for the VAIO X laptop which also has a GMA 500, though with a different 1366×768 panel. Since at this point I knew what to look for I opened his driver inf and discovered the magic value of 300. I took a guess that the motherboard-to-LCD circuitry would probably be similar for both models of VAIO.

Click Finish to close that window, and now click on Flat Panel Settings. The VAIO P panel is an 18bit panel. I can’t remember exactly, but I think all these values are the defaults:

Now that we’re finished with the LVDS settings (the built-in screen), click Next to move on to configuring the sDVO external monitor connection. Name it Monitor to keep it consistent with the Windows 7 GMA 500 driver. We don’t need any customization other than what is shown in this screenshot:

The final screen after this relates to building a video BIOS which we aren’t interested in so leave these settings on the defaults. Once finished, create a new package called SonyVaioP:

Finally while selecting the package, click on Generate Installation in the toolbar. This will create your zipped driver which can be found in:C:\IEMGD\IEMGD_1_16\workspace\installation\SonyVaioP.pkg_installation\IEMGD_HEAD_Windows7

I recently migrated a backup server from Windows Server 2003 to Windows 2008 R2 in order to install Backup Exec 2012 at the same time. Once I had configured everything I noticed in the iSCSI Control Panel that only one path would ever connect to the array, and I was getting regular iSCSI timeouts and failures in the System Event Log, which I hadn’t seen while running Windows 2003:

The errors were event 129:

The description for Event ID 129 from source iScsiPrt cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

event 39:

Initiator sent a task management command to reset the target. The target name is given in the dump data.

and event 9:

Target did not respond in time for a SCSI request. The CDB is given in the dump data.

Crucially these were spaced (all three together) at intervals of four minutes.

Solution

I spoke to the EqualLogic support team and, after a little while spent focusing on NIC drivers, one of the senior technicians fortunately realised that this four minute time interval coincides with the approximate frequency with which the array pings the initiators on the host and may send reconnect requests for additional path setup and load balancing. He recommended that I disable the Windows Firewall and sure enough the problem vanished. So it’s quite easy to inadvertently break iSCSI storage MPIO by making firewall settings changes to your system later on, and it’s easy to forget that these two things are related.

The problem for me was that this backup server has a NIC on the DMZ for faster backups (bypassing the hardware firewall). The pre- and post-backup job scripts enable and disable this NIC as required, but it does nonetheless need to be firewalled restrictively. In Windows 2003 the Windows Firewall can be enabled on a per NIC basis, however not in Windows 2008. Instead the firewall is configured instead in Network and Sharing Center on a per security zone basis (Domain Networks, Private Networks, Public Networks). The problem here is that the iSCSI NICs automatically end up in the Public zone, which is the most likely to be restricted. In my case, I had selected the option Block all connections including programs on the list of allowed programs. Even though the EqualLogic HIT Kit had specified an exemption rule, this was being denied.

Excluding iSCSI adapters

Relaxing the firewall in my scenario was not desirable, so I spent a while searching for a way to force the iSCSI NICs into the Private Networks zone. I couldn’t find one, though I did spot a method to exclude the NICs from the Network And Sharing Center altogether. In fact this same issue had been bothering people running VMware Workstation (because the VMware virtual NICs would get firewalled as Public Network connections), and fortunately someone had found a fix:http://www.petri.co.il/exclude-vmware-virtual-adapters-vista-2008-network-awareness-windows-firewall.htm

The solution posted there uses a PowerShell script which automatically targets VMware adapters, but we can use the same registry modification. So, on your server use Regedit to navigate to HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}. There is a child branch here for each NIC. Find your dedicated iSCSI NICs and for each one, create a new DWORD value called *NdisDeviceType (including the asterisk) and give it a value of 1. Now disable and re-enable each modified NIC. You will see that they disappear from Network and Sharing Center, and are now unaffected by the Windows Firewall.

By setting *NdisDeviceType to a value of 1 the NIC is designated as an endpoint device and is not considered to be connecting to an external network, which is probably quite appropriate for a dedicated iSCSI storage connection. I wonder whether this is the sort of thing that ought to be automated by the HIT kit in future in fact.

Preference Order

Another thing that’s easily overlooked on servers with iSCSI storage (because it’s so well hidden) is that if you have been changing NIC configs (changing drivers, adding hardware, P2V converting, etc.) then it’s quite likely that you may have affected the preference order in which network services use physical adapters. You don’t generally want the iSCSI ones to become the higher priority ones, and I have experienced strange issues with Exchange Server in the past owing to this, as well as licence issues with copy-protected software that relies on generating a unique hardware-dependent machine ID. To set the order, open Network and Sharing Center, then click on Change Adapter Settings on the left hand side. Now hold Alt, then Advanced -> Advanced Seettings. Now you can configure the LAN NICs with higher priority:

I encountered an unusual problem recently – all Windows 7 workstations which had been built with a Microsoft Select Agreement Volume License version of Windows 7 Professional RTM using an unattended install, not via sysprep, had some sort of damage to their legacy filesystem junction points. This had prevented the installer for Kaspersky EndPoint Protection 8 and its Network Agent version 9 from running, though earlier versions had been fine. The error took Kaspersky support a very long time to pin down (several months in fact, despite them having detailed MSI installer logs), and it eventually transpired that many of the links to maintain legacy OS compatibility like C:\Documents and Settings -> C:\Users, or C:\Users\All Users -> C:\ProgramData on these affected systems were resolving to some kind of temporary mounted WIM image path, within the folder C:\Users\ADMINI~1\AppData\Local\Temp\mnt\wim.

This folder no longer existed, and nor was there any phantom mounted WIM image, so any attempt to access the damaged links would fail (in Kaspersky’s case the issue was C:\ProgramData\Application Data). I still have no idea what may have caused this. More recently the unattended install I designed uses Windows 7 Enterprise SP1, with no changes to the core build scripting, and systems built from this do not exhibit this issue. This might suggest it was a problem with Windows itself, and if so then my script to fix the damage could be useful for others.

The repair script requires SetACL.exe which is an extremely versatile tool, but which is syntactically very difficult to use! I compared the ACLs on a clean system, noted the link type (they’re not all junctions, there is one symlink), and whether or not there were deny permissions which prevent recursion on links which resolve to their parent folder e.g. C:\ProgramData\Application Data -> C:\ProgramData. The links are deleted and recreated, but only on systems that are detected to need the fix (see the highlighted line for that logic). If you set line 6 to “set DEBUG=echo” you can test the output before actually invoking the repair commands.

I recently wasted a fair amount of time when I needed to restore some files which were older than the 60 days of catalog retention on the Backup Exec media server. Trying a catalog job would fail with a zero byte count after 15 minutes with the error:

I suspected bad media, so ordered an older media set from storage, but this exhibited the same problem. The error was strange because it implied that the media or the hardware was at fault, but media errors are normally clearly signposted, and often the autoloader front panel will also display this kind of error. I involved Dell Support just to rule this out, but there were no errors with the loader (nor media nor drive).

Symantec Support did figure out a solution though – it seemed as if, despite the catalogs no longer being held on the media server for these tapes, there was some kind of corruption in the Backup Exec database.

The workaround was was to select the problem tapes in the Media tab, associate them with the Retired Media Media Set, then right-click and delete them from the media view. This removes any mention of that media from Backup Exec’s database. Then rescan the autoloader’s slots in the Devices tab, and run an Inventory job on them all. Finally, run the Catalog job once again – then it works.

I’m writing this up here, because I have a vague memory of being burned by this issue once before, and it only ever strikes when you’re dealing with a data loss scenario – not a time when you want to be starting up multiple support requests and waiting hours!

I’m making a notes here for myself, mainly because a lot of the upgrade/coexistence material is over-complex when you’re dealing with a single server deployment of Exchange. I decided that the lowest impact method to transition to Exchange 2010/2007 coexistence was to leave the public DNS/smarthost settings/MX records unchanged, and simply switch the IP addresses of the servers. So the alias mail.domain.com moves from Exchange Server 2007 to 2010.

Choose a public IP address for legacy.domain.com and create a host record in your public DNS.

On your border firewall, add this new host to the same rules you have defined for mail.domain.com. Pay attention to any other rules involving this host (permitting traffic from other firewall security zones, like wifi for instance).

Make sure your SSL certificate has the following FQDNs (assuming domain.com is your public DNS domain): internal server name (exch2010.domain.local), external server name (mail.domain.com), autodiscover for your main email domains (autodiscover.domain.com), legacy for your main email domain (legacy.domain.com).

If any of these are missing, re-key your certificate (GoDaddy lets you change Subject Alternate Names without buying a new cert, as long as you bought the multiple-SAN type). Prepare the cert request using the Exchange 2010 Management Console. When GoDaddy re-key a cert they use the SANs from the original cert request, regardless of whatever is defined in the new CSR. So before you upload the CSR, edit the SANs in the GoDaddy control panel.

Import the issued certificate using the Exchange 2010 Management Console.

Double-click on the cert you downloaded from GoDaddy. In the Details pane you can double check the Subject Alterative Names, and also the Thumbprint. Make a note of that.

Use the Exchange 2010 Management Shell to assign this cert to the main services, replacing the default self-signed one:Get-ExchangeCertificate
Have a look at the current assignments, then:Enable-ExchangeCertificate -Thumbprint {Thumbprint} -Services "IIS, IMAP, POP, SMTP"

Now we need to import this same cert onto the Exchange 2007 server since it will be known as legacy.domain.com. Importing using the Exchange 2007 Management Shell cmdlet is not sufficient since the private key will not be imported. The only way I know of doing this is to export the cert from your Exchange 2010 server as a .pfx file, making sure to select the option to export the private key. Then on the Exchange 2007 server, create a dummy website with a custom host header so you don’t disrupt the running websites, enable SSL on a random port and import that .pfx certificate. Once that is done you can delete the dummy website.

Now in the Exchange 2007 Management Shell run:Get-ExchangeCertificate
to list your certs. Your new cert’s thumbprint should be listed. Now we just need to enable the new cert for the same services the old one was using. e.g.:Enable-ExchangeCertificate -Thumbprint {Thumbprint} -Services "IIS, IMAP, POP, SMTP"

You could at this point tidy up and use Remove-ExchangeCertificate to remove the old cert but there’s not much point since the Exchange 2007 server will soon be decommissioned.

In the Exchange 2007 Management Console, select Server Configuration > Client Access. For each of the service connection points (OWA, Exchange ActiveSync, OAB, etc.) ensure that the URLs are changed from mail.domain.com to legacy.domain.com.

There is another service connection point that’s not listed here in the Management GUI – the Exchange Web Services (EWS) virtual directory. Fail to migrate this one and you’ll get this error message from Outlook clients that try to edit their Out of Office settings:

Your Out of Office settings cannot be displayed, because the server is currently unavailable. Try again later.

Shut down all the Exchange services on both servers, and set the IP address of the Exchange 2007 server to the one you created in DNS for legacy.domain.com. Then reboot.

Change the IP address of the Exchange 2010 server to the one you were using for Exchange 2007. Reboot it.

Do not manually delete any DNS records at this point!

The external smarthost is configured to accept mail only from one of the Exchange servers – mail.domain.com. Rather than edit this, and wait for propagation etc. it’s probably easier just to have your Exchange 2010 server send and receive all external email.

To do this, either edit your Send Connector and change the server name, or leave it disabled and create a new connector copying the settings, but with Exchange 2010 as the source server.

At this point I had a problem with inbound mail delivery. The queue viewer showed that it was stuck at the Exchange 2010 server, and was failing to resolve internal DNS for the Exchange 2007 server. I had manually deleted the DNS entries for the two Exchange servers when I redefined their IPs. The deletion then synced to the AD/DNS at another business site and the tombstone replicated back later on – deleting the newly updated records.

As is fairly typical, the Exchange 2007 server had a separate SMTP relay receive connector defined in Server Configuration > Hub Transport, to allow web servers and monitoring scripts to send email externally. Re-creating this on the Exchange 2010 server proved problematic. It turned out that once this connector was created, the mail flow from Exchange 2007 to 2010 would also bind to it, rather than the DEFAULT connector. Since the Externally Secured option prevents some of the other auth methods being enabled, one of the Exchange 2007 server’s transport queues was stuck with this error:

451 4.4.0 Primary target IP address responded with: “451 5.7.3 Cannot achieve Exchange Server authentication.” Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts.

The solution was to create a new receive connector on the Exchange 2010 server, specific only to the legacy.domain.com IP address which matched the settings of the DEFAULT one. This can later be deleted when coexistence was is longer needed. Apparently the connectors are bound to in the order of the most specific first.

Following this migration work, it transpired that older iPhones on iOS 3.x, and Android handsets are not able to understand Exchange 2007/2010 coexistence and need the mail server name manually updating to legacy.domain.com. Also, Outlook 2003 (there’s always a legacy client with a home user somewhere!) needs to have encryption enabled for server communication.

It’s useful to have wifi support with WPA/WPA2 in Windows PE for occasions where you may want to perform an OS install or a salvage on a machine without ethernet built-in: for instance a MacBook Air running Windows or a Sony Vaio P when you don’t have the breakout dongle to hand.

When I started researching wifi support I found that the people who had clearly got it working seemed to be unwilling to share their work. One tool for the job, Holger’s PE Network Manager did not work for me at all, and judging from the dates of the files it had been created for older versions of Windows PE than the current one. There are many third party Windows PE ‘builder’ apps out there that completely replace the official Microsoft WAIK tools. However these seem more aimed at hobbyists than pros and tend to over complicate by adding features that a deployment pro does not really need. Since they’re not-so-trustworthy compiled binaries I don’t feel comfortable using them for work purposes. I decided to carefully work out for myself which registry entries and which additional files are required. There are surprisingly few.

The following unified script will use the standard WAIK tools to create both x86 and x64 builds, or either one individually, and is designed to be run by double-clicking it. Notice the defined variables at the start, particularly the %SOURCE% folder. The script expects the following folders:

I had originally wanted to connect WinPE clients to a WPA-Enterprise network but although Windows PE now supports 802.1x, it appears to work only for wired connections (see my comment on that post).

There is no GUI to manage the WLAN service, but I did find the necessary registry mod to enable the hooks already present in netsh.exe. You will need to use a working Windows 7 PC which is configured for the WLAN of your choice, then export its profile. You cannot connect to a wifi network in Windows PE without having done this. The PSK must not be encrypted since it will be imported onto a different machine (you need to run this with Administrator privileges or else the key parameter will be ignored):

Copy this XML file into the folder %SOURCE%\scripts\WinPE in the build tree. When Windows PE boots, you simply type wifi. This wifi.cmd script which is built by the main script will automatically import any XML profiles, list the available wifi networks, and display some example netsh syntax:

This one was a very obscure issue. I recently installed the first Exchange 2010 server in our infrastructure and haven’t really configured anything on it yet. It turns out that at around the same time our Exchange 2007 Unified Messaging stopped working but it took a while for anyone to notice. Long enough in fact that I strongly suspected our PABX system was at fault, especially since it has recently had some hardware failures.

The symptoms were a total inability to leave messages on the UM server, but strangely it could still be contacted by dialing the voicemail number. The audio message was something like ‘we cannot connect you at this time’. The fact that an Exchange voice prompt can be heard strongly suggests that the telecoms system is ok.

The event log errors on the Exchange server are 1082:

Event Type: Error
Event Source: MSExchange Unified Messaging
Event Category: UMService
Event ID: 1082
Date: 04/10/2011
Time: 16:05:38
User: N/A
Computer: EXCH-01
Description:
The Unified Messaging server was unable to submit messages to a Hub Transport server because there is no Hub Transport server available to process the request with UM header file “C:\Program Files\Microsoft\Exchange Server\UnifiedMessaging\voicemail429a59b-e196-4b25-940d-796c736fb93d.txt”. Make sure that there is a Hub Transport server located in the same Active Directory site as the UM server. In addition, make sure that the Microsoft Exchange Transport service is started on the Hub Transport server.

Firstly I tried increasing the Exchange UM log level but that wasn’t helpful at all. Error 500 implies some sort of auth issue so I double-checked all the certificates were valid (Get-ExchangeCertificate | fl). Then I started reading. There isn’t a huge amount on this subject (most of what’s written relates specifically to 2010) but I found this excellent write-up by Terence Luk. His were the same symptoms I was seeing, but even creating a new Hub Transport Receive Connector didn’t fix it.

What was different about my infrastructure? Well in my environment all the roles (including UM) are on the same server. So I had to telnet from the Exchange server itself to test properly. And then I noticed something strange. My Exchange server was referring to itself by the IP of one of its iSCSI NICs, which are on a private IP range. Why? No duplicate A records in DNS from spurious interface registrations, no Client or Microsoft Networks assigned on the iSCSI NICs. A simple ipconfig seemed to list them in an unusual order, with the actual Local Area Connection in the middle. This was probably the cause. Next stop Eric Reitz’s How to set/view the NIC bind order in Windows. A new menu I never new existed until this point!

And sure enough, this fixed it. The Exchange 2007 server’s NIC binding order had been like this for well over a year and never caused any issues, but I think that the addition of the first Exchange 2010 server must have raised the security, probably implementing TLS for inter-role UM traffic where it wasn’t used before.