Glo Networks Technical Blog (Glo Blog)

For those of us Exchange admins who aren’t fully up to date with Exchange 2010 service packs (for whatever reason – don’t berate us) and have slowly been getting annoyed with an ever increasing amount of mailboxes that get automapped in Outlook 2007 and 2010 can rejoice. One of our staff spent 10 minutes reearching, understanding and writing a bit of Powershell to resolve the issue en-bulk.

Just run the following under a Powershell instance with the Exchange modules loaded (i.e. the Exchange Management Shell).

foreach ($u in $(Get-User)) { Write-Host "Clearing the msExchDelegateListLink for $($u.distinguishedname)"; $ad = [adsi]"LDAP://$($u.originatingserver)/$($u.distinguishedname)"; $ad.msExchDelegateListLink.Clear(); $ad.SetInfo(); }

Be aware that if you do this, all auto mappings for all users will get removed. This may not have the desired behaviour as some users may be relying on an automapped account. It should be feasible to alter this as required, as it’s pretty damn simple!

As with all things, do this at your own risk, we accept no liability, yadda yadda yadda.

If you’re curious (and lets face it, if you’re modifying the Active Directory en bulk, you should be!), basically what this does is loop over all users, and clear all values against their Active Directory account msExchDelegateListLink attribute. This attribute is where the automapping gets written to.

As an example imagine 2 users, Bob and Alice. Bob is an Exchange admin and at some point was granted full access (with permission, naturally) to diagnose a problem with Alice’s mailbox without having to disturb her too much directly. Bob will now be added to Alice’s msExchDelegateListLink attribute. It’s this entry that needs to be removed.

Apparently in SP2 there is the facility to disable automapping, at the time of adding the relevant permission; the shiny new “-AutoMapping” argument to Add-MailboxPermission. As with many things Exchange 2007 and newer, it’s just a facility available at the Powershell console, for now. And you know what? We’re ok with that.

Posted by Karl in Applications, Cool Stuff, Scripting, Servers | No Comments »

For many of our customers we redirect a user’s My Documents to a directory of the same name, on a Windows share. For example, the user ‘JMcMuffin’ may have their My Docs redirected to “\\FILESERVER\Home\JMcMuffin\My Documents”, which are stored in a local path of D:\Data\Users\JMcMuffin, on FILESERVER. Obviously you can switch \\FILESERVER\Home for a DFS share, etc.

In some instances you might have a significant number and for whatever reason the permissions may have been altered, and the Group Policy defaults don’t quite suit your requirements. Or maybe you’re transfering these files to a new server, in a different domain. I can’t image you want to do the whole thing by hand.

In days of old we’d sort this with a batch script and it would be ok, but might take a while to run. Powershell has changed things though. The script we’ve popped together (below) runs lightning quick in comparison, and we thought someone else might also find it useful.

Just save it in a ps1 file, and invoke it from powershell, providing your directory path that you want to “fix”.

To use our example from above, you’d call the script on FILESERVER, from powershell:

PS C:\Users\Karl> C:\path\to\scripts\fix-perms.ps1 “D:\Data\Users”

The script would then go over each directory and try and add that user to the ACL with Modify rights – i.e. the JcMcMuffin user to the D:\Data\Users\JMcMuffin directory.

In our scenario we required ourselves, another group, SYSTEM and each user to have access only – So we pushed the common permissions from the parent, and then ran the script to add the individual users.

# Fix-Perms
# Iterates over all child directories, and adds the user, with the same name as the directory, to the ACL with modify rights
# Usage:
# Fix-Perms “C:\Path\To\Directory”
# Or, for the current directory
# Fix-Perms “.”

# our parameters, throw a warning if we get none
param (
[string] $dirpath = $(throw “Please specify the full path to the directory!”)
)

# get list of all child directories, in the current directory
$directories = dir $dirpath | where {$_.PsIsContainer}

# iterate over the directories
foreach ($dir in $directories)
{
# echo out what the full directory is that we’re working on now
write-host Working on $dir.fullname using $dir.name

# setup the inheritance and propagation as we want it
$inheritance = [system.security.accesscontrol.InheritanceFlags]“ContainerInherit, ObjectInherit”
$propagation = [system.security.accesscontrol.PropagationFlags]“None”

# get the existing ACLs for the directory
$acl = get-acl $dir.fullname

# add our user (with the same name as the directory) to have modify perms
$aclrule = new-object System.Security.AccessControl.FileSystemAccessRule($dir.name, “Modify”, $inheritance, $propagation, “Allow”)

# check if given user is Valid, this will barf if not
$sid = $aclrule.IdentityReference.Translate([System.Security.Principal.securityidentifier])

# add the ACL to the ACL rules
$acl.AddAccessRule($aclrule)

# set the acls
set-acl -aclobject $acl -path $dir.fullname
}

Posted by Karl in Applications, Desktops and Laptops, General, Operating Systems, Servers, Software | 3 Comments »