razormoon

@ECHO OFF SET DriversRoot=NULL :SearchDriversRoot FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y Z) DO IF EXIST %%i:\DriversRoot.txt SET DriversRoot=%%i:\ IF NOT "%DriversRoot%"=="NULL" GOTO StartSetup GOTO SearchDriversRoot :StartSetup ECHO DriversRoot=%DriversRoot% X:\setup.exe SET DriversRoot=%%i:\ Should NOT contain the trailing slash, otherwise DriversRoot = X:\\ SET DriversRoot=%%i: CORRECT Where DriversRoot equals only the drive letter (and colon) where your drivers are stored. So...pointing to that directory should be: %DriversRoot%\Drivers Now what I don't understand is why the reason for the GOTO SearchDriversRoot loop. FOR %%i should take care of this and run through the letters by design, no?

Vize .5. I'm running Ultimate SP1 with similar errors: ************** Exception Text ************** System.NullReferenceException: Object reference not set to an instance of an object. at Vize.MainApp.GetFilesToBeProcessed(WorkerPages page) at Vize.MainApp.ButtonPatch_Click(Object sender, EventArgs e) at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnClick(EventArgs e) at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ButtonBase.WndProc(Message& m) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ************** Loaded Assemblies ************** mscorlib Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1373 (REDBITS.050727-1300) CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll ---------------------------------------- Vize Assembly Version: 0.2.0.0 Win32 Version: 0.2.0.0 CodeBase: file:///C:/Program%20Files/XPero/Vize/Vize.exe ---------------------------------------- System.Windows.Forms Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1373 (REDBITS.050727-1300) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1373 (REDBITS.050727-1300) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Drawing Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1373 (REDBITS.050727-1300) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- VistaControls Assembly Version: 1.0.0.0 Win32 Version: 1.0.0.0 CodeBase: file:///C:/Program%20Files/XPero/Vize/VistaControls.DLL ---------------------------------------- System.Configuration Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1373 (REDBITS.050727-1300) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll ---------------------------------------- System.Xml Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1373 (REDBITS.050727-1300) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll ----------------------------------------

NUJA... This may sound like a strange solution, but try moving the order of that particular program up or down your install list. For instance, let's say I run 5 app installs in unattend mode: Messenger MS Money Acrobat Reader Office Winrar Using this as an example, I've encounter the error you are having. I've had this issue with several apps, Acrobat Reader being one of them (and notoriously so). However, when I moved the order around (and it takes time to get it work!) I find that the error disappears. Messenger MS Money Winrar Office Acrobat Reader or Winrar Acrobat Reader MS Money Office Messenger etc Try different positions on the install order with the program in question (Jump2reg being yours) and you'll eventually come to a pattern that works. One "quick" way to find out if this will work for you is to build an unattend with ONLY JUMP2REG and see if it installs properly.

maxxp just explained dos command above: cmd /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f oh, oops...you wanted run once... REG ADD "HKCU\Software\Microsoft\Windows\CurrentVersion\Runonce" /V Install /D "Cmd /C Start %systemdrive%\Install\batch.cmd /S /Q" /f

Have you noticed which tweaks are making it through? I bet it is only the HKLM. You must be fully logged on in order to run the rest through as the pc is in Local Machine mode. Either somehow call a cmd AFTER logon, or merge your tweaks during audituser/sysprep pass. Maybe add a long pause command in your firstlogon.cmd, long enough for your account to fully log on? I don't know as I haven't tried.

Well, I've never been successful at using $OEM$\$DOCS\<USERNAME>. My workaround for this is using a cmd file with copy commands such as: @echo off Color 0A FOR %%i IN (C D E F G H I J K L N M O P Q R S T U V W X Y Z) DO IF EXIST %%i:\Autounattend.xml SET AppsRoot=%%i: CMD /C XCOPY %APPSROOT%\MYFILES %USERPROFILE%\DOCUMENTS\ /E /H /Y END As for your regtweaks...adding them using setupcomplete.cmd I believe tells regedit that you are in machine mode so I think that only HKLM entries are processed. You're better off running a cmd AFTER logon. And I don't think firstlogon.cmd would help you.

Are you sure you have defined your security policies in \Windows\Security? Checked all the necessary options? If so, did you inject into install.wim and made a call to secedit from setupcomplete.cmd? I've heard of some users having trouble with the setupcomplete.cmd method. What you can do is move that call from the setupcomplete.cmd and put it in your autounattend.xml as such in <settings pass="specialize">: <component name="Microsoft-Windows-Deployment" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <RunSynchronous> <RunSynchronousCommand wcm:action="add"> <Order>1</Order> <Path>CMD /C secedit /configure /db %systemroot%\security\database\unattend.sdb /cfg %systemroot%\security\templates\unattend.inf /log %systemroot%\security\logs\unattend.log /overwrite /quiet</Path> </RunSynchronousCommand> </RunSynchronous> </component> In the meantime, I'll just edit the above to make the call from autounatted.xml as opposed to setupcomplete.cmd. EDIT: THE ABOVE DOES NOT WORK FOR ME SO REVERTING ORIGINAL POST TO SETUPCOMPLETE.CMD

Depends which desktop you would like to copy to. Use %PUBLIC%\DESKTOP\ for all users Use %USERPROFILE%\DESKTOP\ for current user COPY /Y SAMPLE.LNK %PUBLIC%\DESKTOP

I have NEVER had a coder respond so fast! More than happy to help xpero.

XPERO I too am encountering the unusable os situation. I've had to reinstall quite a few times just trying to get it to work. No luck. I notice that when Vize is done patching it says done with errors as link. It seems that every patch fails. I tried quiting the app and restarting it hope that it will let me restore the files. I can't even run system restore before booting Vista into unusable limbo. The problem is that your app offers no recourse, so you're pretty much screwed as Vista gives error message with missing Logonui.dll, shell32.dll and so on, rendering my pc useless. I've used v0.2 with no issue. Problem is that I erased it. Can you make the app recover before reboot? If all patches did fail, I just don't understand why it erases all those needed dlls?

Simple answer: Add the following two lines to YOUR CODE above: <OOBE> <HideEULAPage>true</HideEULAPage> <NetworkLocation>Home</NetworkLocation> <SkipUserOOBE>true</SkipUserOOBE> <<<<< This <SkipMachineOOBE>true</SkipMachineOOBE> <<<<< and this <ProtectYourPC>3</ProtectYourPC> </OOBE> Another problem you may have is that you have not set "Show Administrator on logon screen". Very important that you enable! See here!

I've never tried the directories I use in XP, however yours seem to work across both platforms. I think your method is headed toward what MaxXP was aluding to (aka: Junction Point). As he stated, this is being phased out.

Interesting. I've been using first post directories and it works fine. It's interesting to know that *legacy* works also. So, we now have two methods.

Like I said. Tested and working. I have not seen a Documents and Settings shortcut. The directory I've provided is a link to \Users. If you haven't tested the above directory then I can't explain any further. During UA the $OEM$\$DOCS does not behave as junction point. It is not virtual nor hidden as Documents and Settings. Like I said before, if you haven't tried it yourself as described above, then I see no reason to explain any further. It is what it is and it works. If you're trying to explain how Documents and Settings behave, especially on a programmer's side, then we have gotten away from the scope of my original post. Test and you shall see. Tic 'Show hidden..' and you tell me if you see Documents and Settings.

jaws75 Thanks for the great tip. It's just like mmc and secedit. Fantastic tip! Could be used in conjunction with above link!

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

It is absolutely possible to copy files via $OEM$ directory into any user directory in \Users (Documents and Settings in XP). It took a bit of experimenting, but the root of X:\Users\ = $OEM$\$Docs\ Also, if in Folder Options you tic "Show Hidden Files", you can navigate X:\Users and explore where Start Menu and Quick Launch is located. I add a lot to Default User during Vista Unattend and the above directories are located here: Start Menu $OEM$\$DOCS\DEFAULT\APPDATA\ROAMING\MICROSOFT\WINDOWS\START MENU Quick Launch $OEM$\$DOCS\DEFAULT\APPDATA\ROAMING\MICROSOFT\INTERNET EXPLORER\QUICK LAUNCH\ We are told in Technet and .chm that this directory is NOT supported in Vista. Not true. These are tested and WORKING. Enjoy!

Well let's pass more of the right stuff. Take it from someone who currently employs the above directory. Unless I have a faulty copy of Vista Supported in Vista = Yes Don't believe everything .CHM tells you. Just trying to help you Wabaunza. The path I related is Vista specific and works for me. One directory I create for an ebook I use in Start Menu >> All Programs >> Property Book is $OEM$\$Docs\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Property Book\ and it applies to all users. Let us know how it turns out.

@Wabaunza Have you tried your own suggestion? $OEM$\Docs\Default User is incorrect. It should be $OEM$\$Docs\Default. Also. you can manipulate files in INSTALL.WIM.

Not so bad. Injecting into install.wim works fine it just takes a little more time...

$OEM$ folder method tested and not working.

In Azalia case it's the other way around. The install won't work in Vista so it must be bypassed with drivers added manually. Sorry 'bout your on board sound though...

Well golly Gosh a simple HKLM key would suffice. Eh, post and learn. And much obliged for the tip.

No, no. Definately rebuild. But I'm thinking if you're using 1.1beta and it's only leaving the wims then it's good news for me and I just have to figure out what I'm doing wrong.

Anyone know the tweak for restoring open folders at login for Vista? I've been checking around here but can't find a thing!