Microsoft

Could not open key UNKNOWN\Components – fixed

When attempting to install Exchange 2007 sp2 on a server I was getting the error message Could not open Key UNKNOWN\Components\ 32 hex numbers \ another 32 hex numbers (see below)
Not so useful error message when trying to install Exchange 2007 sp2.
This turned out to be occurring when the Rollup 9 package was being uninstalled. Checking into the registry and hklm \software \ microsoft \ windows \ CurrentVersion \ Installer \ UserData \ S-1-5-18 \ Components \ numbers \ numbers. Taking ownership of the parent registry key and then assigning my admin user full rights to the parent and cascading permissions would allow the procedure to continue a little bit further. Eventually after a couple of attempts I expanded the Components key in regedit using ctrl + and then used the arrow key to move all the way through, fixing permissions as required.  The lazy way would have been to set permissions at the Components Key but that may cause other problems I didn’t really want to deal with in the future.

I have no idea why the permissions were so screwed up but I really do not appreciate wasting 4 hours on a Saturday afternoon trying to fix the issue – it took a while to debug the initial errors and then more time to run the install, find out it kept causing errors with different registry locations and then navigate through the entire component tree.

The installation failed with: This patch package could not be opened – Fixed.

I have been trying to install the KB958481 patch for Microsoft Dot Net Framework 2 for many hours. Each time the installation would fail with “The installation failed with: This patch package could not be opened. Verify that the patch package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer Patch Package.”

Of course the patch file exists (I am installing it after all) and the patch file came from Microsoft so I would hope it’s valid.  Most of the suggestions seemed to resolve around removing the dotnet framework and reinstalling. All of which I had done in a variety of ways. First by uninstalling the software through add/remove programs and then through Aaron Stebner’s dotnet cleanup tool – neither of which solved the problem.

Eventually I stumbled across a tech posting (made after my initial problem started) in the Microsoft forums (first and second posting that mentioned installing the Microsoft Installer 4.5 redistributable component. After an initial reboot before installing, a reboot after installing, installing the .net patch and another reboot afterwards I was up and running and able to install the other .net patches too.

When Genuine Advantage fails to work….

I’ve had two issues with Genuine Advantage since Thursday – both issues not currently resolved. The first was a server that was restored from a ShadowProtect backup to a virtual machine on ESXI. This is to try and sort out an issue on the original server without causing any more damage to the original server. The restored server boots up fine and allows me to enter my username and password. Immediately after logging in, it then detects it needs to be activated and gives me the option to activate or cancel. If I select Yes to activate with Microsoft it should then jump into the routine of providing a set of numbers and a phone number to call Microsoft (or via the internet). Instead, this server just logs me off. Very frustrating and not useful at all.

Initially the problem was made worse due to the fact that the initial restoration meant that a normal boot insisted AD was corrupt and to go into safe mode to repair but safe mode had the same problem with Windows Activation. After a re-restore I’m not getting the AD corrupt problem but I am getting the Windows Activation issue.  On a side note, it is essential that if you restore a server with shadowprotect that has a C,D and E drive with the NTDS files stored on the E drive, then you need to restore C, then D, then E. If you restore just C and E and specify the drives are C and E, when the machine reboots the E drive will become D and your AD will corrupt itself.

So as you can see I’ve had a troubling week at work doing some restores! The good news is I know how to recover from the above problem but not when Genuine Advantage gets in the way!

The other issue was with a friends Vista machine that had the hard drive fail. I suspect the MBR got corrupted as there was initially no operating system found and my initial repair worked when I told the machine to run diagnostics and fix them and about 5 seconds later the machine was booting. However on the next reboot the system failed again. He then used the HP recovery CD to restore Vista to the machine and then after login Windows (and Security Essentials) was complaining that the copy of Windows was not genuine. However going to the Validate Windows page, the webpage shows that the pc passes with no problems found (although the computer disagrees still). Running the MGADiag tool however returns Validation Status: Invalid License, Validation Code: 50. From the support forums – “Your copy of Windows 7 is using an OEM SLP key.  This type of key only comes win Windows that come pre-installed in a computer built by a large manufacturer.  When an OEM SLP key is in uses, Windows looks to the Bios on the computer’s motherboard for a OEM Bios Flag. An OEM Bios Flag is information found only in the bios of computers built by a large manufacturer that come with Windows pre-installed. An OEM Bios Flag is specific to the Manufacturer and the version of Windows it’s good for. So, If Windows is using an OEM SLP key and the Proper OEM Bios Flag is present in the computer’s Bios, Windows will self-activate”. Of course this is all well and good until the computer does not self activate…..

I’ll update on the both of these issues when I get time to work on the machines and solve the problems.

Office 2010 almost here…

I’m running the Office2010 beta at home (mainly for Outlook and OneNote2010)  and would highly recommend it when it is finally released. If you are running Exchange2010 then there are even more reasons why you should be running Outlook2010. (Note that a lot of the extra features such as mailtips and access to the archive mailbox are already available with the outlook web access app). If you purchase and activate Office 2007 between now and Sept 30 2010, you will be able to upgrade to 2010 via a free download. You will need a LiveID, the receipt and to register your purchase. More details available at the Office2010 Technology guarantee website.

Windows7 keygen site now owned by Microsoft.

I had an interesting google alert come through the other day that found some of my content posted at a website – www.windows7keygen.com. (safe to visit.) Ensuring I had noscript switched on, I checked the site out to find that it was just scraping blogs and posting them as content on the website. I sent the host an email to request that they stopped including my site and added a todo to check back in a weeks time.

I was surprised to find a week later (5 days ago) that the site redirects to a bing search for windows7keygen. I checked whois for windows7keygen.com and found that the domain is now owned by Microsoft – along with another 29,000 domains and it looks like 22,000 of them are hosted on the same server. The domain registrar of Niobe Telekom is also unusual – I suspect that is due to the original owners registration.

I find it rather amusing that Microsoft now have control over the domain but I’m not sure how they managed to get control of it – I’m assuming a windows7 trademark threat? I would have thought that they’d have redirected it to Get Windows7 though.

Exchange2010 training from Microsoft

It’s a busy week at the office this week as I’m at a 3 day event on Exchange2010 training as part of Microsoft’s Ignite sessions. You do need to be a Microsoft Partner to register for the Exchange 2010 training (if there are any further events going on – I’m not sure) but if you are going to be using or supporting Exchange2010 then I highly recommend it. So far it seems to be very similar to the Exchange admin training courses you would normally attend, but at a fraction of the cost. It’s a level 300 course so pretty technical – by about 4pm on the first day my mind was starting to get a bit confused – there was a lot of theory today and you certainly need to have some familiarity with previous versions of exchange.

The neat thing was that we’ve just recently moved to Exchange2010 in-house, so I was able to check some of the features that I didn’t already know about on our live client (outlook or outlook web app) as we progressed through the training.

We’re using Windows2008 machines running Hyper-V with 8gb of memory which means some creative juggling of memory and sometimes the machines are slow, but it really is the only way to do the training. Some points we have 4 machines running – this would have been almost impossible before virtualization was around to reduce the hardware requirements for enterprise lab environments. This course is also the first one I’ve been to that has some users in the local office and some using gotomeeting to attend the training over the internet. So far I think the arrangement has worked well for the internet users although I feel sorry for the person in Washington who has to start work at 6am due to the time zones. I was surprised that they were not using LiveMeeting to host the training (as this is a Microsoft event) but apparently the screenupdates were not been fast enough for the remote users.

I’ll be posting a few links on my twitter account – helsbyhome, and my absoblogginlutely delicious account  as the course progresses. Mostly these are links for extra tools, utilities or downloads to assist in the management and implementation of Exchange2010.

Windows 7 Screensaver not kicking in – fixed

Had an interesting troubleshooting session this afternoon on a Windows7 pc that was no longer having the screensaver kick in. After checking the screensaver settings were being deployed via group policy, disabling wake on lan and also preventing the network card from waking up the computer/allowing the computer to be shut down, the problem still persisted. Unplugging the wireless mouse (that was a new addition by the user and not the original supplied mouse)  didn’t help either. In the end installing the latest intellipoint software and rebooting the machine fixed the problem. Just installing the software didn’t help.

It was nice that Windows7 had automatically found drivers, but it obviously needed the full software installed to work completely.

Subsequently we found a message popping up on the client pc that said the wireless signal strength was low – so it was probably the mouse trying to check in that was making the computer think activity was occurring on the pc.

Live Communicator 2005 fails to install – fixed

I had a client’s LiveCommunicator 2005 stop working and part of the troubleshooting was to remove the software and reinstall. Unfortunately, when I went to reinstall the software, the installation was interrupted and did not complete. No errors were logged in the event log but by looking at the install log file and searching for “return value 3” (standard practise when debugging msi installs) I found the following “ActivateTimeBomb. Return value 3”.  A google  search only pulled back 3 results, all for Live Communicator which was a good  sign, but I did find a posting on the appdeploy forums that offered a solution.  I had already applied this patch to the server but had not needed to apply it to the client before, but doing so fixed the problem. The patch file can be found from the kb article 974571 or a direct download.

I was suprised to see how little information was available on google and how useless the install process was. The timebomb information was hidden away in the install log and  knowing that “Return Value 3” was the key to a successful troubleshooting session.

Preparing Network Connections message at startup of SBS – solved.

Today of all days we’ve had two clients that have had their server reboot for a couple of valid reasons but after reboot the server just sat at “preparing network connections” screen and would not continue. We’re not sure right now what caused this issue but the solution was to reboot the server, press F8 and choose the Last Known Good to be able to get into the server.

Today has not been a good day for this to happen as some clients have been closed so they’ve not been around to let us in to look at the server on site but at the same time we don’t really want to wait until Monday to get access to the server, yet this is a holiday weekend.

For me, it’s been a long week . I’ve started work at 4am twice this week and was working at 1am until 2.30am last night so I doubt I’ll be staying up for NewYear – but I think I can make it until 7pm when I’ll be able to watch BigBen strike midnight.

Happy New Year everyone and I hope 2010 starts off better than 2009 finished!

Unable to rdp to Windows2008 SBS server from XP client after KB969084 installed

We had an issue when all of a sudden we were not able to remote desktop to a clients SBS 2008 server using the rdp client and the TSGateway functionality. Remote Web Workplace would work fine and so would Windows7 clients.
After proving this patch was the culprit by removing the patch and finding my saved rdp session would work, I went back and read the kbarticle 969084 on this patch. I hadn’t initially read this (in common with a lot of other people) and also because the patch was pushed down via wsus. It turns out that XP does not turn on CredSSP by default and this is needed to work with the new RDP client. I followed the instructions at kb951608 and after a reboot, going to the control box/About I got the message that Network Level Authentication was supported and I was then able to connect succesfully.
MSTSC showing Network Level Authentication Supported
To summarize you need todo the following.

  1. Click Start , click Run , type regedit , and then press ENTER.
  2. In the navigation pane, locate and then click the following registry subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  3. In the details pane, right-click Security Packages , and then click Modify .
  4. In the Value data box, type tspkg . Leave any data that is specific to other SSPs, and then click OK .
  5. In the navigation pane, locate and then click the following registry subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders
  6. In the details pane, right-click SecurityProviders, and then click Modify .
  7. In the Value data box, type credssp.dll . Leave any data that is specific to other SSPs, and then click OK .
  8. Exit Registry Editor.
  9. Restart the computer.