You’ll find me in the club…

You’ll find me in here > http://social.technet.microsoft.com/Forums/en-US/category/systemcenter2012configurationmanager

I try to drop in each day on the forums and help out where I can, so do use this excellent set of forums as a great port of call for your ConfigMgr woes.  There are many talented people, some of whom are MVP’s, who commit a lot of time to the forums and helping people out.  Do please remember a little piece of etiquette though; that if someone takes the time out to help you – return the favour by marking their post as helpful or as the answer if appropriate.  It just might give them a warm fuzzy feeling inside.

ConfigMgr 2012: 64bit file system redirection bites again…

Even though the ConfigMgr 2012 client is supposedly 64bit now, the issue with 64bit file system redirection is still very much a problem during Task Sequence and even regular package/program deployments when we want to copy things to the ‘Native’ “%Program Files%” or “%WinDir%\System32”.  File System redirection kicks in and we are magically transported to the 32bit “Program Files (x86)” or “Windows\SysWOW64”. Boo hiss.  I even found a log entry in the client-side execmgr.log which clearly states;

Running "C:\Windows\ccmcache\3\CopyFiles-Temp.cmd" with 32bitLauncher

Why? Why? Why?

In the Task Sequence we can easily get around this problem by choosing to run a “Run Command Line” step instead of an Install Package step; we reference our package and command line and ensure we tick the box to “Disable 64bit file system redirection.”  This is all well and good but what about deployments outside of the Task Sequence?  There simply isn’t the same option, so we need to build this into our script/batch file that we are trying to run.  My borderline Obsessive Compulsiveness dictates that the single solution must ‘just work’ for both 32bit and 64bit operating systems.

The most elegant way I have found for doing this that doesn’t involve re-writing sections of your batch file to cater for the various operating environments, involves taking advantage of being able to invoke the ‘Native’ 64bit command processor (system32\cmd.exe) from within any 32bit command processor running within a 64bit OS if needed.  Here’s a snippet of code you simply add to the very top of your existing batch files…

@ECHO OFF
IF NOT "%PROCESSOR_ARCHITEW6432%"=="AMD64" GOTO native
  ECHO "Re-launching Script in Native Command Processor..."
  %SystemRoot%\Sysnative\cmd.exe /c %0 %*
  EXIT
:native
ECHO "Running Script in Native Command Processor..."
REM Your script starts here

What this will do for you, is first detect if the batch file is being ran from within a 32bit command interpreter on a 64bit OS – if it isn’t then the code jumps to the “:native” label and continues your script as usual.  If we are in a 32bit command interpreter on a 64bit OS, then the script invokes the ‘Native’ 64bit command processor to run this very same batch file and then exit.  The %PROCESSOR_ARCHITEW6432% condition near the top will simply be evaluated again by the Native command processor and ignored (as we are running 64bit cmd.exe in 64bit OS, or a 32bit cmd in a 32bit OS) and your script will happily continue without being subject to redirection.  Neat!

Andy

ConfigMgr 2012 SP1: The Lord Giveth…

..but he’s taken away the ability to add collection variables to the default “Unknown Computers” collection.  Why God, why.

I like the convenience of using this collection to attach the “OSDComputerName” blank variable so that the deployment process for new ‘Unknown’ systems prompts for this information.  I now have to create another collection of my own for this variable, essentially containing the same two resources.

MDT 2012 Update 1: Missing “Request State Store” step causes state restore to fail from State Migration Point in REPLACE Scenario.

I have found that the MDT 2012 Update 1 Client Task Sequence Template is now missing a crucial step in the later stages of the task sequence which is needed to restore captured data from the ConfigMgr State Migration Point when working under the REPLACE scenario – and we need to add this back in.

You simply need to add a “Request State Store” step just above the new “Connect to State Store” step (which looks to just do an authentication against UNC path) and add a condition on the step to run only if Task Sequence Variable “USMTLOCAL” not equals TRUE.

Also add a “Release State Store” step below the “Restore User State” task, again with the same condition as above.

Andy