Posts Tagged ‘Microsoft’


Monday, August 6th, 2018

I recently found myself trying to upgrade an old SQL Server 2008 R2 instance to SP3 so that it could in turn be upgraded to SQL Server 2014, but quickly ran into problems with the following error message:

The INSTALLSHAREDWOWDIR command line value is not valid. Please ensure the specified path is valid and different than the INSTALLSHAREDDIR path.

At first I thought this would be pretty simple – fire up setup.exe from the command line and manually specify the INSTALLSHAREDWOWDIR and/or INSTALLSHAREDDIR options, but that would have been far too easy and unfortunately it seems that for whatever reason you can’t specify these options when the action is “patch” (update/upgrade) or “repair” – they only work for “install”, which wasn’t going to help me.

Much Googling later I had found plenty of people with similar issues, but most were struggling with initial installation (it seems that the SQL Server 2008 R2 installer was very buggy at first) rather than upgrading/updating or repairing an existing installation and so none of the fixes provided worked for me.

Eventually, after poking around the registry, I discovered that the installer is looking in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-518\Components\0D1F366D0FE0E404F8C15EE4F1C15094 key for the INSTALLSHAREDDIR path as well as the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\ Components\C90BFAC020D87EA46811C836AD3C507F key for the INSTALLSHAREDWOWDIR path.

All of the values in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\ Components\C90BFAC020D87EA46811C836AD3C507F key (INSTALLSHAREDWOWDIR) were fine (“C:\Program Files (x86)\Microsoft SQL Server\”), but one of the values (91D3749D1F6219B4BBCA0498BC14CB84) in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-518\Components\0D1F366D0FE0E404F8C15EE4F1C15094 key (INSTALLSHAREDDIR) was set to “C:\Program Files (x86)\Microsoft SQL Server\” instead of “C:\Program Files\Microsoft SQL Server\” and so the INSTALLSHAREDDIR path was conflicting with the INSTALLSHAREDWOWDIR path.

Updating the 91D3749D1F6219B4BBCA0498BC14CB84 value from “C:\Program Files (x86)\Microsoft SQL Server\” to “C:\Program Files\Microsoft SQL Server\” allowed the SP3 update to complete successfully with no reboot require for the change to take effect and I was then able to complete the upgrade to SQL Server 2014 successfully.

Not able to unsuspend a domain in Parallels Plesk

Saturday, May 25th, 2013

If you are seeing the following unhelpful message when trying to unsuspend a domain in Parallels Plesk running on Windows Server:

Warning: The domain is still suspended for the following reason: This user account and user’s domain were suspended

Then you will need to use the command line domain.exe tool to manually unsuspend the domain:

“C:\Program Files (x86)\Parallels\Plesk\admin\bin\domain.exe” –on

I’ve not seen the same behaviour on a Linux based Parallels Plesk server, but that’s not to say that it doesn’t also suffer from the same problem.

Windows Server 2008 with multiple IP addresses on one NIC

Monday, September 5th, 2011

If you are running a Windows Server 2008 installation with multiple IP addresses on one interface then you might be surprised to know that the default behaviour when selecting the IP address to use for outbound connections has changed compared to Windows Server 2003.

Previously, the “main” IP address on the adapter would have been used for initiating outbound connections and the “additional” IP addresses would be used for inbound connectivity only (unless specifically bound to by a client application, which is quite rare).

However, the new behaviour in Windows Server 2008 is that the IP address closest to the default gateway is used for outbound connections, which can catch you completely by surprise when your server’s IP address effectively changes after simply adding a new additional IP address to an interface – particularly if you are using firewalls to filter connections by IP address elsewhere in your network!

In order to provide some control which IP address is used for outbound connections, Microsoft introduced the “skipassource” flag to the netsh command. This allows you to exclude IP addresses from being used for outbound connections when managing IP addresses via netsh.

This command wasn’t initially available, so you may need to apply one of Microsoft’s hotfixes (KB975808 for Windows Server 2008 and KB2386184 for Windows Server 2008 R2). It is also possible to wipe out your carefully crafted skipassource settings using the GUI unless you apply KB2554859.

To add an IP address to the “Local Area Connection” interface with the skipassource flag set, fire up the command line and run the following (replacing <ip> <netmask&gt with the appropriate values for your network of course):

netsh int ipv4 add address “Local Area Connection” <ip> <netmask> skipassource=true

You can verify that this has worked as well as view the flags on all currently configured IP addresses using:

netsh int ipv4 show ipaddresses level=verbose