Jump to content

jimanny

Member
  • Posts

    30
  • Joined

  • Last visited

  • Donations

    $0.00 

Everything posted by jimanny

  1. I have a Dell Precision M6300 that came with Vista Business x64 on a 64GB SSD drive. Out of the box, I have no problems, except Vista uses up nearly 20GB, so I want to shrink it, which I did with vlite (thank you Nuhi ). On the vlited build, the problem comes when I try run the setup.exe for Pro/E Wildfire x64. The hourglass comes and goes without any errors or entries in the event viewer. I'm hoping someone can offer any clues. Is there something in my vlite config that's causing this? I tried to turn DEP to AlwaysOff in Vista, but no luck. Attached is my Last Session.ini file. Last_Session.ini
  2. This time I'm working on an x86 build and notice the same thing with the "n", but different... Lines from newly built (by hand) Autounattend.xml: <component name="Microsoft-Windows-Shell-Setup" 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"> <component name="Microsoft-Windows-Security-Licensing-SLC-UX" 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"> and the same lines from vLite: <component name="Microsoft-Windows-Shell-Setup" 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"> <component name="Microsoft-Windows-Security-Licensing-SLC-UX" 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"> I guess the first "n" in NonSxS is supposed be caps and the in the second line it's upper case?
  3. I was getting the enumeration error so went ahead a rebuilt the Autounattend.xml file in Windows System Image Manager component by component and watching for differences. This line had the difference that fixed the problem: From new Autounattend.xml: <component name="Microsoft-Windows-Security-Licensing-SLC-UX" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="NonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> From vLite Autounattend.xml: <component name="Microsoft-Windows-Security-Licensing-SLC-UX" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> See the difference? Take a look at NonSxS
  4. korri, I ran into the same error. Try nuhi's suggestion to me in post 65. 1.4.RC2 works for me, except with dotnet 2.0 full instead of lite. Also, in case you're on x64, make sure you install dotnet 2.0 full x64 so that you don't repeat my mistake!
  5. Which chip, an Intel or AMD, actually processes x64 better than the other, well, I've read somewhere the AMD may do it slightly better, but exactly how, I don't know. They're definitely both x64 "capable". But if I had to pick, I'd have to go with the dual or quad core Intel chips, but only based on my experience with how they overclock between 32-bit and x64. Last year, I had an Opteron 165 running XP SP2 (32-bit) for months without a hitch at 2.9GHz. Then I installed x64, and had to drop the overclock to ~2.7GHz to be stable again. Earlier this year I did the same thing but with a QX6700 and found it to run run equally stable at 3.4GHz on either flavor, 32-bit or x64. This and the fact that XP x64 is based on the newer and more stable kernel are the reasons I stuck with x64.
  6. I like the stability of 2003 but settled with XP x64. Isn't XP x64 built from the same 2003 kernel? nLite works with 2003 just fine except I use the machine as a workstation and found a few but important drivers would not install on 2003 (Logitech drivers and others). Now I use nLited XP x64 and it's great. I think there are less add-ons available because not all of them work on x64 (I miss Unlocker). But x64 uses the same kernel (or similar?) as 2003, which makes the OS definitely feel more stable that XP SP2.
  7. nuhi, thank you. I got it to work, but only with the full 2.0 x64 .Net. Before when I *thought* I had 2.0 full installed, I probably didn't cause I used ryanvm's all-in-one .Net installer (dotnetaio.exe) which probably didn't install in this XP x64 machine (I didn't check it ). Still though, Framework Lite R3 worked fine on this x64 machine all the way up to 1.4b, so maybe something changed in 1.4RC? Or maybe I was lucky and Framework Lite R3 isn't supposed to work on x64. Either way, I'm stoked that it's working again.
  8. Ok, thanks. I didn't try that. Except I've always done it from the mapped Y: drive, so maybe something changed in 1.4RC (??)
  9. I tried the full x64 2.0 framework (dotnetfx2_64.exe), but still came the same errors. Here's how the event viewer looks: The next two errors say: Resolve Partial Assembly failed for Microsoft.VC80.CRT. Reference error message: The referenced assembly is not installed on your system.and Dependent Assembly Microsoft.VC80.CRT could not be found and Last Error was The referenced assembly is not installed on your system.
  10. nuhi, thanks for the release. nLite is great! I setup a vmware XP x64 SP2 "nLiter" machine, specifically to build nLited x64 images. It's been working great since v1.35. With the 1.4RC release I ran into an error. Here's what I did. Run MS update, install all available updates (there were 4 of them). Reboot. Uninstall 1.4b Install 1.4RC Launch nLite and get this: Ok, I figured maybe the Framework lite was also updated, but I see R3 like I have. Then I tried: Install R3 over the top of the existing install Launch nLite, which then ran fine (?) Then Next > Refresh, and get this: Next, I will install the full .Net 2.0 Framework and see what happens. Thanks for taking a look.
  11. Thanks nuhi! I hope the info helps. I'm looking forward to your next release.
  12. FYI, I narrowed the problem down to the "Network Monitor Driver and Tools" component. With it unchecked, browser.dll came back, and there's no longer the error message on bootup!
  13. I'm trying to nLite Server 2003 SP2 R2, but get a message box at every bootup: At least one service or driver failed during system startup. Use Event Viewer to examine the event log for details. Event Viewer shows: Event ID: 7023 The Computer Browser service terminated with the following error: The specified module could not be found. The service startup type is Automatic, but it's not started (which is normal I know). But when I go to start the service from Services, it gives: Could not start the Computer Browser service on Local Computer. Error 126: The specified module could not be found. From what I've gathered, the Computer Browser service uses browser.dll, which doesn't exist in system32, and I've no idea how it's missing. There are no updates or hotfixes, but there are components removed and tweaks added. Attached is my last session.ini. Any ideas? Last_Session.ini
  14. I successfully slipstreamed SP2 following marek722's tutorial but I still cannot install the two subsequent updates KB907417 and KB905648 either manually or from Office Update. Is anyone else able to install these? Update: Ok, this has something to do with I'm installing Office 2003 on Windows Server 2003. I ran the same Office install on a vmware XPSP2 and had no problems installing all office updates. Just by quick inspection, I noticed in XP the service "Office Source Engine" is manual but started before doing the update from Office Update. With Server 2003 the service wasn't started but the updates still failed even after starting the service. I was going to see if I could use Server as my workstation, but it seems not feasible for me because of this and a couple other minor issues. Anyway it was worth a try, back to XP...
  15. Great! I am very happy that I am able to contribute something useful and also happy with my luck that it worked after only 2 attempts! Basically, I went from your recommendation to have the 3 extra files in the SATARAID directory. The question was where to get the files since they aren't all in 6.69. 6.69 doesn't have NVATABUS.INF so there's only one other place it can come: 6.70 in IDE/WinXP/LEGACY. NVATA.CAT and NVCOI.DLL are already in 6.69 (in SATA_IDE) so copying those into 6.69/SATARAID were the final links to make it work for W2K3 R2. It seems it works because NVATABUS.INF calls NVATA.CAT and NVATABUS.SYS but I don't know who calls NVCOI.DLL. Perhaps NVCOI.dll is called by NVATA.CAT but I don't know cause it's compressed. Anyway, W2k3 SP1 basically equals R2 so it should work the same there too.
  16. Fernando, First, thanks very much for your tremendous work to make integrated NVRAID drivers possible! I have just successfully loaded a fresh copy of Windows Server 2003 R2 32-bit on my DFI NF4-D rig running 36GB raptors in RAID 0! It took me a couple of attempts so I wanted to post here with my findings. Also, please forgive me if this info has already been mentioned/discussed but I did not come across any mention of this technique in this thread: Attempt #1: I was a bit confused with the recommended drivers (the link to 6.66 in post #1) because it seems from inspecting the file names in the WinXP directories, that those are x64 drivers. But nevertheless I tried them anyway and setup quickly gave an error saying the drivers weren't compatible with the W2k3 x86 that I was loading. Attempt #2: This second attempt was a success!: I used the x86 (32bit) v6.69 drivers directly from the source and followed your steps from post #1 but with a slight twist. I copied the following files into the IDE/WinXP/SATARAID directory of the 6.69 drivers: - NVATABUS.INF from IDE/WinXP/LEGACY of the 6.70 for WinXP drivers - NVATA.CAT & NVCOI.DLL from IDE/WinXP/SATA_IDE of the 6.69 for W2K3 drivers Then I used nLite to integrate the drivers as usual from the prepared SATARAID directory. Here is the contents of that directory: disk1 5 06/30/2005 07:48 PM idecoi.dll 289,792 08/18/2005 05:52 PM nvata.cat 9,192 09/27/2005 04:08 AM nvatabus.inf 4,461 08/18/2005 05:50 PM nvatabus.sys 93,568 08/18/2005 05:52 PM nvcoi.dll 33,280 08/03/2005 02:52 PM nvraid.cat 9,423 09/24/2005 04:51 AM nvraid.inf 5,299 09/22/2005 02:50 AM nvraid.sys 77,056 08/18/2005 05:52 PM nvraidco.dll 19,456 08/18/2005 05:52 PM txtsetup.oem 4,703 08/18/2005 05:50 PM From Windows 2003 > Device Manger > IDE ATA/ATAPI controllers > NVIDIA nForce4 Serial ATA Controler > Properties > Driver it says Driver Version: 5.10.2600.552 so I believe this is working properly now for Windows Server 2003 R2. - jimanny
  17. I have looked high and low for 1.0b4. Anyone know where to find it?
  18. BFCF, maybe there's something different in your winnt.sif file. For this method to work for an unattended install, you should only need to modify your winnt.sif and unzip Sort.zip to your UA root. That should create the $OEM$, Tools, and Tweaks directories with all the relative files. Then just compile the ISO and test it. After the install, it should do this: 1. Automatically login as the new user "NewUser" with the password "CHANGEME" 2. Set the permissions on the MenuOrder key (you may not see this cause it happens quick) 3. Reboot 4. Automatically logon again as "NewUser" This is where you try to drag the items in the start menu. If you can't, then it worked. I tested this method with only these tweaks applied so maybe a tweak you have is interfering. Try to only use the file in Sort.zip and see what happens. It should work! You might also try comparing your winnt.sif to mine. Here it is (change the ProductKey and admin password of course): winnt_jimanny.sif
  19. Yes, good find. I originally had CreateMenuOrderKey.vbs create the key before the permissions were set on it with RegPerm. Then later learned you could do the same with a simple .reg file, thus the MenuOrderKey.reg file. So you can safely remove the lines without a problem. I updated the Sort.vbs in the Sort.zip file here. On a side note, if you leave the line you mentioned in Sort.vbs, RegOnceEx can't find CreateMenuOrderKey.vbs and just moves on, which is why my testing still worked. - jimanny
  20. Here is a solution that I use to permanently sort the start menu and favorites for an unattended install. What you will need: 1) A working unattended install. 2) Sort.zip 3) Regperm.exe 4) PsShutdown.exe Step 1: Unpack and collect the files. Unzip Sort.zip to the root of your unattended files location. Please take caution not to overwrite any file that already exists and you want to keep! For example cmdlines.txt. Obtain Regperm.exe and PsShutdown.exe and place them into the Tools directory. Step 2: Update the username and password (optional). Update the the username and password fields in $OEM$\autologon.reg and $OEM$\useraccounts.cmd Step 3: Update your unattended image and run it. At T-12, you'll see a box flash by that adds the new user then a blue dos box that sets up the rest. After a restart, you'll be automatically logged in as the new user. Then the permissions on the MenuOrder key are immediately set via RunOnceEx and the system will reboot via PsShutDown. When you're logged back in, check out the start menu. Try to reorder it by dragging. You should not be able to! What's even better, it will ALWAYS be sorted because the MenuOrder cannot be written to! Please note that this is just an example but can be tweaked to fit your existing unattended install. Also note that any reg tweak .reg file found in the Tweaks directory will be read in at T-12 by Sort.cmd. Have fun, - jimmany
  21. Ok, posting this made me dig a little deeper and I got it to work. If a resume the install, I have to open the "Virtual Machine Settings" dialog box, click CDROM, uncheck "Connected", click OK. Then do it again except check "Connected". For anyone who needs to know, taking the snapshot at T-13 is barely early enough to still be able to disconnect and reconnect the image with all those mouse picks. On the next rebuild, it'll be better to take the snapshot about half-way through T-14.
  22. Does anyone have a problem with vmware not seeing changes in the ISO file that is mounted to the virtual cd? I've done the search and found a couple threads in the ball park but could not find any mention of this issue... I'm using vmware to test my unattended install. I create the ISO and mount it to a a virtual cd inside vmware. Then I pause it during the install just when it hits the T-13 mark, and take a snapshot. This saves a lot of time because now I can just update the ISO and revert (then play) the vmware machine where it resumes the install at T-13. Is this how you guys are doing this? Well, this works fine for me as long as I only change the contents of the existing files in the ISO. For example, removing or adding a line in cmdlines.txt is OK - the install still resumes correctly. But if I add files and directories to the ISO, vmware still resumes fine, but just skips reading the cmdlines.txt file. Any suggestions? How can I force vmware to read changes in the ISO without starting the entire installation over ? - jimanny
  23. @BFCF For my unattended install, the MenuOrder key does not exist at T-12 anyway (see here) so removing the MenuOrder key via cmdlines.txt and a regtweak is futile. This is probably the case for you too. I used this techinique to sort it permanently and unattended too! - jimanny
  24. I'm installing from an nLite compilation with the "Sort Start Menu Alphabetically" option UNchecked. There are components removed so maybe MenuOrder was already removed with some other nLite option? Anyway here's a screeny of my install at T-12... where's MenuOrder? Also, it seems to me that even if the MenuOrder key is removed during install, at some point the user is going to accidently or intentionally reorder the start menu which would cause the key to be created. Then once it exists, I think additional shortcuts get added (from installing programs etc.) to the bottom of the list, and there you have the problem. It seems to me that setting read-only permissions on the thing during a RunOnceEx is the real "never fail" solution. - jimanny
  25. I've been playing around with this issue for a bit now and I'll share what I've learned - hopefully it will help someone. It's been my experience that removing the MenuOrder key does work for a normal install, but only for so long. That is manually install windows, log in, remove the key, and restart. It seems that eventually something happens and it ends up unsorted again. For my unattended install project, I've tried removing the key at T-12 as others have suggested with no luck. Then I came across this at theeldergeek which explains how to sort alphabetically by restricting the permissions on the MenuOrder key. This one has worked great for me for a manual install - now to implement it unattended. Here's what I done which works for me using RegPerm: AlphabetizeStartMenu.vbs: Option Explicit ' Usage: ' AlphabetizeStartMenu.vbs <drive> <user> ' Example: ' AlphabetizeStartMenu.vbs D: NewUser dim oWS, oFS, oArgs, regperm, user, drive dim runonceex, menuorder, usersstring set oWS = WScript.CreateObject("WScript.Shell") Set oFS = CreateObject("Scripting.FileSystemObject") set oArgs = WScript.Arguments drive = oArgs(0) regperm = drive & "\Tweaks\Tools\regperm.exe /K" user = oArgs(1) runonceex = "\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\" menuorder = "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder" usersstring = "/A:Administrators:R /A:" & user & ":R /A:RESTRICTED:R /A:System:F /F /I /Q" 'set permissions on MenuOrder key to prevent reordering 'these are set with RunOnceEx just after the new user is logged in oWS.RegWrite "HKLM" & runonceex & "Title","Alphabetize the Start Menu" oWS.RegWrite "HKLM" & runonceex & "Flags",20,"REG_DWORD" oWS.RegWrite "HKLM" & runonceex & "install01\","Create MenuOrder Key" oWS.RegWrite "HKLM" & runonceex & "install01\1",drive & "\Tweaks\Tools\CreateMenuOrderKey.vbs" oWS.RegWrite "HKLM" & runonceex & "install02\","Add RegPerm Command Line" oWS.RegWrite "HKLM" & runonceex & "install02\1",regperm & " " & menuorder & " " & usersstring CreateMenuOrderKey.vbs Option Explicit dim oWS, oFS set oWS = WScript.CreateObject("WScript.Shell") Set oFS = CreateObject("Scripting.FileSystemObject") 'create MenuOrder key oWS.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\", "", "REG_SZ" I'm actually calling AlphabetizeStartMenu.vbs from a WIHU interface which comes up using RunOnceEx right after I first logon as administrator. The WIHU command sends the CDROM drive letter it finds and new user name that I create with WIHU. BTW, the WIHU install.ini section looks like this for reference: [Registry Tweaks] selected = 1 collapsed = 1 description.0 = Keep the Start Menu alphabetic command.0 = %SRCDRIVE%\Tweaks\Tools\AlphabetizeStartMenu.vbs %SRCDRIVE% %NewUserName% selected.0 = 1 This is working perfect for me now! After I logon as the newly created user, the start menu is perfectly ordered and I am not able to reorder it by dragging. I have not tried this without WIHU but it's my guess that if AlphabetizeStartMenu.vbs <drive> <user> was added to RunOnceEx at T-12 it would work as long as <user> existed at the time of the first logon. Perhaps you could create the user with a batch file and a reg file like here. Then, after you logon again, the MenuOrder key permissions would be set for the user specified. Want to know more? The reason I'm creating the MenuOrder key from AlphabetizeStartMenu.vbs is because I discovered that the key does not exist until after the user is fully logged in - well after RunOnceEx command executes. So basically RegPerm could not set the permissons on a key that did not exist. I discovered this by adding some debug code to the bottom of AlphabetizeStartMenu.vbs: oWS.RegWrite "HKLM" & runonceex & "install03\","Echo Command Line" oWS.RegWrite "HKLM" & runonceex & "install03\1","cmd.exe /k @echo " & regperm & " " & menuorder & " " & usersstring This basically confirmed that the RegPerm command line was correct during RunOnceEx by showing it in a DOS box. It also prevented RunOnceEx from completing so from the same DOS box, I simply started regedit and found the MenuOrder key was not yet created. Then I closed the DOS box and refreshed regedit every second while windows finished it's startup routines with me logged in as the new user. Guess what - MenuOrder never showed up! But it did show up as soon as I dragged an item around in the start menu. I found this very interesting. As a result, I'm not sure why removing the MenuOrder key at T-12 seems to work for some because for my install, the key already does not exist at that time anyway. I would be happy to know if you found this info useful. The End - jimanny


×
×
  • Create New...