Solved

TS Gateway configuration errors

Posted on 2010-11-13
11
2,616 Views
Last Modified: 2012-05-10
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?
0
Comment
Question by:SkipFire
  • 6
  • 5
11 Comments
 
LVL 7

Expert Comment

by:tstritof
ID: 34129255
Hi,

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.

Regards,
Toislav
0
 
LVL 4

Author Comment

by:SkipFire
ID: 34129321
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.
0
 
LVL 7

Expert Comment

by:tstritof
ID: 34129462
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.

Regards,
Tomislav
0
 
LVL 4

Author Comment

by:SkipFire
ID: 34129500
I already did that, no failures were captured, I did see a success entry for ias.xml
0
 
LVL 7

Expert Comment

by:tstritof
ID: 34129576
Sorry,

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.

Regards,
Tomislav
0
Want to promote your upcoming event?

Attending an event? Speaking at a conference? Or exhibiting at a tradeshow? Easily inform your contacts by using a promotional banner in your email signature. This will ensure your organization’s most important contacts are in the know.

 
LVL 4

Author Comment

by:SkipFire
ID: 34129652
All the assumptions were correct.  I also have everything updated.

Trying to remove the TSG role fails.
0
 
LVL 7

Expert Comment

by:tstritof
ID: 34130874
Hm,

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.

Regards,
Tomislav
0
 
LVL 4

Author Comment

by:SkipFire
ID: 34130970
I did see the temp thing and tried that.

I wasn't able to find any informative messages from the failed attempts.
0
 
LVL 7

Accepted Solution

by:
tstritof earned 500 total points
ID: 34132079
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

Regards,
Tomislav
0
 
LVL 4

Author Comment

by:SkipFire
ID: 34132128
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.
0
 
LVL 7

Expert Comment

by:tstritof
ID: 34132283
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.

Regards,
Tomislav
0

Featured Post

Control application downtime with dependency maps

Visualize the interdependencies between application components better with Applications Manager's automated application discovery and dependency mapping feature. Resolve performance issues faster by quickly isolating problematic components.

Join & Write a Comment

If you migrate a Terminal Server licenses server inside the 2008 server family, you can takte advantage of the build-in migration tool. If you like to migrate an older 2003 Server (and the installed client CALs) to a 2008 R2 server for example, you …
You might have come across a situation when you have Exchange 2013 server in two different sites (Production and DR). After adding the Database copy in ECP console it displays Database copy status unknown for the DR exchange server. Issue is strange…
This tutorial will walk an individual through locating and launching the BEUtility application to properly change the service account username and\or password in situation where it may be necessary or where the password has been inadvertently change…
This tutorial will walk an individual through setting the global and backup job media overwrite and protection periods in Backup Exec 2012. Log onto the Backup Exec Central Administration Server. Examine the services. If all or most of them are stop…

747 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now