Known issues installing SQL 2008 R2 BPA relating to Remoting

  • Article

After getting through the Pre-Reqs for BPA (PowerShell 2.0, MBCA, .NET Framework), you may hit one of two scenarios when installing BPA.

In all of the cases of an install failure, you will see the following error:

image

“There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.”

In your Application Event Log, for both of these scenarios, you will also see the following entry:

Log Name: Application
Source: MsiInstaller
Date: 6/10/2010 8:38:18 AM
Event ID: 11722
Task Category: None
Level: Error
Keywords: Classic
User: <Username>
Computer: <Machine name>
Description:
Product: Microsoft SQL Server 2008 R2 BPA -- Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action EnablePSRemoting, location: powershell.exe, command: -NoLogo -NoProfile -Command Enable-PSRemoting -force

Workgroup (aka Non-Domain) Machine:

In this scenario, the Enable-PSRemoting command should execute fine from a PowerShell prompt.  The actual error coming back from the PowerShell command within the Installer is “Access Denied”. 

To workaround the issue you can do the following:

  1. Open a command prompt with Administrative Privileges
  2. Change to the directory where the .msi file resides
  3. Type msiexec /i <MSI Name> SKIPCA=1
    1. MSI Name will either be SQL2008R2BPA_Setup32.msi or SQL2008R2BPA_Setup64.msi depending on your platform
  4. Once BPA is installed, open a PowerShell prompt with Administrative Privileges
  5. Execute the following commands
    1. Enable-PSRemoting
    2. winrm set winrm/config/winrs `@`{MaxShellsPerUser=`"10`"`}

This should allow BPA to be successfully installed in the workgroup scenario.

Kerberos Failure:

The second scenario is that you are failing with the above due to a Kerberos issue.  This particular issue could actually show up after you have installed BPA depending on how you have configured your environment.

The issue stems from the fact that the Windows Remoting Windows Service uses the Network Service account.  Windows Remoting also uses SOAP calls over HTTP and defaults to using Kerberos.  As a result, it will be using the HOST Service Principal Name (SPN) that is on the Machine Account as it is running under that context.  You may have an HTTP SPN that resides on a different account with that host name.  For example, if you are running an IIS Web Application such as SharePoint, or if you are using Reporting Services and the service account is set to a Domain User account instead of Network Service or Local System.  If your URL of your application matches the machine name, then your HTTP SPN will be the same.  That’s where this problem comes in.  WinRM will stop working at that point and give you a message similar to the following.

Set-WSManQuickConfig : WinRM cannot process the request. The following error occured while using Negotiate authentication: An unknown security error occurred.
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
-For more information about WinRM configuration, run the following command: winrm help config.
At line:50 char:33
+ Set-WSManQuickConfig <<<< -force
+ CategoryInfo : InvalidOperation: (:) [Set-WSManQuickConfig], InvalidOperationException
+ FullyQualifiedErrorId : WsManError,Microsoft.WSMan.Management.SetWSManQuickConfigCommand

You can get this type of error from WinRM for muliple reasons.  The one that we saw in our testing was the HTTP SPN scenario.

If you do have an HTTP SPN defined on a Domain Account that is using the name of your machine, you have some options.  First you can follow the steps mentioned above to get BPA installed.  The Enable-PSRemoting command will give you the above error.  You can temporarily remove the HTTP SPN to get remoting enabled and then re-add the HTTP SPN.

Once BPA is setup, you will still not be able to run BPA if you put the HTTP SPN back in place.  You will see the following when you attempt to perform a scan:

image

This will occur regardless of which component you try to scan.  It could be the Engine, Setup, RS, etc…

The only way to perform the scan successfully would be to temporarily remove the HTTP SPN again.  Run the scan, and then put the HTTP SPN back in place.  Another option, but one that will probably require further testing from your application’s end, would be to run the application under a Host Header and then your HTTP SPN would not include the machine name, allowing BPA to run with out issue.  It’s not ideal though.

Unfortunately, the above options for the Kerberos issues are not really all that great.  Hopefully this will not be that common.

Adam W. Saxton | Microsoft SQL Server Escalation Services
https://twitter.com/awsaxton