dexter.inside

Actually the logon screen in Server 2008 is more like the lack of a logon screen. There are only resources for the Vista logon screen. The blue background is rendered behind both of them.

Think of it as linux packages - you either want it or you don't. But you need to know what it does before you decide, and that's your responsability.

If that debian distro can run from FAT32, you could probably capture it to a WIM and add it to the WDS.

That's because it is being enforced from tokens.dat. On Vista/Server 2008 there's no GINA anymore for us to tweak like that.

It would save you a lot of trouble to add the drivers in the image and then multicast it from your WDS.

AFAIK there's an option in the WDS configuration pages for that.

shell32.dll,-21799 looks like a resource that is trying to be used from an invalid CLSID (probably with garbage in InProcServer). I think it's the Common Desktop shell extension. Have a look in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{C4AA340D-F20F-4863-AFEF-F87EF2E6BA25}

I believe you have 2 alternatives: 1) try to mark it as persistent (via the persistence attribute) in System Image Manager from AIK, or 2) take Vista into mini-setup without running sysprep and make a script to clean the driver classes you want to generalize.

What is that service, what are its dependencies and what messages did it leave in the event viewer?

There is a delay being forced on the system when certain drivers receive a "install veto". Unfortunately, it is not a documented behavior. I provided once ~ 2 GB of drivers and it took sysprep about 3 hours to reseal that machine due to this issue. Have a look in the sysprep logs and in the event viewer afterward.

Same problem here, DEP crashing my Huawei 3G modem software.

Actually this is a very serious topic subject, I had the same problem over and over again with my redists. I'm still involved in the legal (or not-so-legal) issues of making something similar open source.

I'd say the simplest way would be to make your own - sysprep the installation, capture it and replace the install.wim from the retail disc. Quite obviously, OEMs would make their custom recovery/backup environments harder to reverse engineer than the default vanilla Vista.

Just like the way you can split the installer on several CDs, you can have a WIM split into 2 and make a 2-DVD installation. None of the parts is larger than 4 GB and you won't have to use a dual layer blank.

Quite simple, actually. First, you get the MSU stored as-is in the image, then uncompressed in WinSxS, then preinstalled in the actual windows folders and probably some other places in different ways that the single instance storage algorithm can't cope with.

Update: for those that encountered the FLDRCLNR.DLL error in mini-setup, here is the solution: http://support.microsoft.com/?kbid=832978 And it is not caused by nLite.

Btw, I have a better idea... Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\Setup] "SetupType"=dword:00000001 "SystemSetupInProgress"=dword:00000001 "CmdLine"=hex(7):73,00,65,00,74,00,75,00,70,00,2e,00,65,00,78,00,65,00,20,00,\ 2d,00,6e,00,65,00,77,00,73,00,65,00,74,00,75,00,70,00,20,00,2d,00,6d,00,69,\ 00,6e,00,69,00,00,00,00,00 "MiniSetupDoPnP"=dword:00000001 "MiniSetupInProgress"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager] "SetupExecute"=hex(7):73,00,65,00,74,00,75,00,70,00,63,00,6c,00,2e,00,65,00,78,\ 00,65,00,00,00,00,00 Skip sysprep altogether and apply this reg. It will get you back to mini-setup. The nasty part was to discover "MiniSetupDoPnP"=dword:00000001 , which AFAIK is undocumented.

I've got Vista SP1 , VS2008 Team Edition and Photoshop CS3 on my 4GB 701 and it works satisfactory. Server 2008 did just as well.

I've been getting quite close on a new approach of servicing drivers into images, by bypassing sysprep altogether and running the mini-setup manually. Unfortunately it's both tricky to perform manually (very complex procedure) and difficult to implement properly as code in my app. Hope to get a workable engineering sample soon, as I've overcome the "legal" aspects I'll keep you posted.

Might as well be running it on eeePC

Quite normal, if you have a SCSI/SAS drive in the VM and no mass storage driver for it. XP usually goes with BusLogic and Server 2003 with LSI As for the disks, they are not mine, I've used the deployment server at work for the tutorial. My employer wouldn't be very happy if I were to share their MSDN subscription

That means either your image is corrupted at editing or setup is incompatible with that WIM API. Have you tried booting from a live cd and applying your image manually with ximage onto the target partition to see if it works?

Are you using sysprep -bmsd to populate sysprep.inf ? Try this to make sure it's not something else causing it - in HKLM\SYSTEM\Setup add or modify: Cmdline:REG_SZ:setup -newsetup -mini MiniSetupInProgress:REG_DWORD:0x1 SetupType:REG_DWORD:0x1 SystemSetupInProgress:REG_DWORD:0x1 and HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SetupExecute:REG_MULTI_SZ:setupcl.exe (according to http://support.microsoft.com/kb/321070) This should run mini-setup without driver detection. If this fails, you should post the last stuff that failed in the setup log. If it doesn't, you are not building mass storage driver list properly. If you have extra steps to perform (related to drivers) or you need to bypass completely the windows mini-setup driver detection (like driverpacks), append it in the REG_MULTI_SZ after setupcl.exe Hope it helps. It did for me.

That's not much, that's quite small actually

That probably being VMware Server 2.x running on top of IIS 7 Core