Here is the scenario: You are leveraging an App-V Management Server that will be assigning groups from trusted domains to applications and/or provider policies. Often there are organizational changes (mergers, spin-offs, domain flattening, etc.) that will warrant domains going offline or trust removals with the current domain for which the App-V management Server belongs.
How does that affect the App-V management server in the event that these domains are no longer reachable? What will happen is those groups will not be able to resolve and “ghost” SIDs will display where the groups formerly displayed.
For example, in the example below, there are groups from two domains (SECUREPKI and CONTOSO) assigned to a default provider policy on an App-V 4.5 management server.
Once the domain CONTOSO becomes offline and no longer reachable, the Provider Policy will simply show ghosted SIDS as in the example below. Provider functionality will not be affected.
The same will also occur for application access permission assignments. The groups from the offline domain will simply display as “ghost SIDs” and the other user’s access will not be affected.
This allows for the App-V management server to remain functional while administrators clean up the decommissioned data.
How this was different with the Softgrid 4.1 Virtual Application Server
The process for previous releases of the Softgrid Virtual Application Server (what the App-V management server used to be called) resolving and accessing Active Directory was different. A special browsing account was required to access Active Directory. Account Authorities had to be configured as well. The group references were also stored in a different format within the database (see below.)
4.5 and later
Using the same example with a 4.1 server, we will see the difference in the example below:
Like with the 4.5 server, the groups are unable to resolve their SIDs. However, we have found that unresolved groups within provider policy group assignment as well as application access permissions, may cause delays.
This delay can lead to “A Network Operation did not Complete in Time” error (xxxxxx-xxxxxx0a-10000005)
With 4.1, if you have a series of applications that have many groups assigned to the application that are no longer resolvable, then you may want to provide temporary remediation for your existing users while you clean up the ghost SIDs. You can simply de-select “Enforce Application Permission Settings” in the Provider Pipeline tab in the Provider Policy dialog box.
What to look for in the SFT-SERVER.LOG file
When this issue is happening, you will likely see entries similar to below upon service start in the SFT-SERVER.LOG
[2011-11-09 19:41:13.599] APP-V-SRV1 4512 4932 SW_ADSDataConnection::FillGroupRefToSIDMap – – – – 5 – Caching(LDAP://contoso.com/<GUID=f80b836b317f7f45afb437ff7db8e741>)->(S-1-5-21-6776287-1952083785-2110791508-36630)
[2011-11-09 19:41:18.161] APP-V-SRV1 4512 4932 SW_ADSDataConnection::DomainNameToType – – – – 5 – “Domain (CONTOSO.COM) error (1355)”
When a client tries to launch an application, you will also see entries similar to below:
[2011-11-9 19:44:24.685] APP-V-SRV1 3836 4436 SW_ADSDataConnection::DomainNameToType – – – – 5 – “Domain (CONTOSO.COM) error (1355)”
[2011-11-9 19:44:42.762] APP-V-SRV1 1984 4272 SW_ADSDataConnection::FillGroupRefToSIDMap – – – – 5 – “Could Not Get Group(LDAP://CONTOSO.COM/<GUID=857fed02a9a42b4d89b7879066f327fd>)”
A slew of these entries may be present if there are a slew of unresolved groups for many applications.
Management Console Issues in Softgrid 4.1
You may also encounter the following error ” A referral was returned from the server” when trying to add groups to the Provider Policy in the Softgrid 4.1 management console. You can resolve this by changing the ASP.NET configuration of the Softgrid Management Web Service. You can change the ADReferralChasingOption to “None.” Per the following KB article: