Answered by:
Revocation Server Offline on Refresh - No Proxy

Question
-
Hi,
have the following problem:
My Environment contains several different domains that grant access to ressources via trusts (forest trusts). I have Win7 client (in DomainA)where i installed a self-signed certificate using a Certificate Server in DomainC and the App-V Client Verion 4.6 (MDOP2010 Refresh). Both, MGMT Server and Cert Server run on WS 2008R2. The Management Server resides in another Forest DomainB), but I managed to allow users in DomainA access to the App-V packages through domain trusts.
When I hit the refresh Button on the App-V Client I receive the error 4604ee8-24c0332a-80092013 and it says: "...The revocation function was unable to check revocation because the revocation server was offline."
During my research I've found only solutions that involve setting up a machine wide proxy or something similar. Unfortunately these approaches don't work for me. The client can find (ping command and others) the MGMT Server and the Cert Server. In short, they can all communicate with each other.
The certificate that is used for authentication of the MGMT Server is correctly installed on the Win7 Client (I checked the Certificate Storage) and it does not show an conflicts or problems with the certificate.
I configured DNS entries (lookup Zones, reverse lookup, cond. forwarder) on all DCs, share and security permissions on the MGMT Server's content folder (according to MS Best Practise Guide). I'm pretty sure that there is still some minor network problem left, which I haven't thought of and I would appreciate any help on the subject.
Please do not pose any questions as to whether 3 AD Domains are necessary, as I cannot influence the designed infrastructure whatsoever and need to figure out a solution in the given scenario.
Thanks in advance
Friday, January 14, 2011 3:14 PM
Answers
-
You may be overthinking this. Let's focus on the one cert that may be involved - which is the server-side cert. Assuming, since this is refresh you are using RTSPS:
1.) Is the cert bound to the server for RTSPS self-signed or issued from a CA?
2.) If it is self-signed I would say you have an underlying issue. Have you takena network trace to look at the TLS negotiation process?
3.) How is the CRL published (if using an internal CA?) By LDAP?, UNC, HTTP?
Steve Thomas, SSEE, Microsoft
App-V/MED-V/SCVMM/SCCM/AppCompat
http://madvirtualizer.wordpress.com/
The App-V Team blog: http://blogs.technet.com/appv/
The MED-V Team Blog: http://blogs.technet.com/medv
The SCVMM Team blog: http://blogs.technet.com/scvmm/
“This posting is provided "AS IS" with no warranties, and confers no rights. User assumes all risks.”- Proposed as answer by znack Monday, January 17, 2011 6:46 PM
- Marked as answer by Aaron.ParkerModerator Tuesday, January 25, 2011 11:45 AM
Friday, January 14, 2011 8:12 PM
All replies
-
There are a couple of mentions on that message in these Exchange articles:
- http://technet.microsoft.com/en-us/library/bb331963(EXCHG.80).aspx
- http://technet.microsoft.com/en-us/library/bb331963.aspx
Which indicate exactly what the message says, that being the revocation server is uncontactable. This article looks to be worth reading as well:
I did see a blog entry on this subject on the TechNet blogs recently, but unfortunately can't find it again - I'll post a link if I find it.
Here are a couple of Google searches that might help:
Friday, January 14, 2011 4:00 PMModerator -
You may be overthinking this. Let's focus on the one cert that may be involved - which is the server-side cert. Assuming, since this is refresh you are using RTSPS:
1.) Is the cert bound to the server for RTSPS self-signed or issued from a CA?
2.) If it is self-signed I would say you have an underlying issue. Have you takena network trace to look at the TLS negotiation process?
3.) How is the CRL published (if using an internal CA?) By LDAP?, UNC, HTTP?
Steve Thomas, SSEE, Microsoft
App-V/MED-V/SCVMM/SCCM/AppCompat
http://madvirtualizer.wordpress.com/
The App-V Team blog: http://blogs.technet.com/appv/
The MED-V Team Blog: http://blogs.technet.com/medv
The SCVMM Team blog: http://blogs.technet.com/scvmm/
“This posting is provided "AS IS" with no warranties, and confers no rights. User assumes all risks.”- Proposed as answer by znack Monday, January 17, 2011 6:46 PM
- Marked as answer by Aaron.ParkerModerator Tuesday, January 25, 2011 11:45 AM
Friday, January 14, 2011 8:12 PM -
Thanks for the replies.
I checked the different approaches to surmount the little hiccup. The one that actually helped was the third question from Steve. I have found out that my CRL publishing had some wrong settings. The publishment via HTTP was not possible as, for some reason, the entry existed but was not checked as use for publishing CRL and DCRL. There were also some irregularities regarding the IIS-Settings for the Virtual Directory containing the .crl files.
Thanks again and the problem is solved!
Monday, January 17, 2011 12:15 PM -
We've just found another possible cause for the same error message.
Although it is, more or less, a somewhat stupid thing, the message appears as well, if one sets up their own certificate but does not include the VERY IMPORTANT property "CRL Distribution Points". This property stores the URL or LDAP location of the CRL and if this property is not set within the certificate, then the CRL list will not be found; even if everything else on the certificate server is configured correctly.
- Proposed as answer by Aaron.ParkerModerator Friday, February 25, 2011 10:47 AM
Friday, February 25, 2011 8:03 AM