Share via

How to configure the App-V Management Server Service to run as a Service Account

  • Article

By default the App-V Management Server service is configured to run as the Network Service, but what if your company has a policy that requires the use of Service Accounts rather than running services as "Network Service" or "Local System?" If you change the service to run as a service account, users may get the following error when attempting to perform a DC Refresh:

Failure on Desktop Configuration Server request to URL {rtsp://AppVserv:554/} with header {Host: Appvserv
Content-Type: text/xml} (rc 1690722A-80090322).

Additionally, clients may get the following error attempting to launch applications:

The Application Virtualization Client could not launch <Application Name> 1.0.
The target principal name is incorrect.
Error code: 450482-1690802A-80090322

The reason for this is because when the service installs, SPN's are configured for the App-V service using the hostname. In order to successfully configure the service to run as a service account, we have to manually configure SPNs.

To configure the SPNs, you'll need to install the Support tools for the server's operating system. For Windows 2003, run the suptools.msi from Support\tools directory on the Windows 2003 Server CD. Once the support tools are installed simply follow these steps:

1. Create the service account in AD Users and Computers.

2. Add this account to the administrator group used for the App-V Administrators.

3. Run Services.msc, then right-click on Application Virtualization Management Server and select Properties.

4. Click on the Log on tab.

5. Change the NT Authority\Network Service to the service account created in Step 1 and enter the password.  Click OK.

6. Click OK to acknowledge the Services dialog box indicating that the new logon will not be in effect until the service is restarted.

7. Right-click on Application Virtualization Management Server and select Restart.

8. Assuming the Support Tools are installed on the App-V Management Server, go to Start, All Programs, Windows Support Tools, Command Prompt.

9. Enter the following 2 commands:

setspn -A SoftGrid/<FQDN of your machine> <YourDOMAIN>\<YourServiceAccountName>
setspn –A SoftGrid/<NetBIOS name of your machine> <YourDOMAIN>\<YourServiceAccountName>

Here's an example of what I ran on my lab computer:

Setspn -A SoftGrid/appvserv.contoso.local contoso\AppVSvc
Setspn -A SoftGrid/appvserv contoso\AppVSvc

10. Grant access to the Content share to the Service Account you created.

11. Add the Service Account to Logon as A Service rights in the Local Security Policy.

12. Give the Service Account Modify permissions to the Microsoft System Center App Virt Streaming Server\Logs directory.

Once you do this your users should be good to go.

Here is a link to some additional information on Setspn: https://technet.microsoft.com/en-us/library/cc773257.aspx

Here's some more security related information: https://www.microsoft.com/technet/security/midsizebusiness/topics/networksecurity/securingaccounts.mspx

Michelle Foley | App-V Support Engineer

Comments

  • Anonymous
    January 01, 2003
    By default the App-V Management Server service is configured to run as the Network Service, but what

  • Anonymous
    January 01, 2003
    UPDATE: Well, at least the icon showed up on the desktop of my client, but perhaps I spoke too soon. After clicking on the icon, I got yet another (but familiar) error that I need to figure out how to solve. Since I haven't received a reply to any of my posts, I'll contiune to post whatever I find helps, unless someone else can offer me guidance. The error is as follows: "The Application Virtualization Client could not launch Default SoftGrid Application 1.0. The Application Virtualization Server has returned an Internal System error. Report the following error code to your System Administrator. Error code: 4513CDC-690150A-200001F4" Seems to be a variation on an error I received before while trying to solve my most recent problem. Any ideas?

  • Anonymous
    January 01, 2003
    Well, I'm going to make this really simple and fudge it. I don't know how the version mis-match came to be, but it's a relatively easy fix. I only hope that these package version mis-matches will not reappear indicating a more systemic problem. To fix, open Sql Server Management Studio and connect to your SoftGrid/MS App-V database. Open the table dbo.PACKAGE_VERSIONS. Correct the version_number field to resolve the version mis-match issue. Additionally, make sure that the package GUID in the OSD file matches the package_guid field of the dbo.PACKAGES table. If not, synchronize these values as well.

I still got an error, but at this point, I don't believe there is anything wrong with my App-V setup, it's more of a package issue with the Default SoftGrid Package application, probably caused by (possibly) the original 4.2 Default SoftGrid Package application files not being deleted by the uninstall and the install of MS App-V 4.5 CU1 not overwriting the existing files (thereby updating all these inconsistencies) or even because the database already contained this package the installer updated the database but not the files, or something. In any event, this package is messed up. You can be sure that if I have any problems with any other applications, I'll be posting back. My next attempt, Adobe Reader, since that is a fairly simple application with a simple installation.

  • Anonymous
    January 01, 2003
    Apparently, that error code is a sort of catch-all error code. Looking in the sft-server.log file, the following error is displayed: [2009-0707 10:32:00.987] MYSERVER 11100 11212 SW_VersionedPackage::ValidateSFTFile - "New Provider Policy" <username> DefaultApp.sft 3 42003 "The version number of the pakcage in the datastore (2) is different from the version number in the package file in the content directory (1). So how did this happen and how might I fix this?

  • Anonymous
    January 01, 2003
    Great post, I only wished it had worked so easily for me! I had originally installed SoftGrid 4.2. I uninstalled SoftGrid 4.2, but I had already set up the database with service accounts, per the directions in Jeremey Moskowitz's book "Creating the Secured Managed Desktop". So I uninstalled SoftGrid 4.2 and installed MS App-V Management Server 4.5 CU1. After installation, I changed the service accounts to use the ones used previously in 4.2 because the service was unable to login to the database and I figured this would be the easy way to solve that problem....until I tried to connect my first client. After following the directions in this post, however, I came across a KDC error (Event ID 11): There are multiple accounts with name SOFTGRID/<myserver_fqdn> of type DS_SERVICE_PRINCIPAL_NAME. The advice per MSKB article 321044 is to find the duplicate account SPN and delete it. So, now what do I do? Any insights are greatly appreciated.

  • Anonymous
    January 01, 2003
    Funny, I spend more time than I should having to convince people that domain user/service accounts are not a must-have for running services and scheduled tasks.  I can't see the logic in it.  The Network Service account is built just for this type of situation.

  • Anonymous
    January 01, 2003
    By default the App-V Management Server service is configured to run as the Network Service, but what

  • Anonymous
    January 01, 2003
    By default the App-V Management Server service is configured to run as the Network Service, but what

  • Anonymous
    January 01, 2003
    P.S. to my last post: I tried deleting the SPNs tied to the host itself and recreating the SPNs as outlined in this article, tied to the service account. When I try to refresh the client, I get the following error message: "The Application Virtualization Client could not update publishing information from the server <Server display name>." "The server could not authorize you to access the requested data. Report the following error code to your System Administrator." "Error code: 4513CDC-16906504-00000917" Any ideas how to get around this??

  • Anonymous
    January 01, 2003
    After further searching on the web, I found another post on this blog that listed MSKB article 939327 that deals with the 00000917 error. Simply, the user is not a member of the group that's listed in the provider policy in the App-V Management Server MMC. Well, here's where things get messy. I have all users (e.g. Domain Users and Domain Admins) in the group SoftGrid Users. Here's the kicker: when I try to view the Default Provider provider policy, I get the following error: "Unexpected error occurred. Unable to retrieve Provider Policy Information. Please report the following error code to your system administrator. Error code: 0000B011" When I dismiss the error, the property pages for the policy appear with simply a General tab and the text "No properties are available on this object." Lastly, I tried creating a new provider policy and deleting the old one. While deleting the old Default Provider provider policy, the following error was displayed: "Unable to delete the Provider Policy. The Provider Policy is associated with at least one Server Group. Error Code: 0000C81A" So, now what do I do??

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    UPDATE: Got everything to work. Somehow, my Default Provider provider policy got corrupted, though I didn't see anything wrong in SQL Server Management Studio when looking at the dbo.PROVDIERS table. I compared my new provider policy I created with the default one and all the fields matched save one. When I tried to change the one field, the default provider policy was still corrupted. So, in SQL Server Management Studio, I opened the dbo.SERVER_GROUPS table and changed the provider_id field  for the Default Server Group to the new provider policy I created. But, I would recommend using the Server Management UI, instead. I just happen to know what I'm doing in SQL Server. To change this, right click the Default Server Group under the Server Groups node in the MMC and choose the Provider Policy from the drop-down list on the General tab and click ok. Then, I was able to delete the corrupted Default Provider provider policy. I restarted the Application Virtualization Management Server service and voila!, everything worked. The error listed in my last post primarily occurred because I forgot to restart the Application Virtualization Management Server service. I hope all of this will help someone else out.

  • Anonymous
    January 01, 2003
    Useful Information Thanks. :-)