VMWare Quirk with OOBE

[Drusenija]

I've only just started making my first unattended disc a couple of weeks ago. I've almost got it to a point where I'm happy with it (although I still have a list of software I want on it ^^), however I've had an issue with creating users.

I originally used the 'net user' method, and it was working okay, however a lot of the HKCU registry keys were getting added to the Administrator account, not the account I had created. So I tried out the OOBE method. However, the user I specified was never being created, and as a result the only account being created was the Administrator account. I tried a ton of different combinations of switches, but nothing I did seemed to work.

So, last night, I downloaded the Virtual PC 2004 trial, and tried running my UA disc through that. My OOBE stuff worked perfectly, and I had my single user automatically logging on.

After some thought, I _think_ I know why it was happening (love some feedback though). I remember reading somewhere that if the display can't be set to a minimum of 800x600x16 automatically at startup, that the OOBE process gets skipped (when it's set to be done through the oobeinfo.ini file).

In any case though, I know now that the OOBE stuff does actually work, so I'm happy about that! But I thought I'd post this up here to help anyone else out who's been having a similar issue with OOBE stuff. I've included my winnt.sif file and oobeinfo.ini file as well as a reference.

winnt.sif

[Data]
	AutoPartition = 0
	MsDosInitiated = 0
	UnattendedInstall = Yes
	AutomaticUpdates = Yes

[Unattended]
	UnattendMode = FullUnattended
	UnattendSwitch = Yes
	OemSkipEula = Yes
	OemPreinstall = Yes
	OemPnPDriversPath = "..."
	TargetPath = \WINDOWS
	FileSystem = *
	WaitForReboot = No

[GuiUnattended]
	EncryptedAdminPassword = No
	OEMSkipRegional = 1
	TimeZone = 255
	OemSkipWelcome = 1
	AdminPassword = *
	AutoLogon = No

[UserData]
	ProductKey = xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
	FullName = "..."
	OrgName = "..."
	ComputerName = *

[Display]
	AutoConfirm = 1
	BitsPerPel = 32
	Xresolution = 800
	YResolution = 600

[TapiLocation]
	CountryCode = 61
	Dialing = Tone
	AreaCode = 03

[RegionalSettings]
	LanguageGroup = 1
	Language = 00000c09

[Branding]
	BrandIEUsingUnattended = Yes

[URL]
	Home_Page = about:blank
	Search_Page = http://www.google.com.au/

[Proxy]
	Proxy_Enable = 0
	Use_Same_Proxy = 1

[GuiRunOnce]

[Identification]
	JoinWorkgroup = SHAKARI

[Networking]
	InstallDefaultComponents = Yes

[Components]
	msmsgs = on
	msnexplr = off

[Shell]
	DefaultStartPanelOff = Yes

oobeinfo.ini

[UserInfo]
Identity000 = "Drusenija"

[Galath]

I am running into the same problem. Does setting your password to something other than default hault the unattended setup? I am thinking that has something to do with the administrator name not changing.

[Drusenija]

Which problem do you mean Galath? Cause if it's the same as the one I just detailed I already provided a solution ^_~ Just a few things with the OOBE stuff though, the OEMPreInstall setting must be set to Yes, and I think AutoLogin needs to be no, to ensure the Administrator account doesn't get used first up. And I don't think you'll have any problems specifying an actual password for the administrator.

Now, just some more information on my original problem. I discovered why VMWare has issues. My suspicions were right. You need the VMWare display driver in order to get OOBE working (since it doesn't work when your display is 640x480 and without that driver you can't get anything above 640x480 anyway). So after putting those drivers into my OemPnPDriversPath in winnt.sif, OOBE now works correctly in VMWare!

Here's some reference posts that explain the problem for anyone else who is experiencing this:

http://www.msfn.org/board/index.php?showtopic=23429&st=20

http://www.msfn.org/board/index.php?showtopic=24156

[kof94]

Remove this

[Unattended]
UnattendSwitch = Yes

It skips the first gui and logs on as local Admin by default.

Edit oobeinfo.ini if you want to mod the first gui. It can create users aswell.

Don't bother to use $OEM$ folder for it (it's not very reliable) just edit the one in your i386 folder and re-cab (makecab.exe) it. Why mess about when you can go to the source!

Read your ref.chm from the Windows Support folder on your disc for some extra info on oobeinfo.ini.

Hope this solves your prob

[Drusenija]

(Firstly, sorry for both digging this up a week later and responding so late, I've had some trouble getting net access the past week!)

kof94, as I said in the second post, I've actually gotten this method working already ^^ The problem was if setup can't set the display to 800x600 (say when you don't have a display driver available), the automated OOBE process is skipped. Adding the driver to my winnt.sif file fixed the problem, so I can still have "Unattended = yes" and have the process work.

As for why I have oobeinfo.ini separate rather than just recabbing it; I'm using XPCreate to make my CD right now, so my initial 'source' is a clean, untouched WinXP CD. In other words, I'm happy with how it works now ^^

[simcam68]

@Drusenija

I've done what you had suggested with getting the drivers out of the VMware folders and put them in the $oem$\driver locations. Also added all the OEmPNPdriver stuff too. But still doesn't work for me. The drivers are copied to the system32 folder on the VM machine and can be installed by clicking "update driver" on the display adapter, but windows did not install them during setup.

I also modified the .inf for the driver like suggested so the resolution would be where I want it. But no luck. I have basically done all that you did but it doesn't work. It worked one time for me on the very first install into the VM machine, after that, no go.

I'm very frustrated with this, been working on it for days now..... I'm going to try net user method right now and see what happens.

Any other ideas for the oobeinfo way???

Thanks, Sim