Apr 142014

It’s important to provide end users with a stable environment to host ‘user specific’ information. It is not uncommon for IT staff to receive calls from end users reporting they can not access information within their home drives or redirected folders.  Then IT staff find that they cannot access those files either. As a guideline and in an effort to hopefully stop existing IT staff from manually creating user folders; it is suggested that the parent folder NTFS permissions and share permissions be set as follows.

NTFS Perms for Home Drive and FDir

NTFS Permissions for Home Drive or Folder Redirection

Share Perms for Home Drive or FDir

Share Permissions for Home Drive or Folder Redirection

The FILEServer\Administrators group can be replaced with your group that is responsible for managing user data. Additionally, Authenticated users in the NTFS permissions can be replaced with the group of users you want to have Home Drives or Redirected folders on this file server.

It is a good practice to add Authenticated Users or Everyone with Full Control to the Share Permission, then limit access to files and folders with NTFS permissions.  This reduces the complexity when trying evaluate effective permissions when troubleshooting.

These permissions, when applied to the users folders not only give users full control of their files, but also gives administrators access to those files as well. As an extra bonus IT staff does not have to manually create the user folder; the users folders are created by the system.

How to fix it

Now we know what the parent permissions should be, how do you correct your current user folders? If you have gotten to a place where you cannot access users files and folders, you cannot simple check “Replace all child object permission entries with inheritable permission entries from this object”.  Note: if you don’t have access to the folder, you will not be able to change the permission for that folder, subfolders and files.

First you must take ownership of the files and folders, update the permissions and then return the ownership back to the user.  We do this by using two commands; subinacl.exe and icacls.exe.  SubInACL is a part of Windows Server 2003 Resource Kit, but it works well in Server 2008 and Server 2012.

The first two lines change the owner of the files and folders to the Administrators group. SubInACL has a quirk where when you use /subdirectories, the parent folder is not affected. The first command then is changing the parent user folder. Don’t forget the trailing back-slash at the end of the path for /subdirectories, otherwise only that folder is processed.

icacls /reset replaces ACLs with the inherited ACLs.

The next two lines changes the owner back to the user. The final icacls /reset ensures the ACE for the user is in the ACL.

All there is left to do is repeat this process for each user folder. I wrapped these command lines in a PowerShell script, then ran the script for a few users each weekend until all of the folders were corrected.

69 total views, no views today

Apr 142014

PowerShell alone offers a plethora of options for Citrix administrators to automate common and complex administrative tasks. Time is valuable, performing common administrative tasks such as managing published applications with PowerShell will inevitably free up more time in the long run. The following provides a quick breakout on how to use PowerShell and the XenDesktop SDK Modules and common published application tasks.

First, we need to make sure the necessary PowerShell Modules are loaded appropriately.

  • Remote into one of the Desktop Broker Servers and launch PowerShell with administrative rights.
  • Assure script execution is set appropriately: Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force
  • Next, load up the Citrix PowerShell modules with the following command: asnp citrix*

Next, lets leverage the XenDesktop SDK Modules and display information relative to how applications are published from within your XenDesktop 7.5 infrastructure.

  1. get-BrokerApplication –> retrive a list of applications that have been published.
  2. get-brokerapplication -enabled $true –> retrieve a list of applications that are enabled
  3. get-brokerapplication -enabled $false –> retrieve a list of applications that have been disabled
  4. rename-BrokerApplication –Name <existingAppName> -NewName <newAppName> –> rename a published application.
  5. remove-BrokerApplication –Name <existingAppName> -DesktopGroup <nameOfDesktopGroup> -AdminAddress <nameOfBrokerAddress> –> remove a published application.
  6. get-brokerapplication | select name,applicationtype,associateddesktopgroupuids,visible | format-list –> will enumerate a common set of application specific information an administrator would want to audit. a the following will be displayed back to the console; Application Name, Application Type, how many groups/users are associated with the application, and whether or not the application is visible.
  7. get-brokerapplication | select name,commandlineexecutable,commandlinearguments,enabled | export-csv c:\temp\applictionAudit.csv –> will yield a quick listing of published applications, along with some of the important publishing specific parameters and export the results to a csv file for later review.

The above should be a good starting point for application management tasks. Randomly auditing the infrastructure and archiving published application lists will allow for administrators to quickly assess configuration drift and changes. 

74 total views, no views today

Apr 022014


The Active Directory Replication Monitor Utility (ADREPL) provides the following administrative feature sets and capabilities delivered through both command-line and an attractive graphical interface. ADRepl.exe is available to the public at no cost, and hosts the following capabilities for administrators:

  • Quickly monitor and verify Replication status, current & highest USN.
  • Graphical display of metadata on objects.
  • View the history of successful and failed replication changes for troubleshooting purposes.
  • Generate status reports that include direct and transitive replication partners, and detail a record of changes.
  • Find all direct and transitive replication partners on the network.
  • Display replication topology.
  • Poll replication partners and generate individual histories of successful and failed replication events.
  • Force replication with a
  • Trigger the Knowledge Consistency Checker (KCC) to recalculate the replication topology.
  • Display changes that have not yet replicated from a given replication partner.
  • Display a list of the trust relationships maintained by the domain controller being monitored.
  • Quickly display the metadata of an Active Directory object’s attributes.
  • Monitor  the replication status of domain controllers from multiple forests.
  • Assess when a replication partner fails, and why.
  • Intuitive Command-Line interface

Monitor Active Directory Replication


  • CB5 Solutions will provide support and bug fixes for the product to maintain customer confidence
  • CB5 Solutions will also provide blogs and step-by-step guides for AD Replication Monitor.


  • You can download the latest version of ADReplSetup.exe here

635 total views, no views today

 Posted by at 5:39 pm
Dec 082013

Hello all, Eric here again. Just recently I was at a customer site in Japan for a few weeks and they had a number of interesting issues, so while I have some time here in the Naha airport, I thought I’d write about a couple of them.

One issue that we encountered across a number of their domains was that we couldn’t create zones in the DomainDNSZones partition (“All DNS servers in this domain” option). It wasn’t due to permissions; unfortunately I didn’t write down the exact error syntax that was returned, but I’m pretty sure it said “unable to create zone” – “server unavailable” or “server failure”. During further investigation, when trying to manually connect to the DomainDNSZones for that particular domain using ADSIEdit, it would fail no matter which DC in that domain that you tried to connect to and give the following error: “A referral was returned from this server”. The key word here is “referral”. Anyhow, the next thing I looked at was to see if there were even any DC’s enlisted into the partition. You can do that by running DNSCMD /enumdirectorypartitions, or by checking the msDS-NC-Replica-Locations attribute of the CrossRef object (CN=Partitions,CN=Configuration,DC=Domain,DC=Com) for the DomainDNSZones partition. Continue reading »

1,321 total views, 4 views today

Dec 082013

While on the topic if DNS, one of the DC’s that had the corrupt application partition (discussed in my last blog entry) also had another interesting issue that’s not all that common, at least in my experience. One DC in one of the child domains, was missing a few AD integrated DNS zones that were stored in the ForestDNSZones application partition, however it had other zones loaded that were stored in the same partition. To clarify what I mean when I say missing, I mean missing from the DNS console.

Normally if you aren’t able to “pull” the default application partitions, a lot of time’s its because it’s a newly promoted DC in a child domain that doesn’t have connectivity to the Domain Naming Master FSMO role holder; so the application partitions can’t be created. In this case however, not only did it already have other zones loaded that were in the ForestDNSZones partitions, it actually also had the zones that were missing from the DNS console already on the DC, they just weren’t loaded. I say “loaded” vs. “showing up in the DNS console” because I’ve seen it where zones are in fact loaded and resolving, they just don’t show up in the DNS console. Continue reading »

1,753 total views, 2 views today