Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

DS6.x: Add Support for Windows 8 Imaging

Created: 12 Nov 2012 | 8 comments
MurrayW's picture
7 Agree
0 Disagree
+7 7 Votes
Login to vote

Currently, the DS "Create Disk Image" job (RDeploy) generates a "The volume is invalid" error message immediately. The log files produced from this simply say "There is a problem with the filesystem." and "Note: The volume is dirty.  Please run chkdsk/fsck (NTFS volume on disk 1, start sector 2048). However;

  1. This was a completely cleaned (in diskpart) hard disk,
  2. The disk was partitioned as MBR, on a BIOS-based system (so exactly the same as Windows 7),
  3. The Windows 8 image was installed from DVD, with no errors, no additional drivers, no additional software, etc.
  4. The disk indicates its in perfect health using multiple tools, including check disk. There is no "problem with the filesystem".
  5. I let Windows set up the partitions and format the disks. We have the standard 350MB "System Reserved" and the remaining as the "Windows" partition.
  6. This was all done on my image-building computer which is a Vista-era HP that "just works" without any additional drivers, etc... so it's not like I am facing the uEFI/GPT issues.

This needs to be fixed ASAP. While there is every chance that we won't deploy Windows 8 immediately, we'd like the option to do so. We certainly need to start testing it and building an SOE design... and for that we need imaging. I really can't see why this is broken, as it should appear to the RDeploy as being almost exactly like our Windows 7 images.

I can work around the issue using the "-RAW" command-line, but that takes many, many hours to complete, and isn't the greatest thing to test an image process and SOE with (I was actually recommended NOT to use this method by a technician at Symantec).

As Windows 8's filesystem hasn't changed wince the "Developer Preview"... I struggle to see why RDeploy STILL hasn't received support for it yet.

Comments 8 CommentsJump to latest comment

ManelR's picture

Hi,

We're using DS 6.9 Build 496 (SP5 MR1) but we deploy using Windows PE and WAIK Tools (because we used this before purchase Symantec tools).

We haven't tried yet to deploy Windows 8 using this method but I suppose that there will be some problems because of:

- New version of Windows PE (4.0?)

- New version of WAIK tools (now called Windows Assesment and Deployment Kit - ADK http://www.microsoft.com/en-us/download/details.as...).

So yes, Symantec, please add support for Windows 8 in your DS solution (RDeploy, Windows PE, etc.) or explain how to add it by ourselves.

Thanks.

IT Systems Manager
LCFIB - Computing Lab
Barcelona School of Informatics
Universitat Politècnica de Catalunya - Barcelona Tech
+1
Login to vote
Pascal KOTTE's picture

Not sure for Rdeploy, not under maintenance any more, as far as I know, but for GHOST, for sure, we would like a a quick update now. Giving a +1. Should be

Did you see any other issue using Dagent 6.9 sp5 under Windows 8? That isa fun, because DS 7.1 not yet correctly supporting Windows 8. (UI cannot run).

~Pascal @ Kotte.net~ Do you speak French? Et utilisez Altiris: venez nous rejoindre sur le GUASF

0
Login to vote
MurrayW's picture

RDeploy mostly certainly is under maintenance. They wouldn't dare End-Of-Life that product as v7.5 (when released) will STILL not be as good as the v6 product for some4 customers. They are still nowhere near feature parity. So yes... RDeploy is supported, and it has been confirmed that they need to investigate it. Another DS update is due soon, and the one after that will likely support Windows 8. I want that timeline pushed up... by a LOT.

And DS 6.9, under Windows 8, is fine. Same limitations as Windows 7 with regards to locked screens, no logon support, no chat, no file copy, and no UAC prompt (or Office 2007 menus)... but everything else just worked. I could deploy the agent, remote control, send scripts and software packages... everything just worked. Just goes to show you that the focus should be on v6.x and not that shoddy bit of code that is Deployment Solution v7.x.

Seriously, the ONLY thing I can't do is capture the images without the "-RAW" switch.

Quote: "I know not what other much is else. But what other else is there?" - ***** (OP hidden as that was too awful! Lol)

+2
Login to vote
Pascal KOTTE's picture

see also https://www-secure.symantec.com/connect/forums/implementing-winpe-4-altiris-71

We should be able to custom similar for Ds 6.9

~Pascal @ Kotte.net~ Do you speak French? Et utilisez Altiris: venez nous rejoindre sur le GUASF

0
Login to vote
BBC's picture

We're using DS 6.9 SP4 and I have put in place imaging and migration events for Windows 8  couple of weeks ago. The only comment I can make is that we do NOT use Sysprep images and so do not see the majority of issues (obviously nearly) everyone seems to have around here.

I have moved away from Sysprep imaging around 8 years ago when the first CPUs' have hit us where support for Hyperthreading (I believe that was it at the time) us and I had to supply additional Sysprep.INF files, along with corresponding HAL files.

I test the imilar process I have in place on 6.9 against the 7.5 platform and the transition should be a "no-brainer" since we remain indipendent from all these issues.

Again, summarized, I do this:

- DOS PXE boot to deploy a IMG containing a WinPE 2.1 environment; ****

- Boot off that WinPE (RAM loaded on the client and connecting to the local DS);

- Copy over the source for WinXP/7/8 and a corresponding answer file and run the initial unattended setup portion;

- The client is rebooted and completes the Windows setup, where in the answer file, I have a command that eitehr calls a couple of application installs first and last the DAgent install or just the DAgent install.

**** with this part I have a pre-formatted drive, where no OEM partition is in place and I can do whatever I want to the HDD or SSD.

-BBC

0
Login to vote
MurrayW's picture

I totally agree with you on Sysprep... for Windows XP. As soon as I needed to generate a HII deployment process (using Windows Embedded to determine the required HAL and inject the correct files, etc.), it all got too hard. We skipped Vista here, so I don't have too much to say on that, but Windows 7 ROCKS for Sysprep. We do use a very complex deployment process because of this though. Because we deployed W7 prior to official support with ANY Symantec/Altiris tools, we scripted the whole thing ourselves. That makes moving to any other system (or even v7.x) a nightmare.

You imply that you can successfully capture and deploy Windows 8 images. Care to share how? Even if I have an old computer (so BIOS + MBR, not uEFI + GPT), install Windows 8 fresh from the DVD, and then immediately try to capture the image (IMG format also - even without Sysprepping it), I get an error 104 "The volume is invalid". The ONLY thing that works is issuing the "-raw" command, and that takes HOURS to capture the image (and isn't ideal for deployment either).

Just because we're sharing, I'll outline a few of the steps ourimage process uses. I've got a LOT more detail on here (in the form of blog posts here on Connect - just click my name):

  1. Run the Deployment job against the computer. The first task runs on the DS itself. It runs "ReplaceTokens" against my unattend XML file and hooks into an external data source to pull in more configuration infromation for the computer (based on it's DS name).  This includes destination OU, admin passwords, asset group information, location information, etc. Makes changing things for the deployment i.e. the local admin password, a real breeeze.
  2. The next task reboots the computer into our WinPE2.1 boot environment... zero touch (because the client computers boot to PXE first).
  3. We determine the partitions on the system, erase OEMs, reconfigure partitions (i.e. non-destructively create three partitions if two are found - in case we're upgrading an XP box).
  4. We then deploy our Sysprepped IMG file (IMG so we can multicast).
  5. We then fire off scripts that fix the BCD, detect the model of the computer, copy down a driver repository from the network, set up any NIC or MSD requirements for Sysprep, etc., inject the custom unattend file from step 1, generate a custom logon wallpaper (tattooed with computer informaiton), and much more.
  6. We then let Sysprep do it's magic and join the computer to the domain (details and OU provided in the unattend file from step 1).
  7. The process then fires off our custom model-setup script which installs everything in the driver repository (as created in step 5), and then installs DAgent for the rest of the installation steps.
  8. We then use nested jobs (redirects) to step down to more and more granular levels of systems and locations - where they get their printers, software, etc.

Sounds complicated... but it does mean we can have one single image, and deploy it to as many models of computers as we want, in multiple departments, with different requirements... all from a single "Start Now". Process takes a bit over an hour to fully build a system specific to a user. We like this. We need to be able to do this or similar in v7.x before we'll consider swapping it over.

At this stage, I'd be happy to do ANYTHING with Windows 8. Hurry up Symantec.

Quote: "I know not what other much is else. But what other else is there?" - ***** (OP hidden as that was too awful! Lol)

0
Login to vote
LShackleton's picture

I can see where you're coming from with your approach - sounds like it works well for you. However I feel the response is out of place in this thread where we're asking for features we need in our environments.

If I simply wanted to deploy images that weren't sysprepped I would have stuck with the solution i made booting from floppy disks (naturally i can move this to any boot media i choose, and did years down the line) and loading PQDI 4 off the network and pulling down images that way - not spent countless amounts of cash and time investing in this enterprise deployment solution!

For me - the single biggest benefit of moving to DS 6.9 back when we did was the plug-in solution HIIS by Altrinsic. It really took the bulk of effort out of all our deployment and has worked beautifully. If we continue to see complete lack of movement in terms of supporting new OS's and new versions of WinPE I will most definitely be jumping ship (HIIS's successor is available for WDS etc). The simple maintenance of driver library and injection on the fly without any interference has been invaluable and this is exactly why Symantec's partners offered this when they came to tender.

So thanks to whomever created this thread - desperate to hear some news about this. Technology may move fast but Windows OS's only come round once every few years - and as always the Connect community finds a way to "hack in" the functionality we need LONG before Symantec do.

edit: think i may have clicked reply to the wrong post - but nevermind..

0
Login to vote
BBC's picture

This might have been a misunderstanding, I don't use any captured OS that's being deployed to clients as whatever image file. the process is like this:

1. Boot to automation, which is whatever OS you have. If this is not WinPE, then you might have to deploy a WinPE to the client (which is similar to the one you can create with the boot disk creator).*

2. Boot to WinPE (loaded to RAM) - as far as I remember, this is an option you have when creating the automation WinPE.

3. Have the agent connect back to the DS and:

- Copy over the OS source

- Copy over the answer file (unattend.xml)

- Run Windows setup with parameters (I use for Win7/8 the one below)

Setup.exe /noreboot /tempdrive:C /unattend:C:\<YourLocationOfTheFile>\Unattend.xml

Have the client reboot to production and finish off Windows setup.

*Why I use WinPE is simple, I leave it on the client and in case can always boot off WinPE to scan, repair clean, etc. the machine. It's not something I expect from any software vendor to have full support in place for new technologies as technology usually goes fast and somewhat big software companies have to prove their stuff against the technology before releasing it, which I appreciate most of the time.

A bigger complain could be that MAC OS X deployment is moved back again and again. For Windows, there's always a workaround that can be used.

I will post the entire process details once I get time to do so - don't nail me on a date, but I hope to have this done before end of the week.

0
Login to vote