Known issues installing SQL 2008 R2 BPA relating to Remoting
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:
“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:
- Open a command prompt with Administrative Privileges
- Change to the directory where the .msi file resides
- Type msiexec /i <MSI Name> SKIPCA=1
- MSI Name will either be SQL2008R2BPA_Setup32.msi or SQL2008R2BPA_Setup64.msi depending on your platform
- Once BPA is installed, open a PowerShell prompt with Administrative Privileges
- Execute the following commands
- Enable-PSRemoting
- 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:
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
Comments
Anonymous
June 27, 2010
Thanks for the info - had the problem the day the BPA was released and this has solved the issue for meAnonymous
June 28, 2010
I want to scan our customer's servers; these servers are not in our domain, and there is no trust relationship between the domains. Is there any way to run the scan without having to RDP to each server, install the BPA tool, and run the scan locally?Anonymous
August 01, 2010
What do you mean by removing the HTTP SPN. Could you please provide an instruction, step by step how to do it.Anonymous
August 11, 2010
The comment has been removedAnonymous
September 08, 2010
The comment has been removedAnonymous
December 14, 2011
Hi Adam, It worked like a charm. Workgroup Machine fix...ThanksAnonymous
September 05, 2012
i have this problem the specified module 'baseline configuration analyzer' was not loaded because no valid module file was found in any module directoryAnonymous
November 06, 2012
I have same problem as 44 The specified module 'baseline configuration analyzer' was not loaded because no valid module file was found in any module directory Its working fine for someone else but not me.Anonymous
May 02, 2013
having way too much trouble getting this to work, please provide more detail on the SPN fixAnonymous
April 09, 2014
As a DBA in a medium size company, I'm not given domain admin access and so cannot drop and add SPNs. I find it hard to believe that this issue has been open for over 3 years and is still not resolved. If anyone has a solution that doesn't require repeated use of domain admin access, please post it.Anonymous
November 08, 2015
I needed to run an additional administrator setup for the Baseline Configuration Analyser (MBCA_Setup32_Win8.msi or MBCA_Setup64_Win8.msi) in step 3 but this helped greatly to get it installed.Anonymous
March 04, 2016
How to remove the HTTP SPN