Windows Installer: MSI installation fails with the error status 1603

During the process of distributing an MSI package to the remote Windows Server 2012 R2 hosts via the Start-Process cmdlet, I ran across an interesting behaviour. In some cases, that MSI package was installed without any issues; in others, it was failing silently generating an event ID 10837 in the Application log.

With the verbose logging enabled, the following error message was observed in the MSI log file:

Installation success or error status: 1603.

The error status 1603 is documented on Microsoft Technet. However, none of those scenarios listed in the article applied to my case. I was able to install that MSI package locally with no issues, and the error popped up randomly when doing installation via PowerShell.

With more testing, I have realised the issue was only popping up when the user account, from which the script was running, had never previously log on to the target system.

I asked one of my colleagues, who has a better understanding of how Windows Installer works, to help with this case. After a thorough investigation, he pointed me to the following lines in the MSI log file:

MSI (s) (2C:C4) [02:22:15:584]: SECREPAIR: New Hash Database creation complete.
MSI (s) (2C:C4) [02:22:15:651]: SECREPAIR: CryptAcquireContext: Could not create the default key container
MSI (s) (2C:C4) [02:22:15:651]: SECREPAIR: Crypt Provider not initialized. Error:-2146892987

MSI (s) (2C:C4) [02:22:15:651]: SECUREREPAIR: Failed to CreateContentHash of the file: installer.msi: for computing its hash. Error: -2146892987
MSI (s) (2C:C4) [02:22:15:651]: SECREPAIR: Failed to create hash for the install source files
MSI (s) (2C:C4) [02:22:15:651]: Note: 1: 2262 2: SourceHash 3: -2147287038
MSI (s) (2C:C4) [02:22:15:651]: SECUREREPAIR: SecureRepair Failed. Error code: 8009034524E29A18
Action start 2:22:15: ProcessComponents.
The requested operation cannot be completed. The computer must be trusted for delegation and the current user account must be configured to allow delegation.

Apparently, in 2014 Microsoft released a security bulletin MS14-049 containing a patch to fix a vulnerability in the Windows Installer service. However, after you install this security update it breaks the MSI package installation. This is documented as a ‘Known issue 1’ in the bulletin and explained in more details here.

To resolve this issue, Microsoft recommends installing update 3000988.

Another option, which is documented in the same bulletin under the ‘Known issue 2’ section, is to opt-out the affected programs by using registry settings. However, this workaround implies more manual work and removes the defence-in-depth security feature for those programs.

I have tested those options and can confirm they both working. Hope this article saves you some time with troubleshooting a similar problem.

Windows: Three ways to map a network drive using PowerShell

This subject is not directly related to virtualisation. However, it can be useful when you are not going to utilise Group Policy, and still need to automate drive mapping.

The old school

net use <drive_letter:> <UNC_path_to_the_network_drive> /persistent:[yes|no]

Pros: simple command that works.

Cons: not native to PowerShell; can be deprecated in the future.

Documentation: https://technet.microsoft.com/en-us/library/bb490717.aspx.

PowerShell 3.0+

New-PSDrive -Name <drive_name> -Root <UNC_path_to_the_network_drive> -PSProvider FileSystem -Scope [Global|Local] -Persist:[$true|$false]

New-PSDrive creates temporary and persistent mapped network drives. The scope should be set to allow other applications properly use mapped drives.

Pros: native to PowerShell.

Cons: require PowerShell 3.0+ to be fully functional.

Documentation: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/new-psdrive.

PowerShell 5.0+

New-SmbMapping -LocalPath <drive_letter:> -RemotePath <UNC_path_to_the_network_drive> -Persistent:[$true|$false]

New-SmbMapping creates a Server Message Block (SMB) mapping on the SMB client to an SMB share.

Pros: native to PowerShell.

Cons: this cmdlet had some issues before PowerShell 5.0.

Documentation: https://docs.microsoft.com/en-us/powershell/module/smbshare/new-smbmapping.

 

“The device cannot start. (Code 10)” for Microsoft ISATAP and Microsoft Teredo Tunneling adapters

I was checking the system settings for one of the Windows 2008 R2 virtual machines that had been provisioned from the template recently when ran over this issue.

Both Microsoft ISATAP Adapter and Microsoft Teredo Tunneling Adapter had warning icons in the Device Manager.

ipv6-issue-01

ipv6-issue-02

Even if it is a minor obstacle, I prefer to resolve any problems with the operating system before installing and configuring applications.

After searching on Microsoft web-site, I came to the following forum thread where the user named Dork Man pointed at the DisabledComponents registry value in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters registry hive.

In my case, it has been set to a value of 0xfffffff for some reason.

ipv6-issue-03

 

I found the Microsoft KB # 929852 that explained this parameter. In this article Microsoft states the following:

…system startup will be delayed for 5 seconds if IPv6 is disabled by incorrectly, setting the DisabledComponents registry setting to a value of 0xfffffff.

Microsoft supports only the following values to configure the IPv6 protocol:

  • 0 – re-enables all IPv6 components (Windows default setting)
  • 0xff – disables all IPv6 components except the IPv6 loopback interface
  • 0x20 – makes IPv4 preferable over IPv6 by changing entries in the prefix policy table
  • 0x10 – disables IPv6 on all non-tunnel interfaces (both LAN and PPP)
  • 0x01 – disables IPv6 on all tunnel interfaces
  • 0x11 – disables all IPv6 interfaces except for the IPv6 loopback interface.

I haven’t had any specific requirements for the setting. So changing the DisabledComponents registry value to 0 and rebooting the server resolved the problem completely.