Hello I had a WSUS server managing updates for servers located in our dmz until it died recently. So decided to move the dmz/workgroup machines to our SCE 07 SP1 server which has been managing our internal network for nearly two years. Following other posts on the forum I eventually managed to add the dmz clients to the SCE server using certificates but their status is 'not yet contacted'. Unfortunately I've somehow screwed up our SCE server since ALL clients now have stopped contacting the SCE server. Here are some points with our current setup: - had to setup root CA on the SCE server which is also running SQL 2005 - not using proxy - cannot browse https://FQDN:8531 sites from clients - can only run console locally, remote console doesn't work anymore - can still navigate to other web services/apps hosted on SCE server - 'VerifyWUServerURL() failed with hr=0x80072efd' when running ClientDiag.exe on both clients and server - 0x80072efd also appearing in windowsupdate.log & reportingevents.log on clients I could be wrong but suspect it might have something to do with the certificates? Came across another post mentioning disjointed certificates but not sure how to fix that. Anyway any help would be appreciated...thanks!

Hello ufakom,I'm not sure why youneed a root CA. Actually, SCE 2007 cannot use the certificate which is not generated by itself. Did you ever change the following certificate from the Essentials_2007_folder\Certificates folder of the Essentials2007 management server?WSUSSSLCert.cer WSUSCodeSigningCert.cerPlease check if the certificates from the agent_installation_folder\Certificates folder on the local computer are identical from the certificates on the SCE server?If you manage the workgroup-joined computers, please follow the steps in the article below:How to Install Agents on Workgroup-joined Computers in Essentials 2007http://technet.microsoft.com/en-us/library/cc339469.aspxThe following threads may also be helpful for your scenario:The OpsMgr Connector connected to sceserver, but the connection was closed immediately after authentication occuredhttp://social.technet.microsoft.com/Forums/en-US/systemcenter/thread/4df11300-fc14-4980-8de2-75721e55e666Problem SCROM to SCE communication via a Gateway management serverhttp://social.technet.microsoft.com/forums/en-US/systemcenterrom/thread/04d90778-6692-454a-815c-2c1a149ebd39/Thanks,Yog Li - MSFT

Thanks for responding Yog Li. I was following several posts/articles in regards to managing a dmz under SCE, like the link below which is for SCOM but also applies to SCE according to one thread. http://www.stranger.nl/files/DMZ_server_monitoring_with_SCOM_2007.pdf The standalone root CA was implemented in order to set up secure communincation between the zones. We're not using a gateway, all dmz clients communicate directly with the management server. Don't believe I changed any of the certs in the Essentials_2007_folder \Certificates, just copied them to the dmz clients. The certs in "agent_installation_folder \Certificates" folders on clients (internal & dmz) are the same as those on SCE server so it may not be a certificate issue? I can still run tasks under the Actions pane for agents (including dmz) but "Last Contacted' column is over a week ago now. Have checked GPOs, SCE groups, registry entries and they are ok. Tested pushing out some software updates but clients not detecting. At this point managing dmz with SCE is the lesser of my worries. It's the clients in our internal/trust network which all have stopped calling-in/updating with our SCE server that I'm more concerned with now, especially since MS is releasing more critical security patches next week and installing these manually in the dmz involves a lot less effort than our internal network. Thanks

Hello ufakom, "Error 0x80072EFD" generally indicates that the Windows Update client did not receive a response from the Windows Update or Microsoft Update Web site. This may be caused by programs that are running on the client computer or by general network-related failures. Please read the following KB for more information. 836941 You may receive an "Error 0x80072EE2," "Error 0x80072EE7," "Error 0x80072EFD," "Error 0x80072F76," or "Error 0x80072F78" error message when you try to use the Windows Update Web site or the Microsoft Update Web sitehttp://support.microsoft.com/default.aspx?scid=kb;EN-US;836941 As you posted, you cannot browse https://FQDN:8531.Please browser https://<FQDN of SCEServer>:8531/selfupdate/wuident.cab and https://<FQDN of SCEServer>:8531/SimpleAuthWebService/SimpleAuth.asmxon problematic clients again andcheck what errormessgae prompts.Some general suggestions: 1. To check if the Anonymous access enabledFrom the IIS manager do the following1) Right click on the Selfupdate virtual directory and choose properties2) Click the Directory Security TAB3) Click the Edit button under Authentication and access control4) Ensure that Enable Anonymous access is Checked5) And that the user name entered is: IUSR_WSUS6) Also ensure that Integrated Windows authentication is checked 2. To check if IP Address Restrictions are setFrom the IIS manager do the following1) Right click on the WSUS Administration and choose properties2) Click the Directory Security TAB3) Click the Edit button under IP Address and domain name restrictions4) You can either include the servers addresses in the exception list or remove and IP address restriction completely. 3. Make sure the Authenticated Access needs to be enabled on the Selfupdate tree in IIS. Also, IIS manager enabled read checkbox and enable anonymous access for all vir directories (but not for root) in the WSUS website and also set execute permissions to SCRIPTS ONLY4. Make sure the IUSR account is configured "Allow logon locally" on SCE server. If the the problem still persists, please use steps mentioned in following KB article to re-synchronize IUSR passward: 909887 Error message when you try to view a Web site that is hosted on Internet Information Server 6.0 by using anonymous access: "401.1 Unauthorized: Logon failed"http://support.microsoft.com/default.aspx?scid=kb;EN-US;909887 More information about permission in IIS 6.0: 812614 Default permissions and user rights for IIS 6.0http://support.microsoft.com/default.aspx?scid=kb;EN-US;812614 Hope this helps.Yog Li - MSFT

Hi, As this thread has been quiet for a while, we assume that the issue has been resolved. At this time, we will mark it as "Answered" as the previous steps should be helpful for many similar scenarios. In addition, wed love to hear your feedback about the solution. By sharing your experience you can help other community members facing similar problems. Thanks,Yog Li - MSFT

Hi The issue was fixed by modifying the SCE Managed Computers gpo for stats and update server from https://scesrv.FQDN:8531 to http://scesrv:8530. All clients including the dmz ones are contacting the SCE server now and are able to download approved updates. However the majority of the clients have a Management and Monitoring status error. Also remote SCE console isn't working. Thanks

Hello ufakom, It seems like a problem of certificates. Try to run following command to delete the certificates and policies: SCECertPolocyConfigUtil.exe /uninstall /managementgroup <management group name>. After that, re-run the configure product feature wizard in SCE console and choose domain policy. Make sure the SCE GPOs are recreated and applied to all clients. Hope it helps,Yog Li - MSFT

Hello ufakom,How about the situation now? Wed love to hear your feedback about the solution. By sharing your experience you can help other community members facing similar problems.Thanks,Yog Li - MSFT