Managing Macintosh OS X with AD Schema Extensions

May 3rd, 12 / 0 Comments

I got stupid again this week and decided to investigate management of Mac computers.  Since we are both cheap and overworked, I wanted a solution that would be both free, and would not require any new infrastructure.  The only options that came to mind were either to extend our OpenLDAP server to support apple schema, or to extend Active Directory.  Since I am the “Windows Guy”, and since use of AD also brings benefits such as Kerberized login to file servers, support for NTLM auth, and support for File Sync, I went with the AD option.

Not fun, very messy, but it works.  Here are the gotchas:

  1. Use the Lion Active Directory integration guide or later.  Earlier guides might lead you to create a schema extension file that will, in turn, create invalid classes in your AD schema.  The new guide works well.
  2. If your computer was bound to AD before the schema update, you likely will need to unbind/rebind before you will be able to take advantage of MCX settings in AD.  The reason is that your apple hardware uuid and macAddress are not populated as part of your AD computer object until after the schema extension is done.  Apple says you only need to restart the OpenDirectory daemon (“killall opendirectoryd” as root) to get the attributes populated, but I do not think this is accurate.
  3. If your domain/forest is at the 2008 or 2008 R2 level, you will need to run “dsconfigad -alldomains disable” after domain bind, or you will not be able to find apple computer-list objects in the domain.  After running this command, you have to specify the AD domains to search using Directory Utility, or by running the following commands as root:
    dscl lolcalhost -delete /Search CSPSearchPath “/Active Directory/CAMPUS/All Domains”
    dscl localhost -append /Search CSPSearchPath “/Active Directory/CAMPUS/campus.ad.uvm.edu”
  4. The Lion+ AD plugin will look in computer objects in only one place in your domain… “CN=Mac OS X”.  If you want to manage macs using computer lists you must create a “container” object (not an Org Unit) with this name in the root of your domain, and create your apple-computer-list objects there.   You will need to use ADSI Edit to create the container and apple-computer-list objects, as ADUC does not allow for creation of these object types.

There is a lot more to learn here.  One thing I am curious about is how we might be able to safely delegate Mac computer management, given that someone with control over a user group or computer group can add any user or computer to that group, and thus can impose settings on users and computers arbitrarily.  One option might be to disable or constrain access to the apple extensions to the user and group objects, so that only select and highly trusted individuals can control user MCX settings.  For computer-list objects, we might not be able to delegate management of the members attribute of the computer list object, but instead only delegate management of the MCX settings.  Messy.

I also am curious to know how MCX settings are applied when multiple MCX settings are used on users, groups, computers, and computer-lists.  Which policy takes priority?  How is merging accomplished?

Ultimately, it is nice to know that Apple has provided a functional solution for Mac management in an AD domain.  It may not be perfect, but it is a start.  Perhaps when combined with “Munki”, or another Apple Software Update clone, we will really have something solid for Enterprise Management of the Mac.

Monitoring and Management

The Mysterious Case of the Un-Deletable MBR (Or, More Reasons to Hate PGP)

Apr 6th, 12 / 0 Comments

Shortly after releasing MDT 2012 on the general public I got a call from a colleague who told me that his LiteTouch deployment was failing.  He was able to boot to LiteTouch media, go though the configuration wizard, and initiate setup.  LiteTouch would partition the drive, Windows Setup would start, the image would get written to the computer, and then the system would reboot… so far so good. What happened next was unexpected.  The computer booted to the PGP BootGuard screen.

Turns out we were dealing with a system that had been encrypted using PGP Whole Disk Encryption. However, we have a lot of those, and deployment has not failed on them before.  In the past, LiteTouch dutifully has erased the Master Boot Record (MBR) and all existing partition tables on the system, effectively wiping PGP BootGuard from the machine before running Windows Setup.

So what changed?  Is this a bug in MDT 2012?  Something new in PGP Desktop version 10.2.0 MP4?  Or a configuration problem in our LiteTouch environment.

Let’s omit the details of ~6 hours of troubleshooting… it was a change in the WinPE LiteTouch environment, and PGP.  It appears, though investigation, that the PGP filter drivers attempt to block access to the MBR of the hard drive.  Since I had injected PGP drivers into the LiteTouch 32-bit boot media, I had, effectively created a situation where DiskPart.exe would be unable to remove PGP BootGuard from the system.  The really irritating part is that the PGP drivers do not pass any indication to the Windows utilities that there has been an error writing to the MBR.  DiskPart.exe, BootSect.exe, and the DaRT Disk Commander all can be used to repair MBRs.  But when used in a PGP-enabled environment they all report success in manipulating the disk MBR, but all of them fail to make any real change to the true MBR.  How do you usually erase a drive?  For me, I would run “diskpart.exe, select disk 0, clean”.  With PGP drivers in place, you could run this series of commands, think that you had erased the drive, but still end up with PGP BootGuard in your MBR.  It really is maddening.

Symantec/PGP claim that you can remove the MBR data by “deinstrumenting” the disk using the “pgpwde.exe” command.  The problem with this is, pgpwde will not let you deinstrument an encrypted drive.  So, you would have to decrypt the drive first, then deinstrument.  I am not wasting time on that.  Worse yet, if your drive was partially encrypted when you erased the data partition, PGPWDE still reports the drive status as “partially encrypted”, and refuses to perform any actions on the drive (such as “deinstrument”) until the current encryption (on the nonexistent drive) completes.  AARGH!

Fortunately, I was able to find a low-level disk manipulation utility that actually works in 32-bit PGP-enabled WinPE environments.  PlDD.exe:

http://home.comcast.net/~plavarre/plscsi/tools/pldd/

There are other “DD” equivalents for Windows.  Most of them either fail to work against PGP (GnuWin32 DD.exe and the Crysocome DD), or will not function under WinPE (FAU DD).  PlDD is pretty old, and it does not work under 64-bit Windows.  But, we don’t need 64-bit support (PGP does not provide 64-bit drivers for WinPE!), it works perfectly in 32-bit Windows.  Thus, this is the perfect tool for the time being.

Getting the right command syntax to pldd.exe was a bit challenging as the tool itself has scarce documentation.  I wish I could credit all of the resources that I used to put this dense command together, but I have since lost the browser tabs.  The following is the pldd.exe command, suitable for plugging into an MDT task sequence as a custom command:

cmd.exe /c “%SCRIPTROOT%\Pldd.exe if of=\\.\PhysicalDrive0 bs=512 count=1″

Argument breakdown:

  • if = In File.  In this version of DD, if provided with parameters, will use a string of zeros as input.
  • of = Out file.  In this case, we are using the Windows device path “\\.\PhysicalDrive0″, which is fixed disk zero.  I think this device path is referenced in the gnuwin32 dd docs.
  • bs = Block size.  We are choosing to write in 512 byte blocks.
  • count = The number of blocks to write.  We are going to write one 512 byte block to the “out file”.

To summarize, we use pldd to write 512 bytes of zeros to the start of physical drive zero.  This action wipes out the MBR and the disk signature of the drive (sorry, I lost my reference for this factoid, too).  Zeroing 512 bytes of disk is rather faster than zeroing the entire drive, which is the only other option I have seen referenced in the tubes for fixing this issue.

Share and Enjoy.

Scripting the Windows Experience, System Imaging and Deployment

MDT 2012 – Taking LiteTouch Offline

Apr 6th, 12 / 0 Comments

I decided to give some of my user base something that they have been asking for for a long time… the ability to run MDT/LiteTouch deployments entirely from removable storage media. I had avoided doing this in the past as we made significant use of the MDT database in selecting hardware-specific support applications (such as Dell QuickSet).  However, with MDT 2012 (and the general deprecation of hardware-specific support software under Windows 7), I have decided to abandon the MDT database.  This makes generation of offline MDT media much more feasible.

“I should be able to get this done in a few hours!”, I thought.  Ha!  Four days later…

Gotchas in adding LiteTouch Offline media to a previously online-only environment:

Expiring stale media:

One of the leading arguments we make to persuade users to adopt the use of LiteTouch is that “we keep it up to date for you”.  What about offline media?  How to we ensure that that stays current?  One of the Brad Tucker, Deployment Guy, has a solution for that:

http://blogs.technet.com/b/deploymentguys/archive/2012/02/15/expiring-outdated-stand-alone-media.aspx

The problem there is that his script was developed for the SCCM ZTI scenatio, not LiteTouch.  However, with a little work I was able to adapt his script for use in LiteTouch.  The script body is available below.  To run it, I needed to modify the “winpeshl.ini” file in %ProgramFiles%\Microsoft Deployment Toolkit\Templates as follows:

[LaunchApps]
%SYSTEMROOT%\System32\wscript.exe,X:\Deploy\Scripts\ZUVMExpiredMediaCheck.vbs
%SYSTEMROOT%\System32\bddrun.exe,/bootstrap

The script referenced above (ZUVMExpiredMediaCheck.vbs) needs to be defined in the “Extra Directory to Include” field in the WinPE section of the Media set in the Deployment Workbench.  You need to include the “\Deploy\Scripts” folder structure in the Extras directory, too.

WinRE installation problems:

Since deploying MDT 2012, I finally worked though the problem of including both WinRE and MS DaRT tools into the LiteTouch boot media, and in the WinRE environment installed with the operating system.  However, with offline media the inclusion we would not want to copy the LiteTouch WinPE instance to disk.  Two reasons.  Firstly, the OS Deployment option simply would not work (Offline media would not be available), and secondly, we just included a script to disable the media.  To solve this problem, I needed to set the “PrepareWinRE” Property in the CustomSettings.ini file for the media set to “NO”.

MS DaRT Integration Problem:

When testing LiteTouch from a fully offline machine, I started to get a “network connection not available” error pop up at seemingly random places after starting up the boot media.  Eventually I realized that the error was coming from the DaRT Remote Connection tool that starts up with WinPE.  While this error does not cause any problems with actual deployment, I don’t want it causing end-user panic, so I decided to see if I could disable the feature.  According to documentation, I need to generate a “DartConfig.DAT” file using the DaRT configuration tool.  DartConfig.DAT is a binary configuration file (not plain text).  It’s options are not documented anywhere, so you really do have to run the GUI tool to generate a new DAT.  You then are supposed to drop the DAT file into “%ProgramFiles%\Microsoft Deployment Toolkit\Templates”, and update your boot media.  A few problems with this:

  1. If you want different configuration files installed into your WinPE instances, you will either to switch out the DartConfig.dat in the Templates directory each time you update boot media, or run the updates from a different MDT instance, or edit the LiteTouch boot WIM files each time you update the boot media.  There is no way to specify different DartConfig.dat files per deployment share or media set.
  2. The Deployment Workbench does not consistently insert the DartConfig.dat file into the LiteTouch boot media.  If you update your DartConfig.dat in the Templates directory, then update your boot media, there is no guarantee that your DartConfig.dat will get updated.  The only sure-fire way to get a new DartConfig in your deployment share seems to be to force regeneration of the boot media (i.e. you need to throw out your existing boot WIM files, not update them).  The situation is worse with offline media sets.  Rather the workbench will copy any existing boot WIMs from the root deployment share to serve as a baseline image when generating offline boot images.  Thus, to update DartConfig.dat in a media set, you need to delete both the root share boot WIMs, and the offline boot WIMs prior to updating media.
  3. You might think that you could work around that whole one-template-per-workbench problem by including a per-media-set DartConfig.dat in the “Extras” folder that you can optionally include in each media set or deployment share.  After all, the media update procedure appears to add the extras after the templates.  But if you did think this, you would be wrong.  The update apparently will not overwrite existing files within the source WIM.
  4. You might, out of sheer desperation, decided to remove DaRT from the offline boot media  by deselecting the component from the WinPE properties of the media set.  This also will fail.  The workbench will report that “DaRT cannot be removed from the media.  Use the -Force option to regenerate the media.”  Presumably the error is suggesting that you should add “-force” to the Update-MDTMedia PowerShell Cmdlet that is used to update the media set.  Sadly, “-Force” is not a valid flag for this cmdlet.

Ultimately, I just used imagex to mount the LiteTouch Offline boot media, and switched out the DartConfig.dat file using a simple “copy” command.  Now I just need to remember to do that every time.

UserExit Script – Required Modifications:

Back in 2008 I added a UserExit script to LiteTouch to generate a semi-unique computer name by taking the last eight characters of the computer’s MAC address, then appending a hyphen and a date string.  It turns out that the routine in MDT that captures the MAC address (presumably ZTIGather.vbs) will not succeed unless the computer has a functional Ethernet connection.  Grrr… When testing LiteTouch offline, we were getting computer names like “Address%-1214″.  Percent characters are not valid in computer names  so, I needed to update our UserExit to use other semi-unique system attributes such as “Serial Number” to “Asset Tag” if the MAC is not available.  I also added a fallback string of “UVMLT” if none of those variables are found.  The new script is available below, along with a sample call to the script from CustomSettings.ini.

' // ****************************************************************************
' // File:      ZUVMExpiredMediaCheck.vbs
' // Version:   1.0
' // Purpose:   Check to see if stand-alone media is expired
' // Actions:   Shuts down WinPE if media is older than iExpAge variable months
' //            Otherwise, script exits with Return 0.
' // Usage:     cscript/wscript ZUVMExpiredMediaCheck.vbs
' //            (to be added to winpeshl.ini, before bddrun.exe)
' // ****************************************************************************
Option Explicit

' // Declare Variables:
Dim cFiles
Dim dtCreationDate, dtEndDate, dtXMonthsAgo
Dim iExpAge
Dim oDiskDrive, oDrives, oExec, oFile, oFSO, oShell, oWMIService
Dim sCommand, sComputer, sExpText, sSysRoot, sUSBPath

' // Initialize Variables:
' Media Expiration Age, in months:
iExpAge = 4

' // -----------------------------------------------------------------------------------------
' // Function: Converts the WMI date query response to a simple date format.  (e.g. 09/21/2010)
Function WMIDateStringToDate(dtmInstallDate)
	WMIDateStringToDate = CDate(Mid(dtmInstallDate, 5, 2) & "/" & Mid(dtmInstallDate, 7, 2) _
	& "/" & Left(dtmInstallDate, 4) & " " & Mid(dtmInstallDate, 9, 2) & ":" _
	& Mid(dtmInstallDate, 11, 2) & ":" & Mid(dtmInstallDate, 13, 2))
End Function
' // -----------------------------------------------------------------------------------------

' // ---------------------------------------------------------------------------------
' // Find the environment variable %SYSTEMROOT% for location of LiteTouch Executables.
Set oShell = CreateObject("WScript.Shell")
sSysRoot = oShell.ExpandEnvironmentStrings("%SYSTEMROOT%")
' // ---------------------------------------------------------------------------------

' // --------------------------------
' // Find driver letter for USB Media
Set oFSO = CreateObject("Scripting.FileSystemObject")
Set oDrives = oFSO.Drives
For Each oDiskDrive In oDrives
	If oDiskDrive.DriveType = "1" Then
		sUSBPath = oDiskDrive.Path
	End If
Next
' // --------------------------------

' // -------------------------------------------------------------------------
' // Media Check - Check for Applications.xml presence and age.
sComputer = "."
Set oWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & sComputer & "\root\cimv2")
' Query WMI for creation date of the Applications.xml file on the USB Drive:
'    NOTE: Do not add the wbemFlagForwardOnly (Decimal 32) flag to this query.  While the query would run faster
' with the flag, we also will not be able test for empty queries.
Set cFiles = oWMIService.ExecQuery("Select * From CIM_DataFile Where Name = '" & sUSBPath & "\\Deploy\\Control\\Applications.xml'")
' // -------------------------------------------------------------------------

' // ---------------------------------------------------------------------------------
' // If Applications.xml file is not present, this is not offline media.  Exit script.
if cFiles.Count = 0 then
	Wscript.Quit(0)
end if
' // ---------------------------------------------------------------------------------

' // ---------------------------------------------------------------------------------------------
' // If the Applications.xml file creation date is more than "iExpAge" months ago, shutdown WinPE.
For Each oFile in cFiles
	dtCreationDate = WMIDateStringToDate(oFile.CreationDate)
	dtEndDate = DateAdd("m", iExpAge, dtCreationDate)
	' Set the date iExpAge months ago from today
	dtXMonthsAgo = DateAdd("m", -iExpAge, Now)
	If dtCreationDate < dtXMonthsAgo then
		' Expiration Text, to be displayed to the user if older than iExpAge months:
		sExpText = "This LiteTouch Offline Media expired on: " & dtEndDate & chr(13) _
			& "Refresh your media using the README file located here:" & chr(13) _
			& "\\files.uvm.edu\software\Windows_Deployment_Services"
		MsgBox sExpText,vbMsgBoxSetForeground,"Expired Media"
		'Shutdown WinPE immediately:
		sCommand = sSysRoot & "\system32\wpeutil.exe shutdown"
		set oExec = oShell.Exec(sCommand)
	Else
		' If the media is fresh, run LiteTouch Offline.
		WScript.Quit(0)
	End If
Next
' // ---------------------------------------------------------------------------------------------

' // ZUVMUserExit.vbs
' // Custom Function library for use with the Microsoft Deployment Toolkit
' // Currently includes "GenUniComp" - a function for generating unique computer names

' code adapted from source content:
'   http://blogs.technet.com/benhunter/archive/2007/03/17/understanding-bdd-rule-processing.aspx

Function UserExit(sType, sWhen, sDetail, bSkip)
	UserExit = Successfs
End Function

Function GenSimDate(sSimDate)
	'Generates a simple date string in the format of YYMMDD
	Dim dNow, sYear, sMonth, sDay
	dNow = Date()
	sYear = Right(cStr(Year(dNow)), 2)
	sMonth = cStr(Month(dNow))
	sDay = cStr(Day(dNow))
	GenSimDate = sYear + sMonth + sDay
End Function

Function CleanMac(sMac)
	'Strips colon (:) characters from the variable passed to this function.  The passed variable is presumed to be a Mac address.
	Dim oRegExp
	Set oRegExp = new RegExp
	oRegExp.IgnoreCase = true
	oRegExp.Global = true
	oRegExp.Pattern = ":"
	CleanMac = oRegExp.Replace(sMac, "")
End Function

Function GenUniComp(sMac,sSerial,sATag)
	'Generates a hopefully unique computer name by:
	'   Selecting from available MacAddress, SerialNumber, or Asset Tag then
	'   triming the right eight digits from the value and appending a hyphen with the current date.
	Dim sSimDate, sUniVal
	oLogging.CreateEntry "ZUVMUserExit: sMac value in UserExit script is: " & sMac,LogTypeInfo
	oLogging.CreateEntry "ZUVMUserExit: sSerial value in UserExit script is: " & sSerial,LogTypeInfo
	oLogging.CreateEntry "ZUVMUserExit: sATag value in UserExit script is: " & sATag,LogTypeInfo
	if InStr(sMac,"%Mac") = 0 then
		oLogging.CreateEntry "ZUVMUserExit: Using Mac Address to generate computer name",LogTypeInfo
		sMac = CleanMac(sMac)
		oLogging.CreateEntry "ZUVMUserExit: Cleaned sMac values now is: " & sMac,LogTypeInfo
		sUniVal = sMac
	elseif InStr(sSerial,"%Serial") = 0 then
		oLogging.CreateEntry "ZUVMUserExit: Using Serial Number to generate computer name.",LogTypeInfo
		sUniVal = sSerial
	elseif InStr(sATTag,"%Asset") = 0 then
		oLogging.CreateEntry "ZUVMUserExit: Using Asset Tag to generate computer name.",LogTypeInfo
		sUniVal = sATag
	else
		oLogging.CreateEntry "ZUVMUserExit: Using Fallback Computer Name",LogTypeInfo
		sUniVal = "UVMLT"
	end if
	oLogging.CreateEntry "ZUVMUserExit: sUniVal now set to: " & sUniVal,LogTypeInfo
	sSimDate = GenSimDate(sSimDate)
	GenUniComp = Right(sUniVal, 8) + "-" + sSimDate
	oLogging.CreateEntry "ZUVMUserExit: Unique Computer Name will be: " & GenUniComp,LogTypeInfo
End Function

Calling the GenUniComp function from CustomSettings.ini:

ComputerName=#GenUniComp("%MacAddress%","%SerialNumber%","%AssetTag%")#
Scripting the Windows Experience, System Imaging and Deployment

Windows 8 Hardware – Waiting for Godot?

Apr 5th, 12 / 0 Comments

I have been running Windows 8 CP on my primary workstation for about two weeks now.  The experience is surprisingly good, although I am sure that work-a-day users of Windows are going to freak out at the site of the Metro, especially when accessed from the traditional Windows keyboard and mouse.  To that end, I though it might be useful to get my hands on some touch-enabled hardware.

This has tuned out to be less than feasible.  According to the Windows 8 build blog, Win8-certified touch devices will have to be capable of handling five-point touch input:
http://blogs.msdn.com/b/b8/archive/2012/03/28/touch-hardware-and-windows-8.aspx

This is an interesting point of data, because Windows 7 “touch ready” devices only needed to support two-point multi-touch.  Thus, the almost then entire mini-ecosystem of touch devices that were built for Windows 7 will never get a Win8 certification.  Those touch monitors from Dell and HP?  Nope.  All-in-one touchscreen PCs from a multitude of manufacturers?  Nope. 

It looks as though the Win8 touch interface has been designed with the capacitive multi-touch displays that are commonplace on tablets and smartphones in mind.  But even a number of current Tablet PC and Windows Slates with capacitive multi-touch will be out in the cold, as a lot of them only support four-point multi-touch.  As for multi-touch monitors, the only that I can find that support 5+ points of touch are the 3M displayes referenced in theWin8 Build blog (see above).  Since these displays retail for over $1000, I think most people would be better off buying a tablet like the ASUS EP121, ASUS B121, or the Samsung Slate 7.

I suppose you might be able to get some mileage out of multi-touch track pads.  Most newer laptops have pads that support multi-touch, but my venerable Dell E6500 does not.  To that end, I am going to try out a Logitech TouchPad Wireless to see if having a gesture-supporting track pad buys me anything in Win8-ville.  I’ll post back with results.

In any event, it seems that those wanting to see what the Windows 8 touch experience will really be like are going to have to wait on some hardware that does not yet exist.  Touch screen ultrabooks?  Hopefully this will be more fruitful than Waiting for Godot.

Uncategorized

MDT 2012 – The Ultimate WinPE Boot Media

Mar 20th, 12 / 0 Comments

This week I went to rebuild our MS DaRT Emergency Rescue Disk media.  While looking into the available tools to automate injection of our LiteTouch / MDT Deployment Workbench driver store into the DaRT boot media, I discovered something interesting in the MDT 2012 RC1 release notes… MDT 2012 supports the addition of DaRT into the LiteTouch boot media.  Once complete, you will have boot media that will support LiteTouch deployment, Standard WinRE recovery tools, and MS DaRT tools.  Too cool!  Some hours of work and a few gotchas later, it is done.  My LiteTouch media contains LiteTouch scripts, WinRE, DaRT, and PGP command line utilities.  Best of all, rebuilding of the media is sustainable.  Here is how it is done:

  1. Making WinRE available in LiteTouch boot media:
    In the Operating Systems section of the workbench, create a DEV folder.  Add to this one operating system with source files for each architecture that you need boot media for (i.e. amd64 and x86).  The OS version must match the version of WinPE used by the AIK on your build system.  (e.g. If you are using the Windows 7 AIK, you need current Windows 7 sources in the deployment share.)  To avoid trouble, make sure that these are the only operating systems with source files for this version of the AIK (e.g. You can have Vista source files if you need them, but keep only one Win 7 source so you will know which boot.wim is being used to generate your LiteTouch media).
  2. Adding DaRT:
    Follow the directions in the MDT help to install and activate the DaRT tools into the deployment share.
    In the deployment share CustomSettings.ini, set the variable:
    PrepareWinRE=YES
    This will insure that the workbench will generate a combined WinRE/DaRT image.
  3. Adding PGP:
    To make PGP tools available, use the PGPPE tools to apply pgpwde.exe to the boot.wim in the 32-bit operating system source files that you created in step 1, as follows:
    pgppe.exe /vista [pathToOSSource] [pathToPGPFiles]
    This will install PGP tools into both the Windows Setup and WinPE images in the stock boot.wim.  When you generate LiteTouch media from the Workbench, the PGP tools already will be present.
    Documentation on the use of PGPPE can be found here:
    http://www.symantec.com/business/support/index?page=content&id=HOWTO64225&actp=search&viewlocale=en_US&searchid=1332275738030
    and here:
    http://www.symantec.com/business/support/index?page=content&id=TECH149634
    (The first article contains corrections to the second article.  Note that PGPPE now is part of a standard PGP Desktop install, and does not need to be downloaded separately).

Of course, there is a lot more going on with MDT 2012 than just boot media changes… more on that later.

System Imaging and Deployment

SharePoint 2010 – External Trust Configuration

Jan 31st, 12 / 0 Comments

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:

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.

 

Uncategorized

SharePoint 2010 – Authentication and Browser Support Planning

Dec 8th, 11 / 0 Comments

We have gone back to the drawing board with SharePoint 2010 planning, and now are challenging some ideas about how authentication must be configured for SharePoint to work with our clients.  Previously, we felt the need to provide multiple supported authenticaiton types (Windows, Basic, and Forms) hosted on different IIS web sites, with unique URL’s (sharepoint, sharepointlite, partnerpoint).  We also felt the need to have a version of sharepoint with “Client Integration” features enabled, and one with these features disabled (sharepointlite).  With changes in SharePoint 2010, is this really necessary?

First, let’s look at the Windows vs. Basic assumption.  Are there any browsers out there that do not support Windows/NTLM authentication?  In fact, there are… the Android mobile browser and, um…, well, there do not appear to be any others.  However, it is not necessary to make a separate web site available to allow basic authentication.  If we enable basic auth on an exsiting Windows-auth web site, browsers that do not support Windows auth suddenly start working.

Now, let’s look at the client integrated vs. dumbed-down assumption.  Previously, we wanted to ensure the clients handled links to MS Office documents stored in SharePoint in a predictable fashion.  Users of Firefox and Safari frequently complained about “strange” document handling behavior in SharePoint links.  For people experiencing confusion caused by failed attempts to launch Office applications from SharePoint browser links, we exposed a version of SharePoint that had the client integration features disabled.  HOWEVER, under SharePoint 2010, the client integration features are much more reliable.  On Windows, I am able to make use of Office 2010 client integration in both IE9 and Firefox.  On the Mac, client integration works with Office 2011 Mac and Safari 5 or FireFox 8.  Additionally, SharePoint will detect if a browser cannot support client integration, and will disable Office inegration links automatically.  For example, the “Open in Word” link is greyed-out in my Chrome browser, while the “Download file” link is active.

Add to this the new mobile web version of SharePoint 2010.  If you connect from a browser listed in the “compat.browser” file on the SharePoint web server, you get directed to a light-weight mobile version of SharePoint instead.  See: http://blogs.technet.com/b/office2010/archive/2010/03/09/configure-sharepoint-server-2010-for-mobile-device-access.aspx for more details on how “compat.browser” works.  This version will use Office Web Apps to render Office documents, but editing will not be possible.  This grants mobile users a functional (if somewhat limited) access method for SharePoint content, while at the same time sidestepping the issue of client integration.  It also means that we do not have to deal with the hassle of attempting to ensure that Office Web Apps will work in a myriad of underpowered mobile browsers.

All things considered, things are looking bright for SharePoint 2010.  It seems we no longer will need a “lite” version of SharePoint, and we will not need two URLs to support the varying authentication needs of legacy browsers.

Sharepoint

Driver installation with SCCM Software Distribution

Dec 6th, 11 / 0 Comments

Here we are, working with SCCM again.  Making difficult things possible, and simple things difficult.  Today we wish to distribute a SmartCard driver to all of our managed servers, so that we can require Smart Card for certain classes of logins.  the newer “CNG” Smart Card minidrivers are all simple “.inf” driver packages that you can right-click install.  This ought to be easy, thought the sys admin.  Wrong!

Installation of inf drivers is not a well documented command line procedure (unlike the rather more complicated “.msi” package, which at least is easy to script).

My thanks goes out to the following bloggers and forum users for their assistance with this case:

The script that I cobbled together to install the Athena “ASECard” minidriver is displayed below.  Note that this should work for pretty much any minidriver, as long as it has a “DefaultInstall” section in the inf file.  I just unpack the amd64 and x86 driver cab files into their respective directories, put the batch script one directory above these, and make an SCCM software package of the whole thing.  The installation command line is simply the batch file name.

@echo off
REM Installs the drivers specified in the "DefaultInstall" section
REM of the aseMD.inf that is appropriate for the current (x86 or amd64) platform.
REM Install is silent (4 flag), with no reboot (N flag).
REM The INF is specified to be in the x86 or amd64 subdirectory
REM of the script directory (%~dp0).

echo Detecting platform...
IF EXIST "%programfiles(x86)%" (GOTO :amd64) ELSE (GOTO :i386)

:i386
echo Installing 32-bit driver...
cd x86
%windir%\system32\rundll32.exe advpack.dll,LaunchINFSectionEx "%~dp0x86\aseMD.inf",DefaultInstall,,4,N
goto :EOF

:amd64
REM The command will run in 64-bit mode (%windir%\sysnative\),
REM when called from a 32-bit CMD.exe (as will be the case with SCCM).
echo Installing 64-bit driver...
cd amd64
%windir%\sysnative\rundll32.exe advpack.dll,LaunchINFSectionEx "%~dp0amd64\aseMD.inf",DefaultInstall,,4,N
goto :EOF
REM End of file
Monitoring and Management, Scripting the Windows Experience

VMware Performance Charts broken again – fix your connection string.

Nov 11th, 11 / 0 Comments

Following upgrade of our Virtual Center server to the vSphere 5 version, we have been struggling with crashing services and memory exhaustion.  Well, the server got an upgrade from 8Gb to 16Gb of RAM this am, so it is now swimming in excess memory.  Despite this, the Perf Charts in vCenter have gone dead again.

We were seeing errors similar to those described here:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012812

We got the “”perf charts service experienced an internal error” when looking at the Performance tab for any object in the vSphere Client.  A look at the latest “vctomcat-stderr[...].log” file in “C:\Program Files\VMware\Infrastructure\tomcat\logs” reveals JDBC connection errors.  The damn service is trying to connect to the standby partner of our SQL database mirrored pair!  So where are the connection strings stored for this service.  Well, no thanks to VMware documentation, I discovered the connection string stored here:
C:\ProgramData\VMware\VMware VirtualCenter\vcdb.properties

All I had to do was append “;failoverPartner=[hostName]” to the line starting with “url=”, then restart the tomcat service (the “VMware VirtualCenter Management WebServices” service).  Viola… performance reports are back.

Now back to fixing everything else that is broken… also known as “everything”.

Virtual Servers

Windows file server aliases, NetBIOS over TCP, and Incomplete Documentation

Nov 8th, 11 / 0 Comments

It was inevitable… some people have started to notice that their bloody Multi-Function Devices (the overpriced beasts formerly known as “printer/scanner/copiers”) no longer can scan to our file server.  Why?  Because we got all smarty pants and tried to disabled “NetBT” (NetBIOS over TCP) for access to our new file server.  We figured “Hey, CIFS over TCP has been available since, what, 1999?  We won’t have any problems with back level clients!”.  Rubes.  Turns out a lot of MFDs still require NetBT.  Rather than be a pain, I have decided to enable NetBT on the new server.  After all, it is mainly the laggards that suffer the consequences of back-level clients (and besides, if I don’t do this I will either have to go update their firmware myself, or locate some mythological pile of gold to pay for new MFDs).

The tricky bit for us was that our clients are using a name other than the server’s primary name to access the server.  Modern clients don’t care.  SMB2-capable systems only require that the server name being used has a valid matching DNS entry, and if you want Kerberos to work, you need to add a matching Service Principal Name (SPN).  We tested that our a long time back, and had no SMB2 client issues at go live.  SMB1 is a bit more fussy… you need to tell the server not to get bent out of shape when the requested server name is not the primary server name by adding the “DisableStrictNameChecking” DWORD in the HLKM\System\CurrentControlSet\Services\LanManServer\Parameters registry key.  We picked up on that one on migration night.

But now, after activating NetBIOS over TCP, client systems still are giving us grief.  Upon connection, we can see the NetBIOS Session Service reporting “Called Name Not Present” in a wire trace.  What gives?  DNS, SPN, and WINS entries are not enough for good-old LanMan?  Sounds like the server needs some additional convincing.

It turns out the key is in “optional names”.  When I added a Reg_multi_sz entry named “OptionalNames” to the HLKM\System\CurrentControlSet\Services\LanManServer\Parameters registry key, populated it with the alias name of our file server, activated NetBIOS over TCP, then rebooted, I found that the server started granting connection requests on TCP Port 139 (the legacy NetBT CIFS port).  Horray!  As an added bonus, our windows server is now registering both its primary name and its supported alias in WINS and DNS… no need for static entries.  Now to see if the MFDs are satisfied…

It really is a pity that there is no one article on this subject in TechNet.  It appears that the folks at Microsoft have little belief that anyone would be so asinine as to want to have a file server with an alias, and support for CIFS over NetBT, and support for CIFS over TCP, and support for modern SMB2 clients.  I’ll bet a consultants would say “Gee, I have never seen this before”.  We get that a lot.

Articles that helped during this troubleshooting process:

Uncategorized