SCVMM 2008 R2: VMM Service Crash with UnauthorizedAccessException while Gathering Information on the Source Machine
When click clicking “SCAN SYSTEM” in the SCVMM P2V (Physical to Virtual) conversion wizard, the following error occurs:
“The connection to the Virtual Machine Manager server <SERVERNAME> was lost.”
The job results will show the following error:
“The Virtual Machine Manager service on the <HOSTNAME> server stopped while this job was running. This may have been caused by a system restart.”
Further analysis will reveal that there was not a system restart, but a VMM Service crash and restart.
This can occur if there is a failure to access WMI on the source server or the source machine fails to initialize its WMI classes properly. You can verify specifics by browsing to some of the required WMI classes (Win32_processor, Win32_operating system, etc.) using a WMI browser (WMIC, WBEMTEST, etc.)
For example, you can test basic access by using the Computer management snap-in. Browse to Service and Applicatons – then to WMI control. Then right click and select properties and attempt to browse the common namespaces.
If WMI returns error messages, be aware that they may not indicate problems in the WMI service or in WMI providers. Failures can originate in other parts of the operating system and emerge as errors through WMI. See the URL below with common error codes
- 0x800410xx and 0x800440xx are WMI Operational Errors
- 0x8007xxxx are Win32 errors, not WMI errors (Often DCOM security-related)
- 0x80040xxx are DCOM errors, not WMI errors (Often DCOM configuration-related)
- 0x80005xxx are ADSI errors (LDAP), not WMI errors
There is also a web site that contains these codes in detail:
If the entire WMI repository is corrupt, try salvaging and/or rebuilding the repository using the following method:
1. Open an elevated command prompt.
2. Verify the WMI repository is not corrupt by running the following command:
If the repository is not corrupted, a “WMI Repository is consistent” message will be returned. If you get something else, go to step 3. If the repository is consistent, perform a repair.
3. Run the following commands to repair WMI:
If the repository salvage fails to work, then run the following command to see if it resolves the issue:
After the last command, there should be a “WMI Repository has been reset” message returned that verifies the command was successful.
Decommissioned or Unreachable Domains: How the App-V 4.5 Management Server handles them differently from Softgrid 4.1 Virtual Application Servers
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:
The Default Block Size of 64KB in App-V 4.6 and Later may Cause Slow Streaming with Certain Network Configurations
Starting with the 4.6 sequencer, the default block size for sequenced packages was changed to 64K. In addition, the option to adjust this was removed from the sequencer. The block size used to be an issue when the network bandwidth was limited and large blocks could not be transferred. Now with more robust networks in place, this is not a problem anymore.
With certain 4.6 client configurations (using packages sequenced on 4.6 sequencers and later) involving RTSP streaming from management servers or streaming servers, users may notice significantly longer RTSP streaming times.
If you want to set the block size lower than 64K with the App-V 4.6 sequencer, you can still do this via the command-line sequencer. This will require an installation program, script, and/or batch file that will run completely unattended. The command line parameters are found here:
You can use the /BLOCKSIZE option to specify a block size parameter of less than 64 (i.e. 32.)
To rectify this issue post-sequencing, you will need to make the following adjustments on the App-V Management server and/or streaming servers when using RTSP:
1.) If using Windows Server 2003 for your App-V Management server, you can modify the TCP/IP settings on the Windows Server 2003 App-V Management server to immediately acknowledge incoming TCP segments per the following KB article: “Slow performance occurs when you copy data to a TCP server by using a Windows Sockets API program” (http://support.microsoft.com/kb/823764).
2.) Use an alternative protocol for streaming (HTTP or SMB.)
3.) Use a third-party sequencer/packager/encoder to adjust the block size.
4.) Some of our customers have had success with adjusting TCP optimizations. For example, on servers running Windows Server 2003 Service Pack 2, you can turn on the TCP optimization feature “Receive-Side-Scaling” on by enabling the following registry parameter:
Data Type: DWORD
NOTE: This is only one part of the SNP (Scalable Network Pack features) that needs to be turned on. Other features such as offloading or TCP chimney do not need to be enabled. Please be aware of the fact that other applications that may be running on that server may not be tuned well for TCP optimizations. You will also need to reboot the server for this to take effect.
5.) For servers running Windows Server 2008 and later, it is recommended to also have the receive window auto-tuning level set to either normal or experimental in addition to RSS being enabled.
To enable TCP Auto-Tuning and RSS:
- From an elevated command prompt, run the following command:
netsh interface tcp set global rss=enabled autotuninglevel=normal
- Reboot the server.
One feature introduced into MED-V v2 is the option to allow a seamless authentication experience for the user if desired. While MED-V v1 allowed for the synchronization of the MED-V Client credentials with the user account inside the MED-V guest workspace operation system, some users wanted a more seamless experience that allowed a single sign-on process between the Windows logon to the host workstation all the way through the guest workspace authentication process. In essence, a user would only need to type his or her password only once. This was not possible in the first release of MED-V.
To facilitate this requires workspaces to be joined to the same domain as the MED-V host. This is a requirement for MED-V v2. In MED-V v2, authentication in MED-V occurs twice. W a user starts the MED-V host either credentials must be entered or saved credentials can be used. These will then need to be refreshed when a user changes their password. The first time a published application is triggered or a workspace is started via the host agent, the user will be prompted for credentials.
There are several aspects of end-user authentication that you can control, including the following:
- Caching the credentials thus storing in the Windows Credential Manager (on the host.)
- Not caching the credentials: This means every time a user starts the workspace through the host agent or triggers the workspace through a published application, the user will be required to supply a username and password.
By default, credential storing is disabled, but you can change this setting through one of the following methods:
- While you are creating the MED-V workspace package.
- After you have deployed the MED-V workspace. Edit the MED-V cmdlet parameter UxCredentialCacheEnabled to set the DisablePasswordSaving registry value.
- Modifying the DisablePasswordSaving registry value directly. This value controls whether the password saving check box appears on the MED-V (actually RDP) client dialog window and whether the MED-V credential prompt is displayed.
The DisablePasswordSaving Registry Value
This value (also a group policy option) is stored in the following key:
The value DisablePasswordSaving is either 0 or 1. If the value is 0, the MED-V prompt is presented and a check box to accept is available and cleared. If the end user selects the check box, credentials are cached for subsequent use. The end user also has the benefit of only being prompted when the password expires. If the end user does not select the check box, the Remote Desktop Connection (RDC) Client prompt is presented instead of the MED-V prompt, and the check box to accept is cleared. If the end user selects the check box, the RDC Client credential is stored for later use.
If the value is 1, the Remote Desktop Client does not validate the credentials when the end user enters them. If the end user caches the credentials through the RDC prompt, there is a risk that incorrect credentials might be stored. In this case, the incorrect credentials must be deleted in the Windows Credential Manager.
The Windows Credential Manager
Stored credentials are found in the Credential Manager control panel item on the Windows 7 host. When passwords fall out of sync, one of the first steps will be to remove any stored credentials in this item. Look for credentials beginning with the TERMSRV prefix. While caching the end user’s credentials provides the best user experience, it does pose some risks. When credential caching is enabled, the end user’s domain credential is stored in a reversible format within the Windows Credential Manager. As a result, an attacker could write a tool that runs as either a system level process or an end user process and that retrieves the end user’s credentials. You can only lessen this risk by setting DisablePasswordSaving to Enabled. This same concern exists when MED-V authentication is disabled but the Terminal Services policy setting is enabled.
By default, the MED-V installation sets a registry key in the guest to suppress the “password about to expire” prompt. The end user is only prompted for a password change on the host. Credentials that are updated on the host are passed to the guest.
If you use Group Policy in your environment, know that it can override the registry key causing the password prompts from the guest to reappear.
Username Hints for connections to the MED-V workspaces will also be stored on the host. If credentials are prompting and your policies do not allow for any credential caching, you still will have username hints. They can be purged by removing them from HKEY_CURRENTUSERSoftwareMicrosoftVirtual PCServers.
Split Domain Authentication
It is not recommended to use Split Domain Authentication scenarios for MED-V v2. This is a scenario where both the user name and user domain credentials differ between workspace and host. This also includes a local authentication to either the host or workspace. To verify the user name and domain for the MED-V workspace, launch a published command prompt and run the following commands:
Workspace Virtual PC’s joined to Different Domain
Scenarios where the workspace operating system is joined to a different domain than the host computer are not supported.