Udostępnij za pośrednictwem

App-V 4.5 Remote Console Configuration Guide

  • Artykuł

Big Bad JohnB published the most awesome of guides around the App-V 4.5 Remote Console. We have been having some fun on the support side around the remote management of the console! And John Behneman put his head down and decided to get to the bottom of them! Not only did he do this sooooo well, but he decided to type up his detailed notes over on the App-V Blog.

 

Heeeeerrrreeeee’s Johnny! :o)

--------------------------------------------------------------------

If you have ever tried to setup an App-V Remote Management Console or upgraded your existing 4.1 SoftGrid environment to App-V 4.5 just to have the Remote Management Console stop working this post is for you. Lately we have received a number support calls regarding this issue and discovered that we don’t have any App-V specific documentation on how to set this up, this post will address this issue in detail.

image

Consider the configuration above, all Servers are Windows 2003 SP2 servers A represents a SQL 2005 Failover Cluster hosting the AppVirt Database, B is 2 IIS 6 servers with the App Virt Management (Web) Service component installed and load balanced with NLB C is 2 servers with the App Virt Management Server and Console installed also load balanced with NLB. D is essentially any XP, Vista or Win2kX with the App Virt Management Console component installed on it. For the App-V 4.5 Remote Console to work in the configuration mentioned above you must configure or verify that the following is true:

1. Both the B IIS 6servers must have their machine accounts delegated in Active Directory

image

2. The cluster server virtual name A and the 2 B IIS 6 servers must have the appropriate Service Principal Names (SPNs) defined in Active Directory

The App-V IIS (B) Servers must have the following SPNs assigned to either it’s machine account or to the Domain Service account if the Application Virtualization Management Service is running under a context other than the Network Service account (Default Settting for 4.5)

SoftGrid/<ServerNetBiosName>
SoftGrid/<ServerFQDN_Name>

The SQL 2005 (A) servers must have the follow SPNs assigned to them, since this is a Failover Cluster and the App-V IIS Management servers are configured to access the AppVirt Database via the ClusterName then there has to be a SPN for the SQL Servers ClusterName if it is a standalone SQL server then replace the ClusterName with the name of the standalone server.

MSSQLSvc/<FQDN ClusterName>:1433
MSSQLSvc/<NetBios ClusterName>:1433

Please Note: If you use SETSPN.exe to set SQL server SPNs you need to use the latest version. I have run into an issue using an older version that would not allow you to add the :1433 suffix to the SPN it would fail with a Syntax message if this happens to you please download the Win2k3 SP2 version of the tool.
Updates to the Windows Server 2003 Support Tools are included in Windows Server 2003 Service Pack 2 https://support.microsoft.com/kb/926027

3. If a service account is used for the Application Virtualization Management Service then this account must be trusted for delegation, insure that the “Account is sensitive and cannot be delegated” is not checked, FYI - this could be set in a Group Policy.

image

If you are still running a Windows 2000 AD you may need to set “Account is trusted for delegation” on the Service Accounts used on the A SQL Cluster and B servers.

image

How to Verify and Set the proper SPNs

There are 2 tools that you can use to create, delete and list SPNs, the easiest one to use in my opinion is SetSPN.exe, Ldifde is good for locating or documenting SPNs in AD:

1. Setspn.exe – Support Tool

2. Adsiedit.msc – Support Tool

3. Ldifde – built-in tool (Windows 2003)

The simplest way to create, delete and list SPNs is to use SetSPN.exe

First find out what context your Application Virtualization Management Server and SQL Server (MSSQLSERVER) Services are running under, by default the Application Virtualization Server Service runs under the Network Service account which translates into the Servers Machine account. If it is a Domain Service account then you would run the SetSpn.exe against the Domain Service account. SPNs are by default registered when an application is installed, therefore if you leave these services set to their default context you should not have to worry about if the SPNs are register correctly. But you should still verify that they are there if you are having authentication issues with your Remote App-V management console.

To find the SPNs registered for the Machine Account run the following command:

setspn –L MachineName

To find the SPNs registered for the Service Account run the following command:

setspn –L Domain\ServiceAccountName

Here is an example of the output you should see, notice the SoftGrid SPNs:

clip_image010

You will also notice that there are no SPNs for my SQL server service, SQL 2005 is installed on this box and apparently did not register it’s SPNs for this service. Well, hold on, I just discovered that my SQL server Service is running under the Domain Administrator account:

clip_image012

Let’s see if it is registered under this account:
clip_image014

Well what do you know there it is! Lets go ahead and add the netbios name SPN registration just for good measure.
clip_image016

Lets pipe our list to find searching for “MSSQLSvc” and see what SPNs we have now.

clip_image018

We now have a SQL SPN for both the FQDN and NetBios name. Just for grins and so you can see how to delete a SPN if you need to, let’s delete the one we just created.

clip_image020

Now lets list them out again we should see that the MSSQLSvc/45RTM-DC:1433 is now gone:

clip_image022

Looks like it did. So in review here are the three commands you need to List (-L), Create (-A) and Delete (-D) SPNs:

To List:

Setspn –L <AD Machine or Domain Account>

Remember SPNs are registered with an AD object either a Machine account or User Account.

To Register:

Setspn –A MSSQLSvc/<ServerFQDN or NetBios Name>:1433 <domain\AccountName>

Remember to run this command twice to register both the FQDN and NetBios names of the Machine. If you are registering a SQL SPN remember to add the port Suffix if you are running SQL on a port other than 1433 (default) make sure you change it here to reflect the correct port. Adding a port suffix is not required for the SoftGrid service, this port suffix seems to be unique to the SQL service.

To Delete:

Setspn –D MSSQLSvc/<ServerFQDN or NetBios Name>:1433 <domain\AccountName>

Here is a couple of screenshots of using Adsiedit.msc to access and modify SPNs, all you do is start the MMC and find the Active Directory Object that you need to modify…

clip_image024

Right click on it and select Properties; you will be presented with the screen below:

clip_image026
Scroll down until you find the servicePrincipalName attribute highlight it and click edit and make whatever changes you need.

clip_image028

Adsiedit.msc provides a better perspective regarding the association between the SPNs and the Machine or Service account it is registered to. Once you understand this association I think setspn is the fastest way to register a SPN but use whatever tool you feel most comfortable with. Both tools get the job done.

Using a lidfde utility to find SPNs

You can run the following command line to output all the SPNs registered for a specific type of SPN, in the following example we are searching for ALL SQL SPNs in the directory not just the ones associated with a given Active Directory Object. You can obviously change the servicePrincipalName value to whatever SPN value you wish to find.

ldifde -f check_spn.txt -t 3268 -d "" -l servicePrincipalName -r "(servicePrincipalName=MSSQLSvc/*)" -p subtree

This script comes in handy when you need to clean up old SPNs that are no longer needed. If you recall I mentioned previously that when you install an application it will automatically register the SPNs it needs for the default service account its service uses, if you then change the service account to use a domain account you should createdthe SPNs for this new account and delete them from the old account. In large Active Directory infrastructures having spurious SPNs registered in AD can cause problems for applications that reference SPNs to find services and resources. The best policy is to find and delete any spurious SPNs lingering in your Active Directory Infrastructure.

Conclusion of Part 1

Now that you have your App-V infrastructure configured properly to support App-V 4.5 Remote Console functionality you should be able to access your App-V Management Servers remotely. If this is not the case and you are receiving errors we will be covering the troubleshooting and known issues in subsequent posts in this series. One of the first things I would try is using a different account that has proper access rights, IIS 6 has a 16k Kerberos token size limit by default and if you are using an account that is a member of a lot of AD groups you may be exceeding this limit. I will get into more on this in my next post…
Here is a hint on a workaround:

955585 CLM: HTTP Bad Request (Request header too long)
https://support.microsoft.com/default.aspx?scid=kb;EN-US;955585

Many thanks to Michelle Foley, Justin Zarb, Steve Thomas, Sam Allen, Frank Szita, Raj Yarlagadda and others for the collaboration needed to create this blog posting.

References:

Setspn Overview
https://technet.microsoft.com/en-us/library/cc773257.aspx

The following is the contents of the C:\MSAppVirt_wd_client_setup_4.5.0.1485\AppVReadme.htm file relevant to SPNs and delegation the information is also found here:
https://technet.microsoft.com/en-us/library/cc817171.aspx :

To distribute the management components across multiple servers, Kerberos delegation must be enabled on the server where the Web service is installed.

When using IIS 6.0 or 7.0 for icon or OSD file retrieval and streaming of packages, for Kerberos authentication to be enabled, the following SPNs must be registered, as follows:

On the IIS server, run the following commands using the SETSPN.EXE Resource Kit tool. The server Fully Qualified Domain Name (FQDN) must be used.

Setspn -r SOFTGRID/<Server FQDN>
Setspn -r HTTP/<Server FQDN>

326985 How to troubleshoot Kerberos-related issues in IIS
https://support.microsoft.com/default.aspx?scid=kb;EN-US;326985

319723 How to use Kerberos authentication in SQL Server
https://support.microsoft.com/default.aspx?scid=kb;EN-US;319723

How to: Enable Kerberos Authentication on a SQL Server Failover Cluster
https://msdn.microsoft.com/en-us/library/ms189585(sql.90).aspx

How to use SPNs when you configure Web applications that are hosted on IIS 6.0
https://support.microsoft.com/kb/929650

Authentication delegation through Kerberos does not work in load-balanced architectures
https://support.microsoft.com/kb/325608

John Behneman | App-V and SCVMM Support Engineer

Comments