cluberti

Can you take / post a screenshot of what slmgr /dlv shows? I'm genuinely curious as to why it's working, and to satisfy my curiousity (there has to be a reason) would you be able to do that?

Now that the logs are clean and useful, you're hitting this, specifically.

What sysocmgr calls are being made when this happens? Seems like something during setup called sysocmgr.exe against a custom file, although it's been while since I've tried it as well so it's a little hazy. Does this happen during GUI-mode setup, or on first login?

If that was the case, we would see this in a process monitor log of the system - which isn't a bad idea anyway. It should at least show which process is attempting to access the A: drive.

The OEM SLIC license that activates from the BIOS is included in the image that ships with those machines. If you make a new image, it won't contain the SLIC license and thus won't auto-activate. If you have MAK keys from a VL or SA agreement from Microsoft, you shouldn't be using the OEM licenses anyway (they're required to be legal with your SA VL licenses, but they're not to be used to activate machines - your VL MAK keys are). However, if you're just looking to activate the OEM licenses on machines you don't plan on using your MAKs for, there are ways to get the activation backed up - search the forums, it's here.

Windows DLC Media Center 2010 Ultimate Edition is a warez name for the Windows XP SP3 Media Center 2010 Super MultiBootable v3.6 download, which is warez. Violation of the very first rule of the forums. [banned].

1. Sprechen sie Englisch bitte, regel 2.d. 2. Bitte stellen sie nLite fragen in das nLite-forum. 3. Willkommen bei MSFN .

Ah, OK. I think this KB article and/or this MSExchange.org article are what you will need.

Assuming you have a backup of at least the mailbox stores (and maybe even the transaction logs), use the disaster recovery option switch to reinstall to avoid this. http://technet.microsoft.com/en-us/library/bb125070(EXCHG.65).aspx

gpresult /z might be a better option, as it's ultra verbose compared to the others.

You're getting crypt32 errors when validating the signatures on the catalog files with the updates (error is 0x80092004, CRYPT_E_NOT_FOUND). Sounds like perhaps your catroot is screwed up. 1. Open a command prompt and execute the following commands: net stop cryptsvc ren %systemroot%\System32\Catroot2 oldcatroot2 2. Delete all files in %systemroot%\System32\CatRoot\<subfolder> (there can be quite a few) that begin with tmp*.cat to remove temporary catalog files. 3. Back in the command prompt from step 1, execute the following command: net start cryptsvc Reboot, and see what happens.

This was discussed previously here, and a solution (well, workaround) was found:

Well, any version of PE (I would suggest 3.0 from Win7/2008 R2) can deploy Windows XP, but you cannot use the Win7 or Vista PE to deploy it automatically from WDS - you'll need to create your own deployment WIM that WDS will boot to do an imagex /apply to disk of your XP image.

Yes, you cannot deploy a Windows XP image from a Vista or Windows 7 PE image booting from WDS, because setup.exe that it'll call from those WinPE images expect something specific in a Vista/Win7 WIM, but doesn't exist in XP. You'll have to make your own deployment PE to deploy XP, or utilise an MDT 2010 installation on that system (using the LiteTouchPE.WIM) to deploy it.

Honestly, it looks like a flash application served from a PHP page.

Some questions - what OS are you capturing, and what version of WinPE are you using to do the deployment? A boot.wim from a Windows 7 or Server 2008 R2 source has worked fine for deploying everything but XP (and that's because XP WIMs can't be bootstrapped with Vista or Win7's setup.exe, so that's expected).

Note that the attached file is Active Password Changer v 3.0 by a company called Active Data Recovery Software, and it's just a demo (it won't actually do anything other than display data). This post is a violation of rule 1.c. Also, given that you are obviously also user gtejavarma from the IPs and email addresses used, and using multiple accounts is a violation of rule 4.b, consider yourself banned (on both accounts) for obvious failures to read or follow the forum rules.

It'd be pretty easy to do, honestly - export the Vista and Win7 versions you want into a new install.wim (gimagex if you need a gui, otherwise imagex from the Win7 WAIK works fine), and replace the existing install.wim from a Windows 7 source with your new one. Never had a problem with it before, so I'm wondering what exactly you're doing to cause a problem.

He's still alive , and still easily found. He's moved on to other things at the moment, but I would expect no newer versions of his tools anytime soon.

Well, if you're doing this A LOT you might consider a more elegant deployment solution itself that is scriptable and customizable, like MDT 2010. Considering installations seems to be your main function, and it doesn't sound like an environment that would do well with System Center ConfigMgr, using something like MDT 2010 might be a good way to go. The front-end time to set up multiple task sequences (you could use the same Windows XP source for all, keeping the actual file size down) to script different types of installs pays off for hands-off deployment quickly on the back-end once you've done the grunt work, and sounds very much like something you should consider if you do (re)installations as often as you say you do. To list your requirements this meets: One media source - this means a very small deployment share size, likely able to fit on a small (bootable) USB key depending on how many apps you also have to store/install - reduces the number of CDs or DVDs to burn, and USB keys are at least as portable as an external HDD (that you're currently using).Uses WinPE for the front-end for all deployments of WinXP, Server 2003, Vista, Server 2008, Win7, and Server 2008 R2.Has the ability to detect system hardware/HAL in WinPE and provide drivers for the install that match the system (MDT driver management), keeping the actual installation size down as well (only drivers that are required are installed).Given that the "task sequence" that is used to deploy an OS is 100% repeatable every time you use it, you don't have to worry about imaging XP and hoping/praying your batch file skills can deal with hardware/hal differences - MDT produces the same install every time, without resorting to images, but still keeping the deployment share and the ultimately deployed OS as small as possible.It has built-in logging, so if something does fail for any reason, you can see what and why - great when you're building a new task sequence and testing it for the first time (in a VM, of course ).

There are other ways, like using MDT 2010 and driver profiles / driver management.

Yeah, if you're using x64 hosts you're limited to Hyper-V from Microsoft or nothing - VMWare player is fine, and VirtualBox and VMLite are also good choices. There are others, but those are the main 3 outside of Virtual PC.

Happy Birthday Tarun and Incroyable Hulk!!!!!!!!! You're both old , and better for it!

Given VMWare server's EOL is June 2011, I doubt you'll see anything more than security releases going forward - support for Win7 is likely never going to happen there. Your best bet going forward is either the Player or ESXi, but ESXi is a bit steep for just running appliances. Given that Hyper-V server and Virtual PC are free, you could always give those a shot as well, or perhaps VirtualBox or VMLite (not sure if your requirements are having an always-on server VM host or not).

Please be a little more specific - what code do you have, and what specifically do you need help with in developing this app? This isn't a forum for asking people to write something for you, so I want to be sure you're asking for help with your code that's not working (or you need advice, etc).