Upgrading from XP to Windows 7 problems

[ScriptingIT]

This one has been entertaining me for days...

 

We like to use our own systems for Windows 7 rather than SCCM/MDT for some clients as we add a lot of features and can hand it over with less training.

Still there is an issue when rebuilding XP machines to Windows 7 (trying to do this the way we currently rebuild XP to XP).

 

Like my other post on this site we set an XP machine to boot from a CD ISO then reboot and from the CD image drop down the WIM, provision/move the Comp AD account etc.

 

Issue1: You cannot use a PE3.0 ISO to boot XP from the local ISO (the boot from local ISO loads the ISO into memory but 3.0 ISO actually contain the WIM which they then load to memory so that does not work)

 

To solve this I just created a good old PE2005 ISO which maps to the netork and kicks off the process. I changed all the logging to a network share (as there is no ability to write to X: in PE 2005).

 

Issue2: If I Diskpart and Format the disk in PE2005 then load my WIM and reboot it gives me "NTLDR is missing" as in the MBR is XP because we Diskpart with PE2005 even after dumping down our WIM. I noted that BCDEDIT seems to run fine from PE2005 so I did an export on a PE3.0 CD (post diskpart/format/wim drop) and tried to import that under PE2005 post diskpart/format/wim drop. It said "success" but still gave NTLDR missing.

 

Any ideas on this one would be nice. What we tend to do is create a SMS job that sets the remote machine to boot from the local ISO then reboots it, the iso does the rest. Sadly here I either cannot boot the PE3.0 ISO this way or cannot format the disk to suite Win7.

 

I did try running the later Diskpart under PE2005 but it does not want to run it (invalid 32bit application).

Any ideas would be good or I'll post back once I crack it.

[anyweb]

are you saying with issue 1 that you cannot boot winpe 3 ? i'm not following you exactly...

[ScriptingIT]

All fixed now!

 

Issue 1 is you cannot copy a WinPE3.0 ISO (generated using the WAIK) to say C:\MyIso.iso on a Windows XP machine and get that machine to reboot to that ISO (like you can with older WinPE2005 iso's using the process I described in another thread on this site). That is because the new ISO's are actually just wrappers that load a WIM into memory and the method we use actually loads the ISO into memory (hope that makes sense).

 

The second issue is if I use an old PE iso that does work (I can boot from the local ISO as normal) but Diskpart and Format create a NTLDR boot loader. I tried running the later DiskPart but it does not work under PE2005. I tried Bootsect.exe but it gave errors also.

 

In the end I copied the new PE3.0 System32 dir to a network share and from the PE2005 (which maps M: below that share) ran Bootsect.exe and it worked and set the bootloader to NT60. Now it all just works again.

 

What does this mean? It means I can deploy our system from SMS2003 or any deployment system and it can rebuild XP to Win7 remotely without having to pay for SCCM cals, add mac addresses to databases, set machines to PXE boot as the first option etc, etc.

 

We are AutoIT lovers so from PE2005 (again booting to that ISO from the local C:\ in XP) like this:

 

Map M from PE2005

 

RunWait(@Comspec & " /c " & "diskpart.exe /s M:\scripts\diskpart_pe.txt",@TempDir,@SW_HIDE)

RunWait("cmd /c Format c: /fs:NTFS /v:""CDisk"" /Q /Y",@TempDir,@SW_HIDE)

sleep(1000)

RunWait("cmd /c m:\Tools\CDTools\PE32Dir\bootsect.exe /nt60 /f c: >> c:\temp\ScriptingIT\BootRect_Log.log","m:\Tools\CDTools\PE32Dir\bootsect")

 

Run ImageX and drop down your Win7 Wim

Copy down the drivers for that model (and hardware based installs etc)

Inject them

Update the XML

Drop in some non-base optional apps etc

 

Much as I like SCCM not all our clients have it or plans to have it but they want to deploy Windows 7. Even where we do have SCCM I still tend to use our system because its easier for all concerned (NZ not all clients have a SCCM expert about our stuff is really simple to drive). Also we can send driver zipped packs to clients they just pop them in a DIR and ZAMMO another supported model etc.

 

We can still use WDS if needed and all that but we are free (insert manic laughter here) from CAL's and mystically knowing MAC addresses of new machines etc.

 

Having said all that SCCM is still pretty cool and the guides here made is MUCH more useable for me (and I live in it at times and date back to BDD2.5). SO APPRECIATE the time you've spent! Makes me want to contribute more.

 

If you have never booted XP from a local ISO check out the other thread it is really quite useful at times (or in our case all the time on various sites).

 

are you saying with issue 1 that you cannot boot winpe 3 ? i'm not following you exactly...

[anyweb]

well i'm sure what you are doing makes sense to you but seriously if you want to ease your own pain then look at MDT 2010 using task sequences so its EASY even for a customer, it will do all of those things and more for free, much less need to script things and hack isos/winpe.

 

SCCM is just the icing on the cake and well, then some

 

cheers

niall

[ScriptingIT]

Did you read my post?

 

We work a lot with SCCM and MDT, and as stated provide and manage solutions using both. When you get familiar enough with a product its common to start seeing it as really EASY. Its OK, I guess (they all are if run well). If you know your stuff and your clients though you can make life for them and yourself much simpler again. I'm not selling anything but I think I've enough experiance of the various technologies to still have an opinion. SCCM is just a framework, not the second coming. It is easy for us, we make it easier for our clients. Do you work for MS?

 

 

 

well i'm sure what you are doing makes sense to you but seriously if you want to ease your own pain then look at MDT 2010 using task sequences so its EASY even for a customer, it will do all of those things and more for free, much less need to script things and hack isos/winpe.

 

SCCM is just the icing on the cake and well, then some

 

cheers

niall

[anyweb]

no I don't work for Microsoft, I work as a Technical Consultant for Logica,

 

my point is simply this, why re-invent the wheel when there are solutions out there already, plus any custom solution you figure out will only be supported by you and no one else,

[ScriptingIT]

I'm not sure which assumption to deal with first. We are a team with plenty of redundancy and our client get handover so most (not all) have internal people who can operate the solution.

We are not re-inventing the wheel as the wheel you refer to is more a wheel template. That wheel template in fact does not do many things we (and our clients) need and therefore we created a wheel that does.

 

Rather than buy just some software template you can by support from us and we can use and BDD and up light touch, SMS or SCCM. But if you want all some of the feature that solution does not have or cannot easily be adapted to give that ours can we have our toys also.

 

Our toys can leverage any system and work with it or work on their own. You can leverage us and well run whatever it is or casually consult etc. I'm not selling mind we are nicely at capacity and taking on work as we can manage it (not much point marketing).

 

Large companies tend to operate in small groups at the client coal face. We are just like one of those groups focused on SOE, packaging, deployment, etc.

 

Clients tend to be 400 - 4000 space for us but really it makes little difference for deployment and even SOE (few more apps, big deal). I try not to get owned by a solution mind.

 

I'm not sure if I'm being difficult or if you are unreasonably focused one a single technology when the outcomes of SOE and its management are more diverse than one solution can hope to offer (unless you can touch the dev team, have them on contract and order up some new 'toys for less').

 

Oh and don't get me started on the logging of all those systems, where SCCM stores packages by default, how slow the interfaces are, etc, etc, etc.

 

I thought in fact your troubleshooting page (just for your reference one) was a poster child for how bad logging and troubleshooting MDT/SCCM/WDS etc really are (I know I've started). Still we design, build and manage them and keep them working. I forwarded to some of my team mentioning how good your guides are and how amusing that page is (we can all relate to it).

 

More and more I am of a mind to replace it (SCCM) with something simple (I mean 4000 clients is not a lot and its not spread across the USA). I don't see anything simple so we created our own. It actually is simple. Thanks not an assumption, I've seen it and we work with both. It is all about client needs and not a specific technology. In this space that is the last of their troubles because they all work or they would not exist.

 

Hope that explains it. ScriptingIT world famous in some parts of New Zealand.

 

no I don't work for Microsoft, I work as a Technical Consultant for Logica,

 

my point is simply this, why re-invent the wheel when there are solutions out there already, plus any custom solution you figure out will only be supported by you and no one else,