Hey, after getting W7 deployment working on our SCCM 2007 R3 lab I wanted to test out bitlocker. Made a copy of our working TaskSequence and did the following... Edited Partition Disk 0: made "System Reserved" boot partition at 300 MB, stored drive letter to BOOTPART made "Windows" system partition at 50GB, stored drive letter to OSPART made "Data" partition for the rest of the disk changed the Apply Windows Settings to use the OSPART partition as destination Time to deploy... PXE booting, selecting my TaskSequence and sitting down to wait... Partitioning - OK (C: D: and E:) Apply Operating System (to D: captured from a build and capture process earlier) - OK Apply Windows Settings - OK Apply Network Drivers - OK (some restarts here to launch "native W7 installer" and join domain) Apply Device Drivers - OK Setup windows and ConfigMgr ... hangs Looking at the smsts.log it fails at this last step. The installation properties are ... SMSSLP=PD1 PATCH="%_SMSTSMDataPath%\OSD\B0100020\i386\hotfix\KB955955\SCCM2007AC-SP1-KB955955-x86.msp" PATCH="%_SMSTSMDataPath%\OSD\B0100020\i386\hotfix\KB977203\SCCM2007AC-SP2-KB977203-x86.msp" PATCH="%_SMSTSMDataPath%\OSD\B0100020\i386\hotfix\KB977384\sccm2007ac-sp2-kb977384-x86-enu.msp" (Not sure if the above is correct, but it has been working on another W7 TaskSequence) The smsts.log says it tried to execute: "D:\_SMSTaskSequence\OSD\B0100020\ccmsetup.exe" /useronly /config:MobileClient.TCF /status:576 Looking at the MobileClient.TCF it has replaced the references to %_SMSTSMDataPath% with E:\_SMSTaskSequence (!) Now, the system has 3 partitions as ordered... Boot 300MB (no driveletter) OS 50GB (C:) Data (D:) Which is how I would expect it to be, however I did notice that during Apply Operating System it used D: for OS (since C: was the smaller boot partition). Does this confuse the CCM install part? As it looks like it set that variable at this stage maybe (i.e. believing that D: was E:) and more importantly; how do I fix it :D It never got far enough in the TS to Enable Bitlocker or do Software Deployment so this is probably unrelated to that but more to some partition/os/image stuff.

The drive assignment in PE is not important to the rest of the setup as windows will take care of this once the TS boots into full OS... I would try and create e client package without any custom switches on, and try and use that... if that works then your problem is installing the client, and you should troubleshoot that!Michael Petersen My Deployment Blog - http://blog.coretech.dk/mip

When using Bitlocker, it is best to put the Bitlocker partition at the end of the drive to avoid Refreshes from seeing it and trying to re-use it. Your conclusion about the drive letters is correct because the %_SMSTSMDataPath% variable is setup before Windows setup is run. After Windows setup, your boot/bitlocker partition gets hidden thus reassigning drive letter which messes up the path stored in _SMSTSMDataPath. PUtting the Bitlocker parition at the end of the drive fixes this. One other question, why use a data drive on a workstation? It will make your life and OSD more difficult in the long run and gives you no advantages except a false sense of security.Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

Well, I'll try to move the BDE partition then but doesn't the W7 installer place it first? (The guides I found on the internet also said to put it first). The data partition is there because our users have NO admin rights, and since we move all user profiles (my documents etc.) to this drive we can always reformat the OS partition without fear of the user having files there. We've learnt this lesson on XP - but maybe it's not necessary on W7? :D Incidentally it seems I got a similar problem today without Bitlocker but by having a CDROM attached... however as every test takes 30-40 minutes it's not something I'd like to repeat ad infinitum :) Actually, using our disksetup it's impossible to put the BDE partition last... :-/ And using only two partitions I think the solution we have in place is going to work aswell. Sooo... Is it possible to change the _SMSTSMDataPath during the TS? To me it looks like it's set to E: then the system reboots and E: becomes D: without the variable being updated... (not sure WHEN this happens though).

Well, I'll try to move the BDE partition then but doesn't the W7 installer place it first? (The guides I found on the internet also said to put it first). Windows installer will use partitions already available -- nothing can "move" a partition. You can also use this http://technet.microsoft.com/en-us/library/dd875534(WS.10).aspx or MDT which uses the drive prep tool. The "guides" don't take into account these other issues because the guides are myopic. The data partition is there because our users have NO admin rights, and since we move all user profiles (my documents etc.) to this drive we can always reformat the OS partition without fear of the user having files there. We've learnt this lesson on XP - but maybe it's not necessary on W7? :D Not to go down this rabbit hole, but they still have permissions to their profiles when non-admins. Moving the profiles directory doesn't change anything except where the files are stored logically. The second concern is well, a false sense of security. If you truly care about the user data, it should be on the network. Incidentally it seems I got a similar problem today without Bitlocker but by having a CDROM attached... however as every test takes 30-40 minutes it's not something I'd like to repeat ad infinitum :) CD Drive letters are assigned after fixed disks so any issues are the result of something different. Actually, using our disksetup it's impossible to put the BDE partition last... :-/ And using only two partitions I think the solution we have in place is going to work aswell. Just another reason not to use it then. However, using the drive prep tool, it will shrink a partition and allow you to work around this. Sooo... Is it possible to change the _SMSTSMDataPath during the TS? To me it looks like it's set to E: then the system reboots and E: becomes D: without the variable being updated... (not sure WHEN this happens though). Not really, but you could hard-code (shiver) the path. Or better yet, use Michael Murgolo's script to install hotfixes during a TS: http://blogs.technet.com/b/deploymentguys/archive/2010/08/13/automatically-populate-the-patch-property-for-the-configmgr-2007-client-installation.aspx.Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

Yea, well - regarding the rabbit hole :) All our computers are laptops and the users are notorious for not saving files on the file servers (they are mostly all independent workers) and also for using the storage for "private stuff" (music, video, photos). Thus having all "my documents" on D: (DATA partition) and specifically just telling users to always save stuff on D: is just making life easier for everyone I believe. I will take a look at that script you mentioned, as I'm also convinced that the installer only applies ONE of the patches (and not all) and that kind of defeats the point of having more than 1 patch. (I'm also unsure if they replace each other - but from what I remember they update different components to different versions...) I did get bitlocker working using just one partition though.

Here's a link with some guidance from Microsoft on moving the profiles directory: http://technet.microsoft.com/en-us/library/cc722177(WS.10).aspx. As for the patches, I noticed that you are specifying the PATCH public property twice. That is incorrect. Public properties should only be specific once. To specify multiple patches, separate them by a semi-colon. Using the script simplifies thing greatly though.Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys