If your enabling DirectAccess on Forefront Unified Gateway in a lab, and you try to request an IP-HTTPS certificate for the UAG machine from your Enterprise CA, you might run into the following error:
“RPC Server Unavailable 0x800706ba”
This is because Forefront Unified Access Gateway is already installed on the machine, and TMG (Threat Management Gateway) is blocking DCOM/RPC traffic that is required to request a certificate using the MMC snap-in.
To avoid this issue, Tom Shinder’s documentation suggests that you request the IP-HTTPS certificate before you install UAG.
However, if you have already installed UAG, follow these steps to request and install the IP-HTTPS certificate:
1. Open Notepad, and paste the following code to make the INF file for the request. The only text that may need to be changed are in red.
[Version] Signature="$Windows NT$"
[NewRequest] Subject = "CN=uag1.contoso.com" ; (Replace the subject name with the external FQDN of your UAG server) Exportable = FALSE KeyLength = 2048 KeySpec = 1 KeyUsage = 0xA0 MachineKeySet = True ProviderName = "Microsoft RSA SChannel Cryptographic Provider" ProviderType = 12 SMIME = FALSE RequestType = CMC
Replace WebServer2008 with the name of your IP-HTTPS certificate template.
1. Run Command Prompt as Administrator
2. Convert the INF file to a request file (.req) certreq –new ip-https.inf ip-https.req
3. Copy the request file to your CA server (or any server that has unrestricted access to the CA machine)
4. Go to the CA server, open Command Prompt as Administrator
5. Submit the REQ file to the CA certreq –submit IP-HTTPS.req
6. Choose the CA in the popup window.
7. Save the file as IP-HTTPS.CER when prompted.
10. Copy the IP-HTTPS.CER file back to the UAG machine.
11. On the UAG machine, open the Command prompt as Administrator
12. Type: certreq –accept IP-HTTPS.cer
This will add the certificate to the local store.
13. (optional) Open the Certificates MMC for Local Computer. Open Properties for the uag1.contoso.com certificate. Give a Friendly Name “IP-HTTPS Certificate” and click OK.
If you’re looking to test DirectAccess scenarios, I highly recommend that you check out Dr. Tom Shinder’s test lab guides published on the Microsoft website.
If you are publishing RemoteApp or Remote Desktop Services on Forefront Unified Access Gateway 2010, and have enabled Single Sign On (SSO) on the RDS application in UAG, you might find that UAG tries to perform user logon on the published server using computername\username instead of domain\username.
I’ve researched this issue and found that there’s nothing I can do about it, at least at the time of writing this, as it is listed as a known issue in UAG.
Workaround
A workaround would be to ask users to log in using “domainname\username” while logging on to the UAG portal instead of just “username”.
Just a thought – you might be able to automate the appending of “domainname\” to the username string by customizing the UAG login page code, although I haven’t attempted it.
If you’re trying to enable File Access in Microsoft Forefront Unified Access Gateway 2010, you might encounter the following error when you try to configure “File Access” from “Admin” menu.
Failed to enumerate domains Please Check your permissions
Before we troubleshoot this problem, it’s important to understand how the File Access feature in UAG works. The File Access feature is dependent on the Computer Browser service. The Computer Browser service, as we all know, is used when we try to browse the network using “Network Neighborhood”, “My Network Places” or “Network”.
If the file servers are members of a domain, UAG computer has to be a member on that domain, or on a domain that has trust relationship with that domain.
To fix this error,
Make sure that Network Discovery is enabled on the Internal network connection.
Open Start > Admin Tools > Services.
Make sure the Computer Browser service is not disabled.
Make sure the Computer Browser service is set to Automatic and started.
Open “Network” on the UAG computer, and see if you can browse other computers on the internal network. If not, troubleshoot accordingly. Once you are able to browse the other computers, then UAG File Access will also work.
If you’re still facing problems,
take a look at the steps needed in mixed-mode domain environments.
if there is a firewall between UAG and the file servers, look at this article
I was trying to configure DirectAccess on UAG in a test environment, and kept getting the above error whenever I tried to activate my configuration.
The solution is simple. UAG needs two consecutive public IP addresses assigned on the external network interface. In a test environment, you would sometimes use a private IP range like 10.0.0.0 or 192.168.0.0 for the external interface, which is not supported. Also note, the UAG DirectAccess server cannot be behind a NAT.
Change the IP address on the external interface to a public IP address, and the error will go away!
On Exchange Server 2007 SP1, Exchange Troubleshooting Agent hangs/crashes after you mount the database in the recovery storage group and begin the actual ‘merge or copy mailbox’ process with the following (or similar) crash information:
Problem signature: Problem Event Name: APPCRASH
Application Name: ExTRA.exe Application Version: 8.1.240.3 Application Timestamp: 47342a91 Fault Module Name: migbase.dll Fault Module Version: 8.1.240.5 Fault Module Timestamp: 47427ba1 Exception Code: c0000005 Exception Offset: 000000000006741e OS Version: 6.0.6001.2.1.0.274.10 Locale ID: 1033 Operating System: Windows 2008 Server Time Zone: (GMT+04:00) Abu Dhabi, Muscat Alternate Language: en-US Support topic(s): Tools/ExTRA
Outlook Web Access is not currently available for the user mailbox that you are trying to access. If the problem continues, contact technical support for your organization and tell them the following: The Microsoft Exchange Client Access server that is proxying the Outlook Web Access requests is running an older version of Microsoft Exchange than the Client Access server in the mailbox Active Directory site.
If you have set up Exchange Server 2007 Client Access Servers in a CAS-CAS Proxy scenario, where the CAS server in the main site is exposed to the internet and the CAS servers in other remote locations depend on the internet-exposed CAS to proxy requests to them, users in the remote site may get the above error when they try to access their mailboxes via Outlook Web Access.
The cause is very simple. The Client Access Server in the remote site may have the latest Update Rollup for Exchange 2007 installed on it, while Client Access Server in the main site is still having an older Update Rollup.
I noticed this problem when the Client Access Server in the main site is running with Update Rollup 3, while the remote site has already got Update Rollup 4 installed. A quick install of the latest Update Rollup on all servers solved the problem.
We have a KMS Server that has been activating Vista clients for several months. A few days ago our desktop team came across the following Windows Activation error on one of the Vista Enterprise machines:
Error 0xC004F038 The computer could not be activated. The returned count from your Key Management Service is insufficient.
The KB Article 942961, which describes this error message, did not apply to us, because our KMS count is more than 25 and the article suggests that this problem only happens when the count is lesser than 25.
We resolved the issue by re-arming the Windows Activation on the client machine and then trying to do an automatic activation after a restart. Here’s how we did it:
On the offending Vista Enterprise client, type: slmgr.vbs -rearm
After a restart, type the following command on the same machine: slmgr.vbs -ato
The -rearm switch "re-arms" or "resets" the Windows Activation on the client machine. This can be done a maximum of three times per Windows Vista installation. The re-arming also extends the grace period, so it is particularly useful if you are looking for a temporary fix to buy some time while you sort out KMS issues.
Sometimes users may face problems logging in to new mailboxes created or moved in to Exchange Server 2007 when they use Outlook Web Access. Users may get error messages like the one below (abridged):
Inner Exception Exception type: Microsoft.Exchange.Data.Directory.ADOperationException Exception message: Active Directory operation failed on cs-ad-03.ad.hct.ac.ae. This error is not retriable. Additional information: Insufficient access rights to perform the operation. Active directory response: 00002098: SecErr: DSID-03150A45, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0 …
Here are some of the things that you may want to try out when you face this kind of a problem:
Make sure that the user object is inheriting permissions from the parent object. To do this,
Open ADUC.
View > Advanced features
Right click on the user choose Properties.
On Security tab click Advanced
Make sure that this object inherits permissions from parent object is checked.
Click OK
Try running the following Exchange Management Shell cmdlet: Set-Mailbox "username" -ApplyMandatoryProperties
Make sure SELF has permissions on the user account and the user mailbox.
Make sure that there are no connectivity problems between Exchange Server and Active Directory. Also make sure that a GC is available.
Installed KB940349 on the SharePoint front end server.
Installed KB941422 – Update for WSUS 3.0. After installing this KB, I had to run the SharePoint Configuration Wizard.
Start the VSS Writer service on the WSS server as per this article.
Make sure the back end SQL Servers are running SQL Server 2005 with Service Pack 2.
I followed all these steps as per the prerequisites document. However, I still got the following error:
This item cannot be protected because some prerequisite software is missing. Ensure that all prerequisite software is installed and then protect this item (ID: 31008). Click Help to view the list of prerequisite software for the selected item.
The problem was solved when KB940349 was installed on the backend SQL Server as well. All servers were restarted after installing this update. Then I went to the Management tab on the DPM 2007 console and selected Refresh Information from the Actions pane.
On returning to the Create Protection Group wizard, the error was gone.
After installing the Office Communications Server 2007 (OCS), if your users get an Address book synchronization error, it is probably because they are not able to access the Address Book shared folder that you created during the OCS setup.
Make sure you have verified the configuration as per KB938286.
On the client machine, try to browse the location https://<OCS POOL FQDN>/Abs/Int/Handler. Take care to use the OCS Pool FQDN and not the server FQDN or IP address. Make sure that your browser does not report any certificate errors. If it does, then you need to sort out the problem.
If the root CA certificate is not installed on the client machine, install it.
If the common name of the certificate is not the OCS server FQDN, you need to re-issue the certificate so that it contains your OCS Pool FQDN. This can be done by running OCS Setup and selecting the option to issue a certificate. Make sure you apply the certificate.
Once you have ironed out all the certificate errors, you should no longer get any certificate errors on IE when you navigate to the above URL. Sign out and sign in to Communicator 2007. You should be able to search the Address Book and the exclamation mark on the OCS icon should vanish.
Outlook Web Access is not currently available for the user mailbox that you are trying to access. If the problem continues, contact technical support for your organization and tell them the following: The Microsoft Exchange Client Access server that is proxying the Outlook Web Access requests is running an older version of Microsoft Exchange than the Client Access server in the mailbox Active Directory site. 
