J. Gregs Brain Corral

Today I am attempting to get SharePoint 2010 to work with accounts stored in an Active Directory forest that is external to the SharePoint server.  This would be our “guest forest”.  Lots of tips are available in the net:

• http://www.marc-lognoul.me/itblog-en/post/2009/05/13/SharePoint-People-Picker-and-Active-Directory-Part-1.aspx
• http://martijnschouten.wordpress.com/2010/06/02/sharepoint-2010-domain-trusts-people-picker/
• http://www.quantumofgeek.com/2010/09/configure-sharepoint-to-authenticate-cross-forest-ad-users/
• And a bit more authoritatively:
  http://technet.microsoft.com/en-us/library/cc263460(office.12).aspx

It is worth noting that the need to provide a username and password for search domain outside of the SharePoint web server’s domain is based on the type of trust that is present between the SharePoint server domain and the searched domain.  If the searched domain trusts the SharePoint domain (and selective authentication is not being enforced), no account credentials needs to be provided.

I used ”forest:guest.uvm.edu” as the external forest to search.  Now the people picker returns results from the external forest.  Good!  Unfortunately, when you go to apply permissions to the external user in a SharePoint site, I get a “No exact match was found. Click the item(s) that did not resolve for more options” error.  What gives?

The following thread seems to touch on this issue, but the resolution is a bit vague:
http://social.msdn.microsoft.com/Forums/en/sharepoint2010general/thread/edfc0ade-e994-44a3-a2e8-335abd9694ff

However, the “Full Metal Architect” page (first link in the bulleted list above) does suggest that using a “forest” search could return more limited search results, because it only queries the global catalog for user properties.  Just for grins, I converted the search scope to “domain:guest.uvm.edu”, did another IIS reset, and now I can add users.  Strange.

Ultimately, to ensure that both local domain and guest domain accounts could be searched and added using the people picker, I had to run the following commands:

stsadm -o setproperty -url [sharepointUrl] -pn peoplepicker-searchadforests -pv "domain:campus.ad.uvm.edu;domain:guest.uvm.edu"

-and-

stsadm -o setproperty -pn peoplepicker-searchadforests -pv "domain:campus.ad.uvm.edu;domain:guest.uvm.edu"

(note the abasence of the “-url” parameter in the second command)

I expect one of these commands really was not necessary, but now that things are working the way I want them to, I am going to leave well enough alone.

In addition to playing Portal 2 (good work, Valve guys!), I have been doing that some of thing called “work”. Today I decided to get back to the question of whether it is possible to enable and disable the Windows file server feature known as “Access Based Enumeration” (or “ABE”) from the command line.

Documentation suggests “yes”, that this is possible, using a tool known as “abecmd.exe”. Unfortunately, I can find no evidence that such a tool exists on Server 2008 R2. Curious… under Server 2003 R2 you needed to use the command line to enable ABE. Now under 2008 R2, you cannot (easily) use anything other than the GUI. Also interestingly, the only GUI that supports enabling ABE is the “Share and Storage Management” MMC that is included with “Server Manager” (the old “Shared Folders” MMC does not have this feature, and neither does the “Sharing” tab in Windows Explorer). It gets even better… if you create a share from the command line using “net share”, ABE is not enabled on the share. WTF? I thought Microsoft was supposed to be reducing the number of features that require the GUI, not ramping them up.

Of course, the ABE flag can be set using the NetShareSetInfo function of the netapi32.dll. However, using these older dlls in PowerShell is a touch more complicated than I care to deal with on a daliy basis. Have gander at this code:
http://poshcode.org/1635
Yuck! (No insult to the code intended… I just mean that I should not have to deal with this to perform basic share admin tasks!)

Fortunately, Bill Steward over at Windows IP Pro has taken mercy on us:
http://www.windowsitpro.com/article/scripting/managing-abe-from-the-command-line
Here he provides a small executable called “ShareABE.exe”, with source code, that will show and set ABE status on a server share.

Thanks, Bill!

I sure hope that Window Server “8″ includes a new .NET assembly for file and print server management. These old APIs are a real pain in the keister.

In our final entry in the Windows File Server management with PowerShell series, we have a quick look at managing shares using powershell.

The one feature of the NetApp that I will miss most was the automatic home share. Similar to Samba, you can tell the filer a set of directories under which user home directories are located. The filer will create these shares on-demand for a connecting user. Even under Server 2008 R2, Windows has no such capability. So what is the solution? Well, we have to create a share for every user. Augh! Fortunaltely, a beefy box can handle all these shares fairly gracefully, and with PowerShell, creating the shares is fast.

Some logic we added to this script includes probing for existing shares using “net share” before we attempt to create the share. If output of “net share” shows that the physical directory path is not correct, we delete the existing share and re-create it. If the share exists, and has the correct path, we don’t touch it. If the share does not exist, we create it.

I learned a fair bit about invoking external commands with PowerShell while writing this script. To summarize, PowerShell is not much like cmd.exe. When invoking a command with multiple parameters, you very often need to separate the parameters into array components, otherwise PowerShell does not know where to delimit the parameters. For example, let’s say we want to run the command:

net share jsmith=h:\homes1\j\jsmith /GRANT:DOMAIN\jsmith,FULL

The username and path are to be populated using variables in the script, so we try:

& net share ($uname)=($path) /GRANT:DOMAIN\($uname),FULL

Looks good, right? Unfortunately, not. The PS invocation command (“&”) parses the command parameters incorrectly, and thus passes a bunch of trash to the “net.exe” external command, and thus puts nasty red errors all over your console.

What we need to do is put the command parameters into an array, and feed that to the PS invocation command:

[string] $cmd = 'net.exe'
[string[]] $params = 'share', ($uname + '=' + $path),`
     ('/GRANT:DOMAIN\' + $uname + ',FULL')
& $cmd $params

Or perhaps more readably:

[string] $cmd = 'net.exe'
[array] $params = @()
[string] $params += 'share'
[string] $params += $uname + '=' + $path
[string] $params += '/GRANT:DOMAIN\' + $uname + ',FULL'
& $cmd $params

I do something similar below, showing once again that there is more than one way to code a cat (and that some cats are better looking than others):

# Shares all directories at the third directory level of the 
#	volumes specified in $homeVols.
# Assumes that all subdirectories will have a name matching an 
#	existing CAMPUS user ID.

Set-PSDebug -Strict

[string[]] $homeVols = @()
$homeVols = "h:\","i:\","j:\","k:\","l:\","m:\","n:\"

foreach ($vol in $homeVols) {
    $subDirs1 = gci $vol | ? {$_.Attributes.tostring() -match "Directory"}
    foreach ($dir1 in $subDirs1) {
        $subDirs2 = gci $dir1.FullName | ? {$_.Attributes.tostring() `
			-match "Directory"}
        foreach ($dir2 in $subDirs2) {
            $uhomes = gci $dir2.FullName | ? {$_.Attributes.tostring() `
				-match "Directory"}
            if ($uhomes.count -ge 1) { foreach ($uhome in $uhomes) {
				[bool]$doShare = $false
                [string] $cmd = "net.exe"
                [string] $arg1 = "share"
				[string] $arg2 = ($uhome.name)
				[string] $out = & net $arg1, $arg2 2>&1
				[string] $homePath = $vol + $dir1.name + "\" + $dir2.name + "\" `
					+ $uhome.name				
				[string] $homePathRX = $vol + "\" + $dir1.name + "\\" `
					+ $dir2.name + "\\" + $uhome.name
				if ($out -match "does not exist") {
					write-output "Share does not exist for $homePath"
					[bool] $doShare = $true
				} elseif ($out -notmatch $homePathRX) {
					write-output "Share not defined correctly for path $homePath"
					[bool] $doShare = $true
					#Delete existing share
					[string] $arg3 = "/DELETE"
					[string] $out = & net $arg1, $arg2, $arg3 2>&1
				}
				
				if ($doShare) {
	                [string] $arg2 = ($uhome.name + "=" + $homePath)
	                [string] $arg3 = "/Grant:CAMPUS\" + $uhome.name + ",FULL"
	                #write-host "about to share: " $uhome.name
	                # The next line will call the "net" command to share the 
					#	current home directory.
	                # If no mapping can be made between the directory name and 
					#	an AD user, "No Mapping" will be in the error output.
					
	                [string] $out = & net $arg1, $arg2, $arg3 2>&1   
	                if ($out -match "No Mapping") {
						Write-Output `
							"User was not defined for share on path $homePath"
	                   $uhome.name | out-file -FilePath h:\noMapUsers.txt -append 
	                } else {
						Write-Output "Successfully shared $homePath"
					}
				}
            }} #End if ($uhomes.count -ge 1)
        } #End $dir2 in $subDirs2
    } #End $dir1 in $subDirs1
} #End $vol in $homeVols

In our old NetApp environment we utilized quotas extensively. We want to map our NetApp quotas to Windows File System Resource Manager quotas in a failrly seamless fashion. Fortunately, with PowerShell, this is almost easy. Microsoft gives us the FSRM.FsrmQuotaManager and FSRM.FsrmQuotaTemplateManager “COM” object classes, documented here:
http://msdn.microsoft.com/en-us/library/bb613257(VS.85).aspx
http://msdn.microsoft.com/en-us/library/bb613280(v=VS.85).aspx
PowerShell works with these with ease.

I got a jump start on these scripts from my brethren on the Internet. Perhaps the most helpful post was Ben Lye’s entry on “Simple-talk”:
http://www.simple-talk.com/sysadmin/exchange/implementing-windows-server-2008-file-system-quotas/

First task… create FSRM quota templates that are similar to our NetApp qtree quotas. We don’t need to use “templates”, but it makes management a bit easier, so we will:

#Creates simple hard-limit directory quotas of the GB values specified in $tholds.

Set-PSDebug -Strict
$qtm = New-Object -com Fsrm.FsrmQuotaTemplateManager

[int[]] $tholds = 25,50,100,150,200,300,400,600,800,1200

foreach ($thold in $tholds) {
	$templ = $qtm.CreateTemplate()
	[string] $tName = [string]$($thold) + " Gb Shared Directory"
	$templ.Name = $tName
	[long] $tLimit = $thold * 1073741824
	$templ.QuotaLimit = $tLimit
	$templ.Commit()
	Clear-Variable templ
	Remove-Variable templ
}

Now we want to map our NetApp quotas to the new FSRM quotas. Challenges here are:

1. extracting structured data from the NetApp “quotas” file.
2. mapping NetApp quotas to the nearest-larger FSRM quota template.

The first challenge is handled using the .NET RegEx and String classes. It was a hack job, but it worked.

The second challege was handled using the powershell “switch” command. The one roadblock I ran into here was caused by a failure to cast a variable as the appropriate data type. For those who did not already know, you never, uh, I mean always should cast your valiables. Why? Look at the switch in the code below… what do you think happens when you compare the un-cast pipeline variable ($_) to “100″? Did you answer “geez dude, I don’t know, that’s a gibberish.”? Join the club. Did you answer “PowerShell does a string comparison, dude! $outQuota was an array of strings! What the heck were you thinking? Do you want 1000 to be considered a larger value than 25?”? If so, then you are correct. If you want to do mathematical comparison, you must cast your valiables an numbers. And by the way, do not cast large numbers as “[int]“. Why? Because [int] will not exceed 32-bits in length. Use [long] or [double] instead.

# Applies quota templates to s:\shared subdirectories, mapped from input file
# specified in $inQuota (the NetApp quotas file)
# NetApp quota limits are matched to the closest larger Windows quota template.

Set-PSDebug -Strict

#parse NetApp quota file:
$inQuota = Get-Content '\\files\etc$\quotas'
$outQuota = @()
#following loop strips all but the shared directory name and hard limit from input:
foreach ($line in $inQuota) {
	$arrLine = @()
	if ($line -match "/vol/vol2/") {
	[string] $ind0 = [regex]::split($line," tree ") | Select-Object -Index 0 |`
		% {$_.trim()} | % {$_.replace("/vol/vol2/", "")} | % {$_.replace('"', '')} 
	[string] $ind1 = [regex]::split($line," tree ") | Select-Object -Index 1 |`
		% {$_.split("G")} | select-object -index 0 | % {$_.trim()}
	$outQuota += ,@($ind0,$ind1)
	}
}
Remove-Variable inQuota

#instantiate quota manager:
$qm = New-Object -com Fsrm.FsrmQuotaManager

foreach ($quota in $outQuota) {
	#determine Windows Quota Template that is closest to NetApp quota:
	[long] $qVal = $quota[1]
	switch ($qVal) {
		{$_ -le 1200} {[string]$qtl = "1200"}
		{$_ -le 800} {[string]$qtl = "800"}
		{$_ -le 600} {[string]$qtl = "600"}
		{$_ -le 400} {[string]$qtl = "400"}
		{$_ -le 300} {[string]$qtl = "300"}
		{$_ -le 200} {[string]$qtl = "200"}
		{$_ -le 150} {[string]$qtl = "150"}
		{$_ -le 100} {[string]$qtl = "100"}
		{$_ -le 50} {[string]$qtl = "50"}
		{$_ -le 25} {[string]$qtl = "auto"}
	}
	# values 25 or smaller use an autoapply template, so skip these...
	if ($qtl -notmatch "auto") { 
		# create a quota object by retrieving an existing auto-apply quota, then update:
		[string] $deptDir = 's:\shared\' + $quota[0]
		$qObj = $qm.GetQuota($deptDir)
		[string] $templ = $qtl + " Gb Shared Directory"
		$qObj.ApplyTemplate($templ)
		$qObj.Commit()
		Clear-Variable qObj
		Remove-Variable qObj
	}
}

Now moving on to user home directory quotas… we used “AutoApplyTemplates” for this situation. AutoApply templates force afixed quota onto all new subdirectories of a parent. In this way, we avoid having to set a template manually for every new user home directory. Our file server contains six volumes (h:-m:), each containing a “homes1″ subdirectory, each of which in turn contins subdirectories 0-9, a-z. Individual home directories are nested within these. We needed to apply AutoApplyTemplates to these 0-9,a-z directories. Easy…

# Applies an Auto-Apply quota to all directories at the second directory level 
# of the volumes specified in $homeVols.

Set-PSDebug -Strict

[string[]] $homeVols = @()
$homeVols = "h:\","i:\","j:\","k:\","l:\","m:\"

$qm = New-Object -com Fsrm.FsrmQuotaManager

foreach ($vol in $homeVols) {
    $subDirs1 = gci $vol | ? {$_.Attributes.tostring() -match "Directory"}
    foreach ($dir1 in $subDirs1) {
        [array] $subDirs2 = gci $dir1.FullName | ? {$_.Attributes.tostring() -match "Directory"}
        if ($subDirs2.count -ge 1) { foreach ($dir2 in $subDirs2) {
            [string] $uPath = ($vol + $dir1.name + '\' + $dir2.name)
			[string] $template = "10 Gb Home Directory"
            $quota = $qm.CreateAutoApplyQuota($template,$uPath)
            $quota.Commit()
            clear-variable quota
            remove-variable quota
        }} #End if ($subDirs2.count -ge 1)
    } #End $dir1 in $subDirs1
} #End $vol in $homeVols

On the NetApp, we had a single volume that hosted users with a larger home directory quota. Under Windows, we can simply set a different directory quota for these individuals which overrides the AutoApplyTemplate. I have done this for the existing 25Gb quota users already, using PowerShell:

# Applies a new quota to the third-level directory of the volumes specified in $homeVols, 
#  under the path $homeVol:\homes2\[a-z]\[samAccountName]

Set-PSDebug -Strict

[string[]] $homeVols = @()
$homeVols = "n:\","m:\"

$qm = New-Object -com Fsrm.FsrmQuotaManager
$qtm = New-Object -com Fsrm.FsrmQuotaTemplateManager

foreach ($vol in $homeVols) {
    [string] $dir1 = $vol + "homes1"
    $subDirs2 = gci $dir1 | ? {$_.Attributes.tostring() -match "Directory"}
    foreach ($dir2 in $subDirs2) {
        [array] $uhomes = gci $dir2.FullName | ? {$_.Attributes.tostring() -match "Directory"}
        if ($uhomes.count -ge 1) { foreach ($uhome in $uhomes) {
            [string] $uHomePath = ($dir1 + '\' + $dir2.name + '\' + $uhome.name)
            $quota = $qm.GetQuota($uHomePath)
            $quota.ApplyTemplate("25 Gb Home Directory")
            $quota.Commit()
            clear-variable quota
            remove-variable quota
        }} #End if ($uhomes.count -ge 1)
    } #End $dir2 in $subDirs2

} #End $vol in $homeVols

And that is all I have for quotas for now. We will need to enhance our templates with threshold alerts and notifications in the future. This could prove interesting as the IFsrmObject.IFsrmQuotaBase class looks a bit challenging to deal with:
http://msdn.microsoft.com/en-us/library/bb613248(v=VS.85).aspx