|
The following are some of the common problems customers may run into when using RTSPS. These are based on specific errors and their likely causes. Please bear in mind that some of these errors may occur under other contexts so understand that the context here is strictly related to RTSP. Common RTSPS Problem #1: Users receive the following error on publishing refresh or when trying to stream an application via RTSP:
"The specified Application Virtualization Server has shut down the connection. Try again in a few minutes. If the problem persists, report the following error code to your System Administrator." "Error Code: xxxxxx-xxxxxx0A-10000009"
This error can occur when one or more of the following conditions are true: 1.) Network Service Account (the account used to authenticate the App-V Server Service does not have access to path to the machine keys: Location for Windows 2008/R2: %ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys Location for Windows Server 2003: %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys 2.) The Certificate Store lacks the necessary permissions for the NETWORK SERVICE account. When this occurs there will also be an accompanying event in the Application Event Log:
Source: Application Virtualization
Event ID: 44955
Description: Certificate could not be loaded. Error code (-2146893043) Make sure the Network Service account has proper access to the certificate and its corresponding private key file. When this occurs in Windows Server 2003 as the underlying operating system, you will need to modify the actual certificate store permissions using the WinHttpCertCfg command. Additional information on using the WinHttpCertCfg.exe tools is available at the link below: http://msdn.microsoft.com/en-us/library/aa384088(VS.85).aspx The syntax you will need to use is: winhttpcertcfg -g -c LOCAL_MACHINE\My -s Name_of_cert -a NetworkService You can then verify that the security context was properly added by listing the permissions on the certificate using this syntax: winhttpcertcfg -l -c LOCAL_MACHINE\My -s Name_of_cert Windows Server 2008 makes the process of changing the ACLs on the private key much easier. The certificates MMC Snap-in can be used to manage private key permissions. To do so, follow these steps: 1. Create an MMC with the Certificates snap-in that targets the Local Machine certificate store. 2. Expand the MMC down to the certificate you need as shown in the image below and select Manage Private Keys. 
3. Use the Security tab to add the Network Service account with Read access. These instructions are also available in the Security Operations Guide at the following link: http://technet.microsoft.com/en-us/appvirtualization/cc843994.aspx http://download.microsoft.com/download/f/7/8/f784a197-73be-48ff-83da-4102c05a6d44/AppV_Secuirty_Operations_Guide.docx Common RTSPS Problem #2:
Users receive the following error on publishing refresh or when trying to stream an application via RTSP:
"No connection could be made because the target machine actively refused it." "Error code xxxxxx-xxxxxx2A-0000274D"
This error can happen during publishing/refresh or during streaming. It usually occurs when one or more of the following conditions are true: - Potential issue with firewall on the server running the App-V Management server or streaming server. Either create and inbound rule that allows RTSPS Port 322 or an inbound rule that allows for the application/service sghwdsptr.exe (for the dispatcher) and sghwsvr.exe (for the core.)
- Listener Port Configuration for server is configured incorrectly or the port is specified incorrectly in the OSD file.
Assuming your configuration is the default in 4.5 and later for RTSPS, watch for the following common URL errors: a. <CODEBASE HREF="RTSP://APPVSRV:554/off2010RC1_mnt/off2010RC1_mnt.sft" - Wrong Protocol b. <CODEBASE HREF="RTSPS://APPVSRV:332/off2010RC1_mnt/off2010RC1_mnt.sft" - Wrong Port (RTSPS default port changed with 4.5) c. <CODEBASE HREF="RTSPS://APPVSRV:554/off2010RC1_mnt/off2010RC1_mnt.sft" - Wrong Port (forgot to change port after changing protocol) Common RTSPS Problem #3:
Users receive the following error on publishing refresh or when trying to stream an application via RTSP:
"The certificate chain was issued by an authority that is not trusted."
"Error code: xxxxxx-xxxxxx2A-80090325" This error occurs when the cert being used on the App-V server either is not issued by a trusted authority, or if it is self-signed certificate, it has not been imported into the trusted root folder of the server's certificate store. Viewing the certificate from within the Certificates MMC-Snap-in (for local computer) will show the certificate with a red X denoting that it is not trusted. 
Self-signed certificates can be trusted by installing the certificate in the Trusted Root Certification Authorities Store. If you are using an online CA, you will need to collect certain data and verify the certificate before doing further PKI troubleshooting. Load the Certificates MMC snap-in focused on the local computer. This requires Administrator credentials. 1.) Click Start, then Run, type mmc.exe, and press Enter. 2.) Click the File Menu and select Add/Remove Snap-in. 3.) Click the Add button. Select Certificates from the list of snap-ins, and click Add. 4.) Select Computer Account, and click Next. 5.) Select Local Computer, and click Finish. 6.) Click Close, and then click Ok. 7.) Expand Certificates (Local Computer). 8.) Expand the Personal folder, and select Certificates. 9.) Export the certificate. In the list of certificates, select the one you want to export. 10.) Right-click and select All Tasks and then Export… 11.) This will start the Certificate Export Wizard. Click Next. 12.) Select No, do not export the private key. Click Next. 13.) Select DER encoded binary X.509 (.cer) and click Next. 
14.) Enter the location and file name for the file, and click Next. I usually use appvcert.cer 15.) Click Finish. Click Ok. After you are finished exporting the .CER file, you can then run the following command against it to verify the certificate: certutil -urlfetch -verify appvcert.cer >appvcert.txt As you can see, I have redirected the output to this command to a file. To quickly search for status errors, use the findstr command to list the error status for each certificate in the chain. Common items you may want to search for include: - 0x800b0109
- 0x80092013
- 0x80072ee7
- UNTRUSTED
- failed
- terminated
- Expired
To determine if the certificate is published in Active Directory run the following command: certutil -store "ldap:///CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=ForestRootDomain?cACertificate?one?objectClass=certificationAuthority" SerialNumber 
The serial number can be found by double-clicking the exported *.CER file and clicking on the "Details" tab. 
Common RTSPS Problem #4: Users receive the following error on publishing refresh or when trying to stream an application via RTSP: "The target principal name is incorrect."
"Error code: xxxxxx-xxxxxx2A-80090322" This is usually caused by the path to the server in the OSD mismatching the name specified for the certificate. It can also occur if the name specified for the publishing server via (RTSPS) does not match the name of the same machine specified in the OSD. For example: Name specified for the certificate is the FQDN but the OSD only references the NETBIOS name. Common RTSPS Problem #5: Poor Streaming Performance This was first addressed in Hotfix Package 5 for Microsoft Application Virtualization 4.5 Cumulative Update 1: August 2009 http://support.microsoft.com/?kbid=973873. It has also been included in Service Pack one for App-V 4.5. Common RTSPS Problem #6
When using RTSPS and a 3rd party Certificate Authority some clients may receive the following error message during a refresh after a user login: The revocation function was unable to check revocation because the revocation server was offline.
Error code: 450260-24C02F2A-80092013 Please see this blog post for the resolution: http://blogs.technet.com/appv/archive/2008/09/18/softgrid-app-v-client-receives-an-xxxxxx-xxxxxx2a-80092013-error-during-refresh.aspx General Tips on using self-signed certificates:
The use of certificates is much more streamlined for App-V version 4.5 and above. When constructing a certificate for use with RTSPS, you can leverage a web server template and share the certificate with an IIS service (especially if you are securing web management service access.) If bypassing Internal CA's or 3rd-party certificates, you can make use of self-signed certificates. If your App-V Server is residing on a Windows 2003 Server, you can use the SelfSSL tool from the IIS Resource Kit Utility. SelfSSL (SelfSSL.exe) can help you generate and install a self-signed SSL certificate. Information about the IIS Resource Kit can be found here: http://support.microsoft.com/kb/840671 The IIS 6.0 Resource Kit can be found here: http://www.microsoft.com/downloads/details.aspx?FamilyID=56fc92ee-a71a-4c73-b628-ade629c89499 Here are some syntax hints as well: selfssl.exe /N:CN=app-v-ms /K:1024 /V:7 /S:1 /P:443 - Creates, Installs, and Binds the Certificate. selfssl.exe /T - Adds the certificate into the Trusted Root Store You can then verify the certificate using the Certificates MMC Snap-in or CERTUTIL.EXE Ensure the certificate you generate is for Server Authentication (or both Server and Client Auth.) Pay close attention to Name and Friendly Names 
Windows Server 2008 has a built-in feature inside of the IIS Manager for creating self-signed certificates. 1.) Open IIS Manager and navigate to the server node (identified by your server name.) 2.) In Features view, double-click Server Certificates. 3.) In the Actions pane, click Create Self-Signed Certificate. 
4.) On the Create Self-Signed Certificate page, type a friendly name for the certificate in the Specify a friendly name for the certificate box, and then click OK. Hope this helps, Steve Thomas | Senior Support Escalation Engineer 
Read more at: |
