Mandatory Terminal Services Profiles and Novell Client

I like quick logins, and I hate managing profiles, so i typically use mandatory profiles on my Citrix servers if it serves only a couple of specific applications.  I recently noticed some wierd behavior on some of my server regarding the mandatory profiles.

If a user logged in, their username was appended to the profile location where the mandatory profile is stored.  I used Group Policy “Set TS Roaming Profile Path” and in this setting, checked the box “Do not append the user name to profile path”

TS Profile Path GPO

TS Profile Path GPO

I checked the registry where this option is stored (HKLMSoftwarePoliciesMicrosoftWindows NTTerminal ServicesWFDontAppendUserNameToProfile) and it existed and was enabled.  For some reason the server was just ignoring it.  I recreated the GPO, checked my system.adm template date, still not working.

I managed to find one forum post on the web with someone else attributing this problem to the Novell client, which is on this server.  He was running 4.91 SP2, I am running 4.91 SP3.  Novell is at SP4 at the time of this writing, so I upgraded asap.  Problem resolved.  Chalk another problem up to Novell client.  At least they fixed the issue in SP4, otherwise my mandatory profiles would be quite un-mandated.



I want to take a moment to plug some great software for enterprise or small shop auditing of systems.  Open-AudIT is an open source, web based auditing system for computers on your network.  It is available from  I’ve found this software very useful in our environment.  It uses WMI to get loads of information about systems and stores them in mySQL database.  The PHP frontend is very easy to use and easily customizable even if you only know a little PHP.  I don’t consider myself an expert by any means, but I’ve constructed a few custom queries that we use often.

The downloadable version is great, but keeping up with their SVN repository really shows where the development of this software is going.  The forums on the site have been very helpful to me, and the fact that all the developers discuss and modify the code frequently really shows that they are doing this project to help people.

So, if you are looking for cool software to inventory, audit, and track systems on your network, I highly recommend you give Open-AudIT a try.  Even if you don’t like it, which I doubt, you’re out nothing but time.

Changing AAC SQL db

Today, one of our SQL servers went down. Unfortunately it held our Citrix Farm Datastore and AAC (Advanced Access Control) database. The dbas were able to get the dbs moved over to another SQL server quickly. Changing SQL servers for a farm is relatively simple; change the SQL server name in the DSN file on each server and restart the IMA service. But what about the AAC server? Where do I change it on there?
A call to Citrix revealed some registry keys to change and then the Configuration utility will run again. I was freaking out because the Server Configuration utility was not running and giving an error. Here’s what to do:

  1. Open Registry Editor and browse to HKEY_LOCAL_MACHINE/Software/Citrix/AccessObjects, backup the CitrixAGEServer key just in case you need to restore previous configuration, then delete the CitrixAGEServer key.
  2. Browse to HKEY_LOCAL_MACHINE/Software/Citrix/MSAM/ServerConfigured and change the value from 1 to 0.
  3. Run the server configuration wizard.

You’ll need to know your SQL server, database name, database credentials, and service account credentials.  It should then find your previous configuration once you complete the wizard.  Make sure that the SQL credentials are dbowner and IIS is currently running.

adminSDHolder in Active Directory

Last week, we decided we wanted a select handful of Helpdesk Leads to be able to reset passwords on other helpdesk and support role associate’s accounts.  For the longest time, the helpdesk associates were unable to reset passwords due to rights, but because this particular directory was old, we never looked into why.  Once we started looking, we did not find any inheritance blocking, any special delegation, or any other reason why they could not reset particular user’s passwords.  Then we found one of those commonly forgotten items in Active Directory.  Here comes the crash course on adminSDHolder in Active Directory.

AdminSDHolder is a container object under the system OU in AD.  This container object has an ACL on it that is copied to protected group members every 60 minutes.  Protected groups are:

  • Administrators
  • Account Operators
  • Server Operators
  • Print Operators
  • Backup Operators
  • Domain Administrators
  • Schema Administrators
  • Enterprise Administrators
  • Cert Publishers
  • So, every 60 minutes, the ACL from adminSDHolder OU is copied to any user account that is a direct or transitive member of any of these groups.  In addition to the ACls being copied, permissions inheritance is deselected from the account.

    This concept is designed by Micro$oft to enhance security on important accounts.  You wouldn’t want any helpdesk user with account operator rights to be able to reset the password on your enterprise admin account and then be able to use it for any reason they feel necessary (wish we didn’t give them a 2 week notice!)

    What we did to fit our needs was create a “Helpdesk Leads” group that only Domain Admins have rights to.  Then, we gave “reset password” rights to the adminSDHolder object for this group.  That may sound simple, but there is a catch.  Since adminSDHolder object is technically a container object, the “reset password” right cannot be assigned through a GUI.  The DSACLS command must be used (available in support tools).  here is the syntax:

    dsacls cn=adminsdholder,cn=system,dc=yourdomain,dc=com /G “Helpdesk Leads:CA;Reset Password”

    After 60 minutes, our Helpdesk Leads users were able to reset passwords for protected accounts.