Yep, "it depended" in our case, so we had to have it on for the whole volume from the get go, to include program files, etc. our testing at the time, if I recall correctly, didn't leave us confident that fsutil would do the job well enough, as there wasn't a registry at the time it would be invoked, so a format step right after the built-in step in the sccm ts was easy, no cost, and we were guaranteed that it would be on for the volume by way of format before there were any files or registries on the disk. And it works fine in an SCCM ts, where there's not any MDT script logic thinking about it and checking it for you.
Todd From: [email protected] [mailto:[email protected]] On Behalf Of Kent, Mark Sent: Thursday, May 29, 2014 8:48 AM To: [email protected] Subject: RE: [MDT-OSD] 8.3 filenames We have one app that needs it, and of course we have it off. Even if you turn it on, folders that were created when it was off do not have an 8.3 file name (like Program Files and Program Files x86). Also if you try to run a command to make 8.3 file names for those folders when they contain an app in use, the command will fail. I actually built a task sequence to boot into WinPE, turn on 8.3, create 8.3 file names for those folders, then boot back into Windows and do the app install. Seems convoluted but that's what you have to do, and it works. Mark Kent (MCP) Sr. Desktop Systems Engineer Computing & Technology Services - SUNY Buffalo State From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Michael Niehaus Sent: Thursday, May 29, 2014 9:39 AM To: [email protected]<mailto:[email protected]> Subject: RE: [MDT-OSD] 8.3 filenames Actually, if you have software that needs 8.3 filename support, you may need it in both. (I've seen cases where the software itself breaks with 8.3 off when it is installed, and others where it doesn't work properly with short names off even after installing correctly.) So "it depends." Thanks, -Michael From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Kent, Mark Sent: Thursday, May 29, 2014 6:01 AM To: [email protected]<mailto:[email protected]> Subject: RE: [MDT-OSD] 8.3 filenames You could also simply add the commands to your deploy workflow, rather than killing yourself trying to get it in the capture. Mark Kent (MCP) Sr. Desktop Systems Engineer Computing & Technology Services - SUNY Buffalo State From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Mote, Todd Sent: Thursday, May 29, 2014 8:44 AM To: [email protected]<mailto:[email protected]> Subject: RE: [MDT-OSD] 8.3 filenames On the vms that I captured from, without my step, running "fsutil 8dot3name query c:" returns , On 2008 R2 "The volume state for Disable8dot3 is 0 (8dot3 name creation is enabled). The registry state of NtfsDisable8dot3NameCreation is 2, the default (Volume level setting). Based on the above two settings, 8dot3 name creation is enabled on c:" and on 2012 R2 "The volume state is: 0 (8dot3 name creation is enabled). The registry state is: 2 (Per volume setting - the default). Based on the above two settings, 8dot3 name creation is enabled on c:" Neither of these are the deployed version of what I captured, I just turned the vms back on after capturing them. So it would seem that MDT took care of enabling 8.3 for me in both cases, and captured them that way. It looks like that's one less step to bring over from SCCM. Not saying one B&C is better than the other, just different. :) I'm sure this won't be the last difference I find. So what should I expect from deploying these then, since they both captured with it on? Should what Michael describes below, happen in ztiapply now? Would I expect it to be off after deploying 2012 R2? Those answers will have to wait until I do my SCCM SP1 to R2 upgrade next week. Thanks for the early morning replies. Todd From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Michael Niehaus Sent: Thursday, May 29, 2014 12:56 AM To: [email protected]<mailto:[email protected]> Subject: RE: [MDT-OSD] 8.3 filenames MDT automatically enables 8dot3 when deploying Windows 7 and earlier OSes via this logic in LTIApply: ' If deploying something less than Windows 8, make sure 8dot3 support is enabled. Diskpart in Windows PE 4.0 ' leaves 8dot3 off by default. If Left(sOSBuild, 3) < "6.2" then oLogging.CreateEntry "Enabling 8dot3 name support on volume " & sDestinationDrive, LogTypeInfo On Error Resume Next oShell.Run "fsutil.exe 8dot3name set " & sDestinationDrive & " 0", 0, true On Error Goto 0 End if However, ImageX and DISM are supposed to automatically enable this any time you apply a WIM file that has short names in it (as most would). I've never validated that though. If you remove the condition around that logic in LTIApply.wsf, instead of running your own FSUTIL command, does it change the result? That obviously points out a different solution too: Just run "fsutil 8dot3name set c: 0" (adjusting for the appropriate drive letter, using %OSDisk% or something similar) instead of reformatting, which isn't necessary to do this. Thanks, -Michael From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Keith Garner Sent: Wednesday, May 28, 2014 10:32 PM To: [email protected]<mailto:[email protected]> Subject: RE: [MDT-OSD] 8.3 filenames Short answer: Don't run the command, you'll be fine. Some feedback: 1. Do not hard code C: in the command, it may not work. :) instead you could use a variable like %OSDisk% set by ZTIDiskPArt.wsf 2. MDT does not use Format.com to format partitions, instead it uses diskpart.exe. 3. I also don't see the need to reformat the Target OS Disk to support 8.3. >From what I can tell all my MDT Litetouch targeted OS Partitions Support 8.3 >NTFS *AS-IS*. 4. To check yourself run the command: [cid:[email protected]] 5. You can Set 8.3 status using the fsutil.exe command as well. 6. I had to look this up, but *yes* WIM files support the ability to capture and preserve 8.3 generated names, and I was genuinely surprised by this! I might recommend treating imaging process as 8.3 agnostic, and only worrying about 8.3 status when applying the image on the target. (IMHO) AS for the specific error below, when you reboot into WinPE, chances are pretty good that the OS has changed the drive letters of the partition we want to capture. How do we find our OS Target Partition between WinPE and full OS reboots? The Trick MDT LiteTouch uses is to take a profile Signature of the Target OS Drive, so we can find it again. We use the Size, VolumeName, and VolumeSerialNumber. My guess is that when you reformatted the drive, you gave it a *new* VolumeSerialNumber, hense the reason why it can't find the *EXACT* drive again, because it's looking for the old VolumeSerialNumber. -k From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Mote, Todd Sent: Wednesday, May 28, 2014 3:25 PM To: [email protected]<mailto:[email protected]> Subject: [MDT-OSD] 8.3 filenames Not to start this war again, but up until teched I'd built and captured with sccm. At teched several folks strongly suggested that I stop doing that immediately. I in fact did a b&c from teched, and it worked great, though somehow it had mistakenly used the standard version of server rather than the enterprise version, so I adjusted the TS that had just finished successfully with standard to enterprise, only to find it failed with no discernable reason. So that was the straw that broke the camels back, and I set up MDT 2013 standalone. Couple of days later I was building and capturing, seemingly reliably again. So I go to our sccm build and capture to get the steps that had been developed over the years to add them to mt new mdt b&c ts. One step, to satisfy some older programs being able to find executables was that of turning on 8.3 filename support. Easy 'run command line' step immediately after the 'partition and format' step, "cmd /c format c: /fs:ntfs /q /v:OSDisk /s:enable /y". have never had a problem with it in the sccm B&C, all the apps in question work fine, life has been dandy. When I added this step to my mdt b&c, everything worked fine up until the capture part. It bails out when attempting to capture with an error along the lines of "couldn't find a partition to back up" here's the section from my bdd.log: <![LOG[TargetPartitionIdentifier is set, find disk: SELECT * FROM Win32_LogicalDisk WHERE Size = '53161750528' and VolumeName = 'OSDisk' and VolumeSerialNumber = '06C99A9B']LOG]!><time="15:27:18.000+000" date="05-21-2014" component="ZTIBackup" context="" type="1" thread="" file="ZTIBackup"> <![LOG[Search for Drive: TargetPartitionIdentifier SELECT * FROM Win32_LogicalDisk WHERE Size = '53161750528' and VolumeName = 'OSDisk' and VolumeSerialNumber = '06C99A9B']LOG]!><time="15:27:18.000+000" date="05-21-2014" component="ZTIBackup" context="" type="1" thread="" file="ZTIBackup"> <![LOG[DestinationDisk and Partition did not yield a target Partition.]LOG]!><time="15:27:18.000+000" date="05-21-2014" component="ZTIBackup" context="" type="1" thread="" file="ZTIBackup"> <![LOG[FAILURE ( 5456 ): Unable to determine Destination Disk, Partition, and/or Drive. See BDD.LOG for more information.]LOG]!><time="15:27:18.000+000" date="05-21-2014" component="ZTIBackup" context="" type="3" thread="" file="ZTIBackup"> <![LOG[Command completed, return code = -2147467259]LOG]!><time="15:27:18.000+000" date="05-21-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch"> <![LOG[Litetouch deployment failed, Return Code = -2147467259 0x80004005]LOG]!><time="15:27:18.000+000" date="05-21-2014" component="LiteTouch" context="" type="3" thread="" file="LiteTouch"> How can I enable 8.3 filename support and use the partition and format step built into mdt? Disabling my format step, making no other changes allows the sequence to finish, and capture fine. Enabling it makes it fail with the above error. Obviously size, volumename, or volumeserialnumber change, but I don't know how to affect anything other than volume name. Todd
