Jump to content


Established Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Stephensr

  • Rank

Profile Information

  • Gender
  • Location
  1. Wooohoooo Resolved this.... Went back to basics, re-created the unattend file in SIM and set the UILanguage to en-US and all is working grand!!
  2. Additional Language Pack…. I’m deploying W7 X64 Enterprise using SCCM 2007 with MDT Integrated (zero’ish touch), no problem there at all… Standard setup en-GB throughout however a requirement has arisen to include the zh-CN (Simplified Chinese) Language Pack for one of our regions. en-GB is to remain the standard but zh-CN needs to installed as an option for the users in that region. The language pack installs great apart from one annoying thing and that is the language option screen in OOBE, the damn thing keeps appearing and it’s driving me nuts! Please see attached file.. I am using our standard unattend file which is minimal and is attached... I have tried the following: Added the International Core (language settings) to the unattend at the Specialize pass – the Prompt Still appears. Removed the Specialize pass from the unattend – the Prompt Still appears. Added Shell Setup and set OOBE to skip machine and user setup – the Prompt still appears. Changed the package source location to be local directory (I read this on this post) – the Prompt Still appears. Have I missed something glaringly obvious..? Any ideas would be greatly received.. Thanks in advance. Rich.
  3. Hey hotdog453 Did you ever get this resolved? This has presented itself in my environment when everything was fine. It's not consistent which is driving me nuts... Thanks Rich.
  4. Hi there... Yes you are correct...the blue screen is occuring because the pointsec pre-boot sector is referencing data on the drive that no longer exists... Are you re-sizing the partitions? I'm pretty sure that hard linking on an encrypted disk is not possible if you are resizing the drive... we are using a State Migration Point to store our backed up data.... because we resized the partitions I had to break the refresh senario into two phases using two task sequences on encrypted laptops.. 1st ) A simple back -up TS which runs USMT and stores the data on the SMP 2nd) A deploy TS which deploys the image etc...however the encrypted laptops have to be pxe booted to this in order to re-partition and remove the pointsec pre-boot sector on the drive. Rich.
  5. Morning All… I’m looking to use the Pre and Post OEM Task Sequences in SCCM 2007 R2… I have successfully got these two task sequences working on the same physical system. The Pre OEM Task Sequence installs the captured image and core apps and then runs ZTIOEM/Pre to place the breadcrumb files and set the partition to inactive.. .the same system is then pxe booted and the Post OEM Task Sequence is run. This applies the system name, drivers, install system specific apps and joins the domain, everything works as expected. The problem I have is capturing an image of the system once it has run the Pre-OEM Task Sequence in order to apply the image to another piece of kit as the reseller will be. I have read that using imagex is not viable and that the capture/clone should be done using a 3rd part application like Ghost, can someone please confirm this for me? Capturing the image using imagex and then applying it to another system seems to be causing issues as after the first reboot in the Post-OEM task sequence the machine is missing the bootmgr and cannot continue, as I understand it this is a symptom of why imagex can’t be used to capture an inactive partition, is this correct? Thanks in advance.. Richard.
  6. Morning all, I’ve been looking at an issue for the last couple of days that has me somewhat confused. I know there have been other posts regarding this but I’ve not yet seen a definitive reason behind it… We have a small number of systems in the environment that have two physical drives for example a 75GB and a 300GB drive, meaning the preferred setup would be: Disk 0 (75GB) 200 MB: System reserved 50GB: OSDisk 24GB: Data Partition Disk 1 (300GB) 300GB: Extra Can someone please explain why in Win PE these disk randomly swap between Disk 0 and Disk 1?? I need to ensure that in a system refresh scenario these desktops only ever have W7 Enterprise installed to Disk 0 (in the example above) thus leaving Disk 1 alone. We are using the OSPart task sequence variable at the apply OS Phase so I am going to try to use the following script that I believe Niall had a hand in creating in order to target the current partition that has Windows installed: <job id="GetDriveletter"> <script language="VBScript" src="..\ZTIUtility.vbs"/> <script language="VBScript"> dim driveSearch Set objFSO = CreateObject("Scripting.FileSystemObject") Set colDrives = objFSO.Drives For Each objDrive in colDrives driveSearch = objDrive.DriveLetter & ":\\Windows\\explorer.exe" strComputer = "." Set objWMIService = GetObject("winmgmts:" _ & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2") Set colFiles = _ objWMIService.ExecQuery("Select * From CIM_DataFile Where Name = '" & driveSearch & "'") If colFiles.Count < 1 Then Else oEnvironment.Item("OSPART") = objDrive.DriveLetter & ":" End If Next </script> </job> I would still very much like some insight as to why the Disk numbers change at what seems to be random intervals….is it a hardware issue i.e. symptom of using SATA drives, or that OSD prefers the larger drive.... Thanks. Rich.
  7. Bronx Bull, I've been working away in the lab and after a few teething issues with DMU compilers I can confirm that with the filter drivers injected the TS is working fine on the Encrypted systems! If I am ever in Upstate NY I owe you a beer or two!! Thanks-for taking time out to assist, really appreciated! Issue Resolved! Rich.
  8. Morning Bronx Bull The OSDStateStore sounds interesting, although because the whole drive is encrypted I wonder if this will still work. Because the TS is running a Refresh(Wipe & Load) it is being run from within the OS… I don’t think you can diskpart the C partition when the OS is running… I totally agree that USMT isn’t the issue..and yep like your TS I have UMST loadstate is in the tail end of the TS, which works as expected. This TS including USMT works absolutely fine on un-encrypted systems, it’s purely the encrypted laptops that are causing the issue.. From the image provided you can see that: Refresh scenario is initiated from within the exisiting OS in order to perform USMT tasks on WinXP or Win7 using the variable = SMSTSInWinPE = False) USMT Scanstate completes…. The system then performs the Reboot task to the associated boot image which stages the following to the encrypted drive in the _SMSTaskSequence directory prior to actually rebooting: TSEnv.dat Backup directory Logs directory WDPackage directory WinPE directory The system the reboots, Checkpoint encryption then prompts for logon credentials which are then entered. Win PE then boots and attempts to initiate hardware devices, however because the disk is not yet accessible and is actually still encrypted at this moment in time the “Unable to read task sequence configuration disk” message is displayed and the task sequence fails Please see the TS attached…
  9. Thanks for your response Bronx Bull…. 3rd party Encryption and OSD really don’t play nice and it’s giving me a bad headache! ;-) All packages are being run directly from the DP’s however when the TS runs it automatically stages the TS config files (_SMSTaskSequence) to a local drive, then boots to PE and references the _SMSTaskSequence directory… I think re-directing the staging directory to a network share sounds like it could get really quire messy, if as you say it is even possible. I will investigate further… I have heared about the Checkpoint filter drivers but from what I have read they seem to be for Bart PE and have not seen or heard of any succesfull SCCM OSD Win PE integrations… Not really possible as the OS is running at the time of TS execution… so the process is: If the user initiates the TS and the config files are staged locally on the encrypted C partition, The TS then runs USMT and stores data on the SMP The system then reboots to WinPE (I will test the following tomorrow) Create TSHook and a Diskpart script to run prior to the TS starting which blows away the encryption & _SMSTaskSequence directory and creating a new un-encrypted file system acessablie from WinPE I will test but I expect the TS will fail as the _SMSTaskSequence containing the TS config files has been blown away by Diskpart…unless I’m missing something?? I suspect for the encrypted laptops I will need to remove USMT from the TS and use Separate TS’s for Back-up (USMT Scanstate) and Restore (USMT Loadstate) and have the field guys PXE boot the encrypted laptops and process the TS as a “New Computer” thus blowing away the encryption straight away - Only after the user has successfully run the BackUp TS though….. Fun & Games… J Rich.
  10. Morning All, any ideas on this one would be greatly appreciated. I am deploying our captured image using one task sequence that caters for the Bare metal and Refresh (now Wipe & Load I believe) scenarios, this has worked fined until we perform a Wipe & Load on the Checkpoint Encrypted laptops in the fleet. These laptops have all partitions encrypted leaving no un-encrypted estate on them. You may already see where I am going with this…. The task sequence is being advertised to the user who runs the TS from within Windows enabling the capture of USMT data to the SMP. Once the USMT Capture is complete the system is rebooted to the PE boot image in order to run diskpart and apply the image etc…. This is where the TS fails. The Task Sequence config files have been staged to the c:\_SMSTaskSequence directory which is of course Encrypted within PE, we then receive the “Unable to read task sequence configuration disk.” I have seen a number posts elsewhere that mention using a “Hook” that runs a diskpart script upon the restart to clean and re-partition the disk before TS begins to process. I am a little unsure how this would work as the config files will have been “blown away” by the diskpart script and surely the TS will fail again with same error, can any confirm my suspicions? I have also seen some articles that mention changing the location of the Staging config files from c:\_SMSTaskSequence to x:\_SMSTaskSequence . Again I’m a bit unsure about this as I didn’t think X: was accessible prior to loading the PE boot image. I hope this makes sense. I look forward to hearing any suggestions.. Kind Regards, Rich.
  • Create New...