Monday, June 18, 2012

Fix: SQL Server setup fails with error: "MsiGetProductInfo failed to retrieve ProductVersion for package with Product Code" (GUID)

When running SQL Server setup, SQL Server setup fails with error: "MsiGetProductInfo failed to retrieve ProductVersion for package with Product Code" which is followed by a GUID.




To fix this issue, registry entries (possibly from a previous aborted install) must be removed.

To fix, first make sure there is no installation running currently. If you have the above error on screen, close it, and exit SQL Server Setup entirely.

To locate the offending registry entries, search the registry for the first block of the GUID and remove any entries found. Then, search the registry again, except reverse the order of the first GUID block. Remove any entries found. I note that XML Parser v6 is cited when you locate the offending registry keys.





After these keys are removed you will be able to complete the install.

Thank you to Gaurang Patel for his blog post that helped me resolve this issue.

This was seen with SQL Server 2008 R2 Enterprise Edition Setup.

Monday, April 23, 2012

Fix: Cluster Available Storage not detected by SQL Server Setup

If you have shared storage showing available in Failover Cluster Manager but SQL Server Setup throws an error indicating there is no shared storage available, do the following to fix the problem:

Add the shared disks to another resource group (such as MSDTC).
Then perform the Remove From (Resource Group Name) action.

This returns the disk to Available Storage, and SQL Server Setup can now detect the shared volumes.

This was seen with SQL Server 2008 R2.

Wednesday, March 21, 2012

Fix: "Property IsLocked is not available for Login" error

Issue: SQL Server accounts (Non-AD) appear to no longer have database access. When attempting to open the account in the SSMS GUI, you receive the message:

"Property IsLocked is not available for Login '[Name_Of_Login]'. This property may not exist for this object, or may not be retrievable due to insufficient access rights. (Microsoft.SqlServer.Smo)"



This message appears due to having the "Enforce Password Policy" box checked on a SQL Server (non-AD) account.


Here is T-SQL to fix the problem:


ALTER LOGIN [login]
WITH PASSWORD = 'password' UNLOCK
,CHECK_POLICY = OFF
,CHECK_EXPIRATION = OFF


When I saw this issue recently, more than one SQL Server instance (SQL Server 2008 R2) was affected simultaneously. They were in the same AD domain, but on different hosts. This leads me to believe it is AD related, though I've found no clear acknowledgment from Microsoft on the issue. The issue has been present since SQL Server 2005.

If you want to enforce AD password policies for SQL Server access, I recommend using an AD account for accessing SQL Server. You gain all the benefits of security / account management with AD, not the least of which is Kerberos authentication. Applications which are still passing plain text passwords to SQL Server in a connection string need to be updated to support AD Authentication. I encourage you to raise this concern with your application development team and support them as they update the apps.