TS Gateway configuration errors

I am trying to setup TS Gateway, however when I open the manager it does not load with my server name, and when I try to manually connect I get an error stating
The Terminal Services connection authorization policies (TS CAPs) cannot be read. This problem might be due to a corrupted store for the TS CAP. Alternatively, this problem might be due to a recent password change for the Administrator account on the TS Gateway server.

If I delete c:\windows\system32\ias\ias.xml it will let me open it, but once I close it I get the error the next time I open it.

When I do have it open if I try to create a new TS CAP I enter all the details and get an error stating "WMI failure: Unable to Create Network Access Policy".

How can I solve these 2 issues?
Who is Participating?
tstritofConnect With a Mentor Commented:
Yes, it did seem far fetched. I see that you've come across the same TechNet articles.

What other services do you have installed on the server besides TSG? Any IIS or WSS sites possibly? Or anything else that could alter IIS configuration?

Would it be possible for you to post the following parts of ServerManager.log here:
- lines logged at the times when MMC fails to connect to TSG (if any)
- lines logged at the times when WMI fails to configure TS CAP
- lines from start of TSG removal to the failure of role removal


what specific OS version are you running? This seems like you're having problems with privileges to access specific folders on system drive.

Are there any errors in event logs or services failing to start?

Are you running AV software on the server? If yes have you tried the above steps with AV disabled?

Try checking security event log for any audited access failures to ias.xml or ias folder. If you dont have auditing set up enable it first through group or local policy and then configure specific auditing rules on objects you want to audit.

SkipFireAuthor Commented:
I am running WIN 2008 STD SP2

The ias.xml file can be deleted without me doing anything special, and gets recreated exactly as it should.

No services fail to start, no event log entries about TS or these errors.

I did remove AV as part of my troubleshooting and still get the error.

Nothing of interest in the security log, just log in and log off successes.
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Have you tried enabling auditing on ias folder and ias.xml through file/folder security properties? Try auditing all actions for Everyone group successful or unsuccessful. Here are the steps:

If this is not a DC open Administrative Tools > Local Security Policy. Otherwise you will have to edit the settings of Group Policy.

Check the auditing settings for object access (usually it is disabled) like in the picture below.

 Local Security Policy - Auditing not enabled
To enable auditing right click the policy and open Properties. Set them as below.

 Local Security Policy - Set policy
Be sure to return this to default setting after you finish testing otherwise your security log will be filled up by various success/failure events. After clicking OK policy setting should loke like this:

 Local Security Policy - Auditing enabled
After this locate the ias folder and setup audit for the folder and propagate settings to child objects. Right click the folder, choose Properties and open advanced security settings. Move to Auditing tab and click Continue to edit auditing properties.

 Activate folder auditing
Click the Add button and choose Everyone group and add Full Control for both sucess and failure events.

 Audit all events on a folder and subfolders
The auditing properties of ias folder should then look like this:

 Folder auditing activated
Repeat the attempt to access MMC with ias.xml in place (not deleted). If errors are encountered delete the ias.xml. Restart MMC, exit MMC, restart it again.

To minimize log impact disable auditing policy at this point. Now check your security logs. Events regarding file access have XMLs similar to this:

 Object access audited in security log
I hope this helps shed light on your problem.

SkipFireAuthor Commented:
I already did that, no failures were captured, I did see a success entry for ias.xml

I thought you didn't have auditing activated.

So to confirm:
- you verified that and TSG can access ias.xml correctly
- you didn't detect any access to ias.xml other than your own and TSGs
- your TSG, NPS and WMI services are running correctly under default accounts (Network Service, Local System and Local System respectively) with no errors in system or application log
- there are no other relevant errors in System, Application, TSG-Admin and TSG-Operational logs
- your account is a member of local administrators on the machine and member of domain admins

I'm not sure where to go from here. I've usually had useful errors logged in system or TSG-Admin log and followed instructions at TechNet to resolve issues.

If your server isn't fully updated you may try that and also if all else fails try to reinstall TSG role.

Sorry I couldn't provide more help.

SkipFireAuthor Commented:
All the assumptions were correct.  I also have everything updated.

Trying to remove the TSG role fails.

failed uninstall of TSG role is new info. Did that produce any useful info about failure reasons in event logs?

After doing some Googling about this (I'm intrigued by the unusual :)) I found a somewhat bizzare note on one technet forum stating that changing the environment variable references for %TMP% and %TEMP% to %WINDIR%\Temp (usually C\Windows\Temp) solved the issues. But there was no confirmation on that one.

It's far fetched but... Temp folders are used during various installs. Machine and user environment variables point to different TEMP/TMP locations. So if the system ever tried to access user TEMP location it would need proper privileges. Normally LOCAL_SYSTEM has full access to Users folder and that wouldn't be a problem.

The only explanation I could figure in favor of the mentioned solution is that LOCAL_SYSTEM somehow didn't have the proper privileges to user's Temp folder. One reason for that is an actual error in ACL, and the other possible reason that the Users folder is mapped to a share on another server (and thus possibly inaccessible to LOCAL_SYSTEM). However, why it would only affect TSG is something that I can't explain. Also, I don't have the appropriate environment to test this.

Anyway, if you haven't figured it out by now you may give this a try but I'm not wildly optimistic.

SkipFireAuthor Commented:
I did see the temp thing and tried that.

I wasn't able to find any informative messages from the failed attempts.
SkipFireAuthor Commented:
I have IIS with WSUS.

There wasn't anything logged aside from the error that was displayed for MMC or WMI, and I don't see anything related to the TSG removal attempt.

I thought that the TS CAP was required for TS Gateway to work but it is now working without any policy there.  I'm going to do some research about the risks of not having one specified, but I didn't plan on using it to lock down anything anyway

Thanks for all the help.
OK, good luck. After researching your problem it seems TSG install is much more sensitive than I thought. I've installed it in different environments so far and it didn't cause problems (even on SBS). Since I'll be using it in the future too for TS hosting applications I'll probably come across situation like this. If I do and manage to resolve it (I am a hands-on type) I'll let you know.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.