Windows 7 Running bootrec/scanos in 32-bit WinPE to detect 64-bit offline Win7

[rjatech]

Esteemed ladies and gentlemen,

I have a 32-bit WinPE into which I have integrated MSDART tools and some 3rd party remote control software as well as some utilities provided by a vendor which supports our hard drive encryption solution.

The long and short of it is that there are occasions in which we need to manage the offline OS and reset the Admin password (its supposed to be randomized and managed by yet another 3rd party, who has fallen woefully short in their obligation to provide a quality product). Since my 32 bit WinPE is based on 32 bit MSDART which is built off a 32 bit Windows 7 OEM ISO, the 32-bit recovery utilities (such as Locksmith) work fine. However, if the offline OS is 64-bit, and i boot to my 32 bit WinPE, the full features of MSDART are not available since it has to run the bootrec/scanos first in order to detect the offline OS.

At this point, we are now deploying mostly 64 bit WIndows 7 enterprise, and my WinPE is losing its effectiveness. If I build a 64 bit WinPE based off a 64 bit MSDART and 64 bit Win7 OEM DVD, it WOULD work, except the hard drive is encrypted, and the utilities provided by our encryption vendor are all 32 bit (we have submitted a request for 64 bit drivers but they do not have any nor do they see a need to provide them) so i can't unlock the drive.

That hopefully answers the 'why' of 'why am i doing this', but the main problem i have at this point is to find a way to run bootrec inside a 32 bit WinPE to detect a 64 bit offline OS. I tried extracting the 64 bit bootrec from 64bit MSDART and the 32 bit WInPE obviously has a problem with this.

Can anyone recommend a way to detect a 64 bit offline OS using a 32 bit version of bootrec inside of a 32 bit WinPE ? My hope is that if it detects the offline OS, then the 32 bit MSDART version of Locksmith will run. Maybe, maybe not, but we have to start somewhere.

Thank you for any consideration you give this.

 

[Josephur]

If your vendor is doing hard drive encryption and can't offer a seamless 64-bit upgrade path, its time for a new vendor, or to use Windows based encryption which you can control via your own domain/server.

I'm not sure why your vendor cannot offer you an inf based driver that you can load into the 64-bit WinPE when you create it using MSDaRT that will run and at least allow access to the files...

FYI Windows PE 4.0 or later supports encrypted drives (BitLocker).

 

[rjatech]

Well, the encryption software does install on 64-bit systems, its the WinPE they provide which does not have 64-bit drivers to facilitate the bypassing of encryption within WinPE. That environment contains some tools for importing an encrypted MBR as well as bypassing encryption in order to interact with an encrypted offline OS. That part works, because the WinPE is 32 bit. However, their 32 bit drivers do not work inside a 64 bit WInPE, which is needed to successfully run MSDART tools on a 64 bit offline OS inside WinPE.

We will be moving to Bitlocker eventually, but 8,000+ PCs will still have our old encryption (Sophos), which if previous experience is any indication (we went from Pointsec to Sophos, and it was 3 years+ before old assets disappeared through attrition) we will be supporting it for quite some time to come.

I suspect what i want to do isn't possible, but i just wanted to be sure i'm not missing something. I guess if i knew the dependenices that bootrec had, i could export the right files from the 64 bit MSDART but that might be a bit far-fetched, or just take tons of trial and error.

Something else that might be helpful to know,,, can anyone recommend a standalone password changer? One that doesn't need to be booted from? I know there are linux based tools but they seem to require that you boot into the linux shell from an iso and then interact with the offline OS, which won't work on an encrypted hard drive obviously.

 

[Josephur]

One that doesn't need to be booted from?... If you're in a business environment then why aren't these machines on a domain so that passwords are a moot point and controlled by your domain controller?

If you're using a local account for all users to login with on 8000 PCs, and you don't have a common Administrator password in which to reset the users passwords. that's just insane!

 

[rjatech]

These PCs are on a domain. Sadly we have had multiple problems where the trust relationship is broken and the PCs are off domain. Then, our only mechanism is logging in with either cached credentials (works sometimes) or local admin accounts (works almost never).

We used to have common Admin passwords, but switched to a 3rd party solution for randomizing local admin account passwords (see: Enterprise Password Vault by CyberArk). There are instances where that password isn't managed properly, assets are off domain, and no one can log into them, so that's why I built a WinPE with our encryption vendor's tools plus MSDART utilities plus remote control abilities. Then i can remote in, bypass the encryption, and then use Locksmith to manage the admin password.

Until 64-bit came along. The password issue aside, i also use this as a platform for startup repairs (yeah i can still manually repair BCD etc) and system restores, which MSDART is great at.

 

[Josephur]

If you're having trust relationship issues it's time to get them fixed. Even if you have to hire an outside consultant to help you troubleshoot issues with Active Directory, with that many PCs on your domain it would be worth it. Probably not that hard of a fix either. There's no way I would administrate 8,000 PCs without a proper domain running, your just asking to spend extra valuable time and money on issues all the time.

Once fixed you can easily create a local admin user on each PC that is uniform, and reset passwords using Active Directory with no issue. All without having to go to each PC, as it should be.

 

[rjatech]

Unfortuantely I am on the support end of things, and not on the administrative. Fixing issues at the domain level is beyond the scope and expertise of my current position. I am limited to fixing things at the workstation level, and thus have developed my own tools to facilitate those fixes.

Back to my original issue, does it make sense? Does it seem feasible?