Jump to content


Photo

Create your own Autounattend.xml All-In-One (x86/amd64)


  • Please log in to reply
148 replies to this topic

#81 Escorpiom

Escorpiom

    Member

  • Members
  • PipPip
  • 38 posts
  • OS:Windows XP Pro

Posted 10 June 2012 - 09:42 PM

Yes, but when using a blank password you can take out this:

<AutoLogon>
<Enabled>true</Enabled>
<Username>Paul</Username>
</AutoLogon>

And you could add these in OOBE:

<ProtectYourPC>3</ProtectYourPC>
<HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>

In other words, setting "skipmachineoobe" to true does not mean these setting will be skipped, they will be processed.
Everything else looks great!

Cheers.

#82 bphlpt

bphlpt

    WinCert Dominator

  • Global Mods
  • 1,170 posts
  • OS:Windows 7 x64

Posted 11 June 2012 - 09:12 AM

...
- If you don't want to use a key, it is possible to set "skipmachineoobe" to "true". I know it is not recommended by Microsoft but it allows me to install any Windows edition with one Autounattend file while retaining the 30 days trial period. It is necessary to specify the other parameters like user account creation and such. Note that this doesn't work for DVD installation method, as you need to choose the Windows version.
- Disabling UAC from the Autounattend.xml didn't work, I had to put some registry settings in firstlogon.cmd. I guess it has to do with the "offlineservicing" setting, as I use another installation method (NT6FastInstaller) this would not be "offline".


Escorpiom and myselfidem - It would be really great if we could come up with appropriate settings that would accomplish these in all cases, ie have a truly universal AutoUnattend.xml that would work as intended for both DVD and USB installation methods and hopefully for all the most popular installation tools including Win Toolkit, WinNTSetup, WinSetupFromUSB with GUI, RMPrepUSB, NT6FastInstaller, DX WinNT6.x True Integrator, and any others I've forgotten including plain vanilla installs using nothing but MS tools and methods. Possible, or just wishful thinking?

Please feel free to list all other OS installation tools anyone is aware of that the Autounattend.xml might be used with. It would be nice to have them all listed in one place. Note also that I have not used all the tools I listed above so if I listed one that has nothing at all to do with Autounattend.xml please let me know.

Cheers and Regards

Edited by bphlpt, 11 June 2012 - 09:22 AM.


#83 Escorpiom

Escorpiom

    Member

  • Members
  • PipPip
  • 38 posts
  • OS:Windows XP Pro

Posted 11 June 2012 - 10:09 AM

In that case the only setting left for a DVD install is the Windows version to install.
There is a file on the dvd that defines the windows version "ei.cfg" but probably, if the Autounattend file is present ei.cfg will be ignored (not sure about that)
So that would require to set the Windows version in the Autounattend.xml, making it not universal.

Everyone has his or her way, as said before I'm using a modified NT6Fast installer, the advantage is that it skips the WinPE pass.
ImageX will extract the wim index I choose to the harddisk, create boot menu and bootsector and copies the autounattend file to the windows\panther folder and firstlogon.cmd to c:\install folder.
That takes about 4 or 5 minutes, only when rebooting the autounattend.xml will get used. This method is universal for all editions, both x86 and x64.

On a side note, I modified the NT6Fast installer to do the partitioning and have included a XP universal .wim image, so I have only one script that can deploy many OS the unattended way.
bphlpt, did you look at the test batches I made? Did I get it right this time?

Cheers.

Edited by Escorpiom, 11 June 2012 - 10:12 AM.


#84 myselfidem

myselfidem

    Wincert Addict

  • Members
  • PipPipPipPipPipPip
  • 598 posts
  • Location:Suisse
  • OS:Windows 7

Posted 11 June 2012 - 10:39 AM

There is a file on the dvd that defines the windows version "ei.cfg" but probably, if the Autounattend file is present ei.cfg will be ignored (not sure about that)

If we want choose the Windows 7 AIO Edition image to install ; we must remove the ei.cfg file!
You can open ei.cfg file with notepad to read the desciption about Windows. If we keep this file only ONE Edition can be installed!


@bphlpt
We must select keyboard layout and language inside Autounattend.xml file, we can't make an universal Autounattend.xml file, but we can adapt the values to suit your needs!

However, here is an example, using Escorpiom values, and Admin as account!
Spoiler

I will add this example inside SetProductKey.rar soon!
Regards

Edited by myselfidem, 11 June 2012 - 08:31 PM.


#85 bphlpt

bphlpt

    WinCert Dominator

  • Global Mods
  • 1,170 posts
  • OS:Windows 7 x64

Posted 11 June 2012 - 12:51 PM

...
Everyone has his or her way, as said before I'm using a modified NT6Fast installer, the advantage is that it skips the WinPE pass.
ImageX will extract the wim index I choose to the harddisk, create boot menu and bootsector and copies the autounattend file to the windows\panther folder and firstlogon.cmd to c:\install folder.
That takes about 4 or 5 minutes, only when rebooting the autounattend.xml will get used. This method is universal for all editions, both x86 and x64.

On a side note, I modified the NT6Fast installer to do the partitioning and have included a XP universal .wim image, so I have only one script that can deploy many OS the unattended way.


I would love to hear the details of this method, it's advantages and disadvantages, and why you chose to use this way over RMPrepUSB and the other options. Probably best to explain the details in another thread though. Don't want to hijack the thread.

bphlpt, did you look at the test batches I made? Did I get it right this time?


:) As if I'm an expert. LOL Actually, it depends. I only looked at them briefly before and thought they were two tests you made with the first one giving the correct results and the second one not. Is that correct? And it is then called from the "FirstLogonCommand" section for x86 only, since x64 only commands can be called cleanly in a separate batch from the "FirstLogonCommand" amd64 section. Is that correct? Assuming both of those statements are correct, so the batch will only be called from the "FirstLogonCommand" section for x86 and statements inside will only be intended to be executed by a 32-bit OS, hence the whole reason for the "IF" tests, and also assuming that you do not need the Arch0 variable for any reason, then your batch can be written:

@echo off
if not exist "%SystemRoot%\SysWOW64\cmd.exe" if not defined PROCESSOR_ARCHITEW6432 goto :Cpu86
goto :exit
:Cpu86

:: Put all your x86 only statements here

:exit
exit

which is what you had only slightly "cleaned up". :)

If my understanding was not correct, I would be happy to take a look at the actual routine you are trying to use to see if I can spot any problems. I would also need to know when it is called and where it is called from.

Cheers and Regards

#86 bphlpt

bphlpt

    WinCert Dominator

  • Global Mods
  • 1,170 posts
  • OS:Windows 7 x64

Posted 11 June 2012 - 01:54 PM

If we want choose the Windows 7 AIO Edition image to install ; we must remove the ei.cfg file!
You can open ei.cfg file with notepad to read the desciption about Windows. If we keep this file only ONE Edition can be installed!
...


So Escorpiom had it backwards? The presence of the ei.cfg file will override the Autounattend.xml? So if the ei.cfg file is removed we can use the same Autounattend.xml for either DVD or USB use?

Shouldn't your comment above:
<!--Batch file to launch the 64-bit or 32-bit programs-->
actually be:
<!--Batch file to launch the 64-bit programs-->
since from where it is it will only be called for a 64-bit OS?

While your other comment:
<!--Batch file to launch the 32-bit programs-->
should actually be:
<!--Batch file to launch the 32-bit or 64-bit programs-->
since from where it is it will be called for both 32-bit and 64-bit OS? Or am I missing something?

Cheers and Regards

Edited by bphlpt, 11 June 2012 - 01:55 PM.


#87 myselfidem

myselfidem

    Wincert Addict

  • Members
  • PipPipPipPipPipPip
  • 598 posts
  • Location:Suisse
  • OS:Windows 7

Posted 11 June 2012 - 05:42 PM

So Escorpiom had it backwards? The presence of the ei.cfg file will override the Autounattend.xml? So if the ei.cfg file is removed we can use the same Autounattend.xml for either DVD or USB use?

No, the presence of ei.cfg don't override the Autounattend.xml file at all. But, if we keep this one, only one Edition can be installed (32-bit or 64-bit) with install.wim (Ultimate for example) images merged of course.
We need first, to create our customized Windows 7 AIO, to have Windows 7 Ultimate Edition because all images are included inside.

Example mine:
ei.cfg
[EditionID]
Ultimate
[Channel]
Retail
[VL]
0

But, if we want choose to install any Windows 7 versions (32-bit or 64-bit) we must remove this file and during the installation a window let us choose the Windows 7 Edition we want install.

I made new comments about programs inside the Autounattend.xml AIO file, working on cpu x86 or amd64. The batch files aren't the same: FirstLog_x86.cmd and FirstLog_x64.cmd.

Because on a computer runing 32-bit OS we can only install 32-bit programs, but on a computer runing 64-bit OS we can install 32-bit programs and/or 64-bit programs.

Regards

Edited by myselfidem, 12 June 2012 - 04:19 PM.


#88 bphlpt

bphlpt

    WinCert Dominator

  • Global Mods
  • 1,170 posts
  • OS:Windows 7 x64

Posted 11 June 2012 - 06:51 PM

Because on a computer runing 32-bit OS we can only install 32-bit programs, but on a computer runing 64-bit OS we can install 32-bit programs and/or 64-bit programs.


That is true of course, and I understand your point, but I just figured that since for a computer running a 64-bit OS the "<FirstLogonCommands>" for BOTH "x86" AND "amd64" sections will get processed, it made sense to put the 32-bit programs in the "x86" section and the 64-bit programs in the "amd64" section. No? I realize that there will be a few exceptions to this rule, but in general I thought that was the best way. If I am incorrect, could you please give me some examples?

Actually I just thought of an example that requires programs to be listed in both "x86" and "amd64" batches, assuming that the batches are set up to only be run for 32-bit and 64-bit OS's respectively - dual arch installers such as Adobe Flash. Since it is now only provided as a dual arch installer it should go in both the "x86" section and in the "amd64" section, with the "IF" tests set up to make sure that the installer is only run once. As an alternative, you could have two different sections within your 32-bit batch for 32-bit vs 64-bit OS installations to utilize. You could even get fancy and have three different sections - an "all" section at the beginning which would get run for any installation, then your "IF" tests would split it into 32-bit only and 64-bit only sections. The batch called from the "amd64" section would then truly only need to be 64-bit programs to be used in 64-bit OS. Right?

Cheers and Regards

#89 myselfidem

myselfidem

    Wincert Addict

  • Members
  • PipPipPipPipPipPip
  • 598 posts
  • Location:Suisse
  • OS:Windows 7

Posted 11 June 2012 - 08:04 PM

That is true of course, and I understand your point, but I just figured that since for a computer running a 64-bit OS the "<FirstLogonCommands>" for BOTH "x86" AND "amd64" sections will get processed, it made sense to put the 32-bit programs in the "x86" section and the 64-bit programs in the "amd64" section. No? I realize that there will be a few exceptions to this rule, but in general I thought that was the best way. If I am incorrect, could you please give me some examples?


Yes, you are right, it make sens!
But, however we can choose to install 32-bit programs on 64-bit OS!
We must adapt the batch files to suit your needs using "<FistLogonCommands>" for both "x86" and "amd64", with this particular Autounattend.xml file, because all passes are executed!

About Adobe Flash Player, we can install on 32-bit OS or 64-bit OS.

Like this, on Windows 7 64-bit OS, I can install Office 2007 32-bit version, Java 32-bit version, IE9 32-bit version, etc.

We are free to install what we want with the batch files.

Regards

*Edit: About dual arch programs

Actually I just thought of an example that requires programs to be listed in both "x86" and "amd64" batches, assuming that the batches are set up to only be run for 32-bit and 64-bit OS's respectively - dual arch installers such as Adobe Flash. Since it is now only provided as a dual arch installer it should go in both the "x86" section and in the "amd64" section, with the "IF" tests set up to make sure that the installer is only run once. As an alternative, you could have two different sections within your 32-bit batch for 32-bit vs 64-bit OS installations to utilize. You could even get fancy and have three different sections - an "all" section at the beginning which would get run for any installation, then your "IF" tests would split it into 32-bit only and 64-bit only sections. The batch called from the "amd64" section would then truly only need to be 64-bit programs to be used in 64-bit OS. Right?


If I well understand the dual architecture programs are used on different CPU and OS.

That means:
- on a computer with cpu x86 the 32-bit program will be installed
- on a computer with cpu x64 and OS 64-bit, 32-bit and/or 64-bit programs could be installed
- on a computer with cpu x64 and OS 32-bit, the 32-bit program will be installed

But using the batch file you improved, all seems to work fine! ;)

Regards

Edited by myselfidem, 13 June 2012 - 07:40 PM.


#90 myselfidem

myselfidem

    Wincert Addict

  • Members
  • PipPipPipPipPipPip
  • 598 posts
  • Location:Suisse
  • OS:Windows 7

Posted 12 June 2012 - 04:40 PM

Escorpiom and myselfidem - It would be really great if we could come up with appropriate settings that would accomplish these in all cases, ie have a truly universal AutoUnattend.xml that would work as intended for both DVD and USB installation methods and hopefully for all the most popular installation tools including Win Toolkit, WinNTSetup, WinSetupFromUSB with GUI, RMPrepUSB, NT6FastInstaller, DX WinNT6.x True Integrator, and any others I've forgotten including plain vanilla installs using nothing but MS tools and methods. Possible, or just wishful thinking?

Another tool is "WinAIO Maker Professional v1.3":
http://forums.mydigi...-Setup-Solution

The interesting part also is that we can select the option: Enable x64 Recovery Mode

Using: ar_seven_am, Escorpion, bphlpt advices, we can use our Autounattend.xml AIO file:

We can remove some unwanted values, of course!

Example = using only ONE WindowsPE pass and a random name for the computer (*)
Autounattend.xml
Spoiler


Regards

Edited by myselfidem, 12 June 2012 - 04:42 PM.


#91 bphlpt

bphlpt

    WinCert Dominator

  • Global Mods
  • 1,170 posts
  • OS:Windows 7 x64

Posted 12 June 2012 - 06:54 PM

Another tool is "WinAIO Maker Professional v1.3":
http://forums.mydigi...-Setup-Solution

The interesting part also is that we can select the option: Enable x64 Recovery Mode


I thought that Win Toolkit offered that same capability. Can anyone confirm that it does or does not?

Cheer and Regards

Edited by bphlpt, 12 June 2012 - 06:54 PM.


#92 myselfidem

myselfidem

    Wincert Addict

  • Members
  • PipPipPipPipPipPip
  • 598 posts
  • Location:Suisse
  • OS:Windows 7

Posted 13 June 2012 - 11:44 AM

myselfidem, I think ur autounattend.xml will not work if we add some extra command in setting specialize also OOBE, an example I make 2 firstlogon command (one for x86, 2nd for x64), becuz since x64 have x86 feature too in the image, it will check x86 setting too even we choose x64 image, that will mess up installation command if we make that separately depend on the system architecture itself (mostly worse in specialize setting, if we choose x86 as first, it will use x86 n ignore x64), all u need to change is move amd64 first as first setting than x86 as 2nd setting in autounattend.xml.

Thanks to explain the trouble!

We are trying to create an "Autounattend.xml AIO" file, for any Windows 7 versions (32-bit or 64-bit) we choose to install!

After many tests, I see that we can keep the order for x86 and amd64 passes whithout trouble...
But it's needed to create carefully the batch files for "RunSynchronousCommand" inside "specialize passes"
and "FirstLogonCommands" inside "oobeSystem passes"!

I also tested the Daemon Tools program (dual architecture).
On a Virtual Machine it's needed first to install the "TrustedPublisher Certificate" for Daemon Tools to install fine the program and the Virtual device.

Browse inside the registry to:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\TrustedPublisher\Certificates\5557C0953FBD9F93745B214FB2483E9369B597F0]
"Blob"=...

Or for 64-bit:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SystemCertificates\TrustedPublisher\Certificates\5557C0953FBD9F93745B214FB2483E9369B597F0]
"Blob"=....

I've updated the folder SetProductKey.rar (all batch files updated) , on my sig below, with the new example for Daemon Tools.
Tested Windows 7 32-bit and 64-bit (AIO), on Oracle VM VirtualBox, and works fine!
(vbs files are used to hide the command prompt window)

Here is the Autounattend.xml AIO file (for Daemon Tools, as example)
Spoiler


Cheers and Regards

Attached Files


Edited by myselfidem, 13 June 2012 - 07:52 PM.


#93 bphlpt

bphlpt

    WinCert Dominator

  • Global Mods
  • 1,170 posts
  • OS:Windows 7 x64

Posted 13 June 2012 - 08:11 PM

We are trying to create an "Autounattend.xml AIO" file, for any Windows 7 versions (32-bit or 64-bit) we choose to install!

After many tests, I see that we can keep the order for x86 and amd64 passes whithout trouble...
But it's needed to create carefully the batch files for "RunSynchronousCommand" inside "specialize passes"
and "FirstLogonCommands" inside "oobeSystem passes"!


Thank you for continuing to work to make the Autounattend.xml as robust, universal, and bulletproof as possible. But I have to ask, in addition to everything you are doing, if processing amd64 first and x86 second as ar_seven_am and I have suggested, can even help with just one potential problem and make it even more bulletproof, why do you not want to do that? If it doesn't hurt anything in any way, why not?

Cheers and Regards

Edited by bphlpt, 13 June 2012 - 08:52 PM.


#94 myselfidem

myselfidem

    Wincert Addict

  • Members
  • PipPipPipPipPipPip
  • 598 posts
  • Location:Suisse
  • OS:Windows 7

Posted 13 June 2012 - 08:27 PM

Many thanks bphlpt !

Well, of course, we can do like you and ar_seven_am have suggested, processing amd64 first and x86 second inside our Autounattend.xml file - to avoid potential problems - installing Windows 7 64-bit editions with Windows 7 AIO - for "RunSynchronousCommand" inside "specialize passes" and "FirstLogonCommands" inside "oobeSystem passes"!

This seems to be the best way finally ! :P

Regards

*Edit:
However, we can see that the two passes are executed anyway even if processing amd64 first and x86 second installing Windows 7 64-bit versions!

We can look at "setupact.log" inside: C:\Windows\Panther\UnattendGC\setupact.log

After testing successfully Windows 7 64-bit AIO, here is mine setupact.log on VM Oracle VirtualBox

setupact.log
Spoiler


Autounattend.xml
Spoiler


I think it seems we can't avoid some problem if the batch files aren't good anyway, and changing or not the passes order makes no difference!

Attached Files


Edited by myselfidem, 13 June 2012 - 11:06 PM.


#95 crashfly

crashfly

    WinCert Pro

  • Members
  • PipPipPipPipPip
  • 400 posts
  • Location:Arkansas, USA
  • OS:Windows 7 x64

Posted 14 June 2012 - 12:37 AM

*Edit:
However, we can see that the two passes are executed anyway even if processing amd64 first and x86 second installing Windows 7 64-bit versions!

There is a way around the "two pass" problem. Put in a statement that tests for a file that is created the first time the batch file is run. If the file is there (test returns true), then exit the batch file.

Simply put this at the beginning of the batch file and problem is solved. No more "run twice" problem.
if exits=%SystemDrive%\filetemp.txt exit
echo . > %SystemDrive%\filetemp.txt

Edited by crashfly, 14 June 2012 - 12:39 AM.


#96 myselfidem

myselfidem

    Wincert Addict

  • Members
  • PipPipPipPipPipPip
  • 598 posts
  • Location:Suisse
  • OS:Windows 7

Posted 14 June 2012 - 07:51 AM

Many thanks crashfly !

Yes the workaround works fine...but we must adapt the batch files if we want install Windows 7 x86 versions!

Regards

Edited by myselfidem, 15 June 2012 - 06:22 PM.


#97 bphlpt

bphlpt

    WinCert Dominator

  • Global Mods
  • 1,170 posts
  • OS:Windows 7 x64

Posted 14 June 2012 - 08:11 AM

Well, of course, we can do like you and ar_seven_am have suggested, processing amd64 first and x86 second inside our Autounattend.xml file - to avoid potential problems - installing Windows 7 64-bit editions with Windows 7 AIO - for "RunSynchronousCommand" inside "specialize passes" and "FirstLogonCommands" inside "oobeSystem passes"!

This seems to be the best way finally ! :P

Regards

*Edit:
However, we can see that the two passes are executed anyway even if processing amd64 first and x86 second installing Windows 7 64-bit versions!

We can look at "setupact.log" inside: C:\Windows\Panther\UnattendGC\setupact.log

After testing successfully Windows 7 64-bit AIO, here is mine setupact.log on VM Oracle VirtualBox


Thank you for putting the amd64 section first. You are correct that both sections will still run and that this is not a substitute for a properly constructed batch file. But both ar_seven_am and I, and perhaps others, prefer it this way, and again if it doesn't create any problems for you, why not? crashfly's method of checking for the existence of a file that either should or shouldn't be there if a routine has already been run, is one that is very often used and is a proven way to handle a situation that just can't seem to be handled any other way. Of course it is also always best if you have to create a flag file that you make every attempt to clean up after yourself and delete the flag file after you no longer need it. Assuming the batch will only be attempted to run twice, and you actually only want the code below the test to run once, this can be accomplished as follows:
if exits=%SystemDrive%\filetemp.txt del %SystemDrive%\filetemp.txt & exit
echo . > %SystemDrive%\filetemp.txt

(This also assumes that this code is in a batch file that will be called twice. If you have separate batch files for the x86 and amd64 section then this solution might not work for you.) And this test does not have to be the first lines of the batch. If there is code you always want to have run, even if it has been run before, then put this test after that code. To accomplish exactly what you want during an OS build requires a delicate dance between the Autoattend.xml and the batch files that it calls and exactly how those batch files are constructed - what is in them and in what order. Perhaps we should expand this thread's discussion to include the batch file's construction and contents in more detail since the batch files and the Autoattend.xml are so intertwined?

Cheers and Regards

Edited by bphlpt, 14 June 2012 - 08:22 AM.


#98 Escorpiom

Escorpiom

    Member

  • Members
  • PipPip
  • 38 posts
  • OS:Windows XP Pro

Posted 14 June 2012 - 12:04 PM

Well, perhaps the method crashfly suggested is the most convenient, in my case I'd rather have one batch only instead of two.
Going to do some tests. In the same way you can also set a reg key and check it when the batch runs, for example

REG QUERY , if exist "key" then exit
REG ADD "key"

Or something similar, nothing will be written to disk. Perhaps the RunOnceEx key if we are using it?
The method bphlpt explained is working perfect also, tested it yesterday. Thanks for the effort.
Ah, almost forgot, my batch will add some reg entries, after that it searches for a network share, if not found it searches for a local source.
If a source is found, it sets the post install source as a drive letter.
On that source drive is an universal ROE batch that adds the RunOnceEx entries to the registry. After that it is executed.
At the end a little cleanup and a reboot.

So: Autounattend > Firstlogon.cmd > ROE.cmd.

Where the Firstlogon is always on the systemdrive, the ROE batch can be anywhere.

Cheers.

Edited by Escorpiom, 14 June 2012 - 12:10 PM.


#99 myselfidem

myselfidem

    Wincert Addict

  • Members
  • PipPipPipPipPipPip
  • 598 posts
  • Location:Suisse
  • OS:Windows 7

Posted 14 June 2012 - 03:48 PM

Assuming the batch will only be attempted to run twice, and you actually only want the code below the test to run once, this can be accomplished as follows:

if exits=%SystemDrive%\filetemp.txt del %SystemDrive%\filetemp.txt & exit
echo . > %SystemDrive%\filetemp.txt

(This also assumes that this code is in a batch file that will be called twice. If you have separate batch files for the x86 and amd64 section then this solution might not work for you.) And this test does not have to be the first lines of the batch. If there is code you always want to have run, even if it has been run before, then put this test after that code. To accomplish exactly what you want during an OS build requires a delicate dance between the Autoattend.xml and the batch files that it calls and exactly how those batch files are constructed - what is in them and in what order.


Many thanks,
YES, it is the best way to set first passes amd64 and second x86 inside our Autounattend.xml AIO file ! ;)
But, I am not totally sure!

Sorry, but it would be nice if someone can give an example solving the Windows 7 AIO 64-bit installation about the passes! Because, I think since the begenning that SPTD Virtual Driver, seems not to be a good one!

Perhaps we should expand this thread's discussion to include the batch file's construction and contents in more detail since the batch files and the Autouattend.xml are so intertwined?


Yes, I think so. I think you and suggestions crashfly, have solved the problem improving the batch files!

As example, working fine for me with Daemon Tools (any order inside Autounattend.xml file):

Daemon_x86.cmd (set inside RunSynchronousCommand)
@echo off
echo.
if not exist "%SystemRoot%\SysWOW64\cmd.exe" if not defined PROCESSOR_ARCHITEW6432 goto :Cpu86
goto :exit
echo.
:Cpu86
rem TrustedPublisher Certificate needed to install Virtual SPTD Setup
regedit /s "%SystemDrive%\Install\Apps\Daemon\Daemon32.reg"
echo.
cmd /c %SystemDrive%\Install\Apps\Daemon\daemon-tools.exe /S
echo.
:exit

Daemon_x64.cmd
@echo off
echo.
if exist "%SystemRoot%\SysWOW64\cmd.exe" goto :Cpu64
goto :exit
echo.
:Cpu64
rem TrustedPublisher Certificate needed to install Virtual SPTD Setup
regedit /s "%SystemDrive%\Install\Apps\Daemon\Daemon64.reg"
echo.
cmd /c %SystemDrive%\Install\Apps\Daemon\daemon-tools.exe /S
echo.
:exit

@Escorpiom
Thanks to share your results !

Regards

Edited by myselfidem, 14 June 2012 - 06:01 PM.


#100 Escorpiom

Escorpiom

    Member

  • Members
  • PipPip
  • 38 posts
  • OS:Windows XP Pro

Posted 18 June 2012 - 01:09 PM

Here is the regkey I'm using to check for a double firstlogon-run:

REG QUERY "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\PostInstall" /V "FirstLogonRan" >NUL 2>&1 && exit
REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\PostInstall" /V "FirstLogonRan" /T REG_DWORD /D "1" /F >NUL 2>&1

Not tested yet, but it should work.
I chose this reg key because it seems that it will not be redirected on x64. Adding should not be a problem, firstlogon runs as admin.

@myselfidem:
Your autounattend.xml has only the x86 WinPE pass, not the x64. Is it not needed?

Cheers.

Edited by Escorpiom, 18 June 2012 - 01:09 PM.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users