Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


FireGeier

Member
  • Content Count

    405
  • Donations

    $0.00 
  • Joined

  • Last visited

Everything posted by FireGeier

  1. Hello kal! Ah... I forgot about this simple way of doing it. Than you will not have any problem usualy. Well there is no problem, if you copy a file to the target system generaly, but if you use UseConfigSet tag in Autounattend.xml, than you will have the problem described here. If you do it in an other way, than you'll have no problems - or better, you should not have. Thanks, I'll add that as a workaround, if the "simple" method should not work. Regards, Martin
  2. Hello kal! Great input and great work! That's highly appreciated! You're 100% right. It can happen like you've described, even if in very less cases only. My very first German Vista Guide was using an exe-file a member of German windows-unattended.de has written. It's called FWDT.exe and it is almost doing the same like your AppsRoot.exe. The "problem" of this exe solution is, that you have to find a way to copy the AppsRoot.exe over to the target drive to execute it. That means you've to integrate to install.wim or you have to use $OEM$ folder and UseConfigSet - what has a known issue, too. Many users found it to complicated and so I switched back to the simple method you've mentioned first. As far as I've got feedback the simple method is working in about 99% of setups. Don't missunderstand... I don't want to criticise, cause I know that your solution is the 100% perfect way of doing it and you did great work! Thanks! Regards, Martin
  3. Hello Mateus! Are you doing it like described inside my Guide here and here? If yes, than please look for a workaround here. Regards, Martin
  4. We will soon. Soon? How soon is "soon"? That message was written April 20th and it is now almost September. Come on guys I think there are many eager people (like me) who want to see your project completed instead of sticky's. There is a guide here and other helpfull projects - like this here from maxXPsoft. Or look here at nuihs vlite project. I think there are enough options on the board to get an unattended Vista setup. No one gets paid for the work here - AFAIK - so these are all free time projects... if you think a guide should be published sooner, feel free to write one. Martin
  5. Hello Dobby! Thanks, for your feedback! Yes, you're right. I've to apologise for the bad English. So any help with the grammar would be highly appreciated. Thanks, for pointing that out! Martin
  6. No, there is nothing like that for Autounattend.xml and no regtweak AFAIK, too. I'm not 100% sure for the regtweak but 100% sure for Autounattend.xml. Regards, Martin
  7. Hello Wabaunza! I can't see a sysprep command to leave the audit mode inside your xml. I just see the one to enter audit mode: <RunSynchronousCommand wcm:action="add"> <Path>%WINDIR%\system32\sysprep\sysprep.exe /quiet /audit</Path> <Order>2</Order> <Description>Sysprep</Description> To leave audit mode add the following line as the last synchronous command in auditUser pass: %WINDIR%\system32\sysprep\sysprep.exe /quiet /oobe /reboot or, if you want to generalize your setup at the same time: %WINDIR%\system32\sysprep\sysprep.exe /generalize /quiet /oobe /reboot Regars, Martin
  8. Hello Ozzie! What are you trying exactly? Martin
  9. Does this mean, it don't gives you the double entries? Martin
  10. In audit user mode I got it almost to work with cmd /c in front. So in your case it should look like this: Try out and see, if it's working. And if you want to set it to the default user profile, than you need to follow the copy profile guide in addition. Martin
  11. Yeah, I agree that's right. I clean the sandbox folder, too, after the update run. But one update run means that all updates are integrated and than the sandbox will be cleared. In your case sandbox is cleared after every single hotfix. I would say that both procedures are making sense. You clear it after every single hotfix cause the next fix will be like a new integration. If you put everything together in one xml, than you don't have the option to clear the sandbox between single fixes. But you supposed to put them in one xml to get dependency checked. I like your way of integration as well, just wondering if the dependency will be checked. To me they do. Martin
  12. Hi chiners! Dejavu... look here. Or are you asking for the regkey to remove the US keyboard? Regards, Martin
  13. Ok... I understand, than that's the difference. I'm using the "xml-method" cause this was one of two procedures, where I could find something in WAIK help about dependency check. I would have prefered the method with all updates in one command line semicolon-seperated, but I never got this to work. So I ended up with the "xml-method". So it may has something to do with this dependency check? On the other hand the error came up for some guys here, too, when using peimg to integrate the hotfixes. Peimg command does not check dependency, AFAIK. Very strange... can't see any logic behind ATM... Martin
  14. Max is right, WSIM can corrupt the xml even if you don't integrate fixes. For me it happens almost when changing an Autounattend.xml that does already exist - removing an entry for example. It's not happening all the time but it can happen. Most of these corruptions don't realy matter but sometimes they do. On the other hand, that doesn't mean automatically, that slipstreaming the updates could not be a problem, too. Max do you may integrate the updates in an other way than described in WAIK help or my guide? Martin
  15. EasyBCD is an other alternative to edit BCD file. I think there are some more tools available, cause BCDEdit is to complicated to understand. Or better the documentation is not very helpfull. Martin
  16. Hello MICROS~1! You could start the script using RunSynchronous command. But if you're following my Guide and installing drivers directly from your removable media, than you script should run before SetDriversRoot.cmd is executed - that would work the same way like described for Drivers from Media. Regards, Martin
  17. Hello amit! With FAT32 it won't work. You need to format it with NTFS. But even if you're formating it NTFS you can run in problems like you've described. You need to use BCDEdit to reconfigure or correct the BCD boot file. BCDEdit is not that easy to use. You can try to start from Vista Setup DVD first - without using an Autounattend.xml - and than don't start the setup use the Recovery Console instead. There is an option to correct the bootcode, AFAIK. That's easier to use than BCDEdit. Do you have an internal disk installed in your computer? Have you may switched form one USB port to the other? Regards, Martin
  18. Hello MICROS~1! The part with the Users folder is simple. Just put the Windows-Shell-Seutp / FolderLocations / ProfilesDirectory Component to your Autounattend.xml to move your Users Folder. It's not that easy for Program Files. Note ProgramData Component in FolderLocations is not the Program Files. Reason: Vista is image based. That means it's not installed, it's extracted to the HD and configured than. So you would have to copy the Program Files Folder to your prefered location and than you would need to change all entries inside registry belonging to the Program Files folder. Could be done with a batch but it's not that easy. Regards, Martin
  19. Well, that's not right completly - if you try following my Guide. I don't wanna say, that this is the only working way. But it seems to be, that amit tried to follow my Guide and so he has to use setx. But amit did not follow the Guide exactly: Setx.exe with -m option sets the AppsRoot variable to the system (machines) environment. That means it will be written into the registry. But the environment will be loaded once only; at the very beginning of a session (pass). So if you set AppsRoot variable in auditUser pass for example, than you can't use it in this same auditUser pass. This is the reason why I set AppsRoot variable during specialize pass and than use it in auditUser pass. Set instead sets the AppsRoot varialbe for the actual cmd only. That means after cmd /c command it's gone again. So you can't use it for the second, third etc. cmd /c command. This is/was my experience when figuring out the apps installation. AFAIK, that will only work, if you put this command AND all the apps installer calls into the same batch. I need to mention, that I'm not the "king of batch programming", too, so I might be wrong here partly. But the way I've described works, if you do it exactly like described inside the guide. But amit did not, cause he used setx command in the same pass like the call for apps installations. Regards, Martin
  20. Hello chiners! It's not that easy for Vista unfortunatly. You need to do the steps described here, to copy the HKCU tweaks over to the DefaultUser. Note: If you've problems to get it worked, than please read the workaround here and let me know! And like maxXP said, auditUser pass is the right pass to apply HKCU tweaks. The only thing you have to know is, that they are just setted for the User you logged on in auditSystem pass. BTW, you can apply HKLM tweaks during auditUser pass, too. But if you need the tweaks present for the Vista setup already - like disabling UAC during setup for example - than you've to apply these kind of tweaks during specialize pass. Final Note: If you should have problems to get the whole AppsRoot thing to work, than pleas read here. Regards, Martin
  21. Hello chiners! Please read here. And please look here, too, to find out about the disadvantages of this method. Regards, Martin
  22. Hello swancd! You need to use a key to let the unattended Setup run, BUT you can remove the key using sysprep at the end. I'm not an OEM so I can't tell you, if OPK-Tools include a genereal key you can use for the unattended Setup only. If the tools do not include such a key, than you can use one of the keys of the DVDs/licenses you're selling with the computer, you just need to make sure that this key will not be autoactivated during setup. There is a setting in Autounattend.xml (<SkipAutoActivation>) to avoid that. This is the way I do it for my friends. I use my key for the unattended setup and at the end - after syspreping the machine - I put in the key from case of friends computer. If I understand right that's the same thing you wanna do. The only thing is that I'm not to familiar with OEM-DVD cause I've never had one in my hands for Vista so far. If you should not be prompted for the key at the end of unattended Setup, than read here. Regards, Martin
  23. Hello thom! AFAIK about setups from "simple" networkshare (wo using WDS), you need to log on to your networkshare first - that means run a batch to to do so form within WindowsPE 2.0. Than start the setup from your share (not the setup from the Start-CD/DVD). But I've not tried out yet, cause I don't have an environment to test. But this is what I've read. So first you've to make sure that you can access the share from WindowsPE 2.0. If you should start the setup from the share already and you get this error message, the problem is that you're already logged on to the share and than the logon from Autounattend.xml will fail, too. So, if you've logged on from with WindowsPE already, than you don't need the credentials thing inside your xml, AFAIK. Regards, Martin
  24. Hello nokia! You can use imagex /delete to remove the vista64 images from your wim file. Syntax: imagex /delete PathToYourWimFile ImageNumber PathToYouWimFile: This entry points to the wim file you want to delte images from. ImageNumber: This is the index number of the image you want to delet inside your wim file. To find out which Image number belongs to which image use imagex /info (e.g.: imagex /info d:\VistaSource\install.wim). Example: imagex /delete d:\VistaSource\install.wim 4 This will delete the image with index number 4 of install.wim inside d:\VistaSources directory. Note: WAIK help says the imagex /delete command should run from a WindowsPE 2.0 system, but I would expect, that it's running from under XP or Vista OS ,too. But keep in mind if you should have problems to execute the command. Regards, Martin
×
×
  • Create New...