cn0saj

I have also been trying to get nero to do an unattended install recently. I used to use /qb /norestart and it worked so well. Ahead changed something in the latest release which basically means setupx ignores the /norestart parameter now as we have all found. I have sent them a technical support request to ask for it to be fixed and asked why this is so but I don't expect an answer anytime soon. Also I have run into another problem - yep the same as most of you have found missing cabs.... The problem appears to be something weird with the nero setup. When you extract the package using the distro setup (ie executing the exe file) there is 453 files in the cabs directory. When I use winrar or any other archive utility to look or extract the files I can only ever see/extract 338 files???? They are double packing some cabs (the missing ones) but I cannot find where the extra ones are initially stored. They are not packed using rar, cab or any obvious format. The problem is the second level of decompression happens in the setupx cycle by the looks of it. The whole point of our mods is to bypass this setupx as the /norestart is not honoured by this layer (and hence any layers underneath) I have no idea why they would do this other than to stop people screwing with their distro's. The only solution really is to run nero once using the downloaded setup until the MSI install starts. Capture the files from the temp dir and package them up into a new rar archive. You can also capture the missing cabs, re-add them to the nero distro and modify the post extract execute command to run the msi install directly which is what has been previously described above basically.

Thats a really great idea. Unfortunately I had already thought of this but forgot to mention it This should have appeared before the first step above. ie. Before even allowing windows to use its internal driver I tried a driver from the LG website which would suit this device - which is always my primary preference. Unfortunately it worked no better than the windows shipped one. On investigating the two they were remarkably similar....

I have recently come across a problem with my current unattended software installation procedure and am looking for some ideas of where else to look for a problem or if anyone has seen this before. Basically we have an established unattend procedure which works well and have always had the display set to 1024x768x32 as a minimum using the [Display] part of the std windows unattend.txt procedure. After recently changing the monitors on one of our systems (we used to run some cheap no name brand and have now attached some LG Studioworks 995E 19" displays) - each time we do a rebuild the system defaults to 640x480x32 rather than out chosen resolution. Unattend is running a XP with slipstreamed Sp2. We are using OemPnPDriversPath driver install procedure for the forceware 81.98 but changing back a version doesn't alter anything - we have already tested it. The unattend procedure works fine if the no-name brand displays are attached but not if the LG ones are. (We tested this on the same PC with 2 rebuilds) The LG displays are detected correctly and assigned the internal windows drivers. The no-name monitors default to the "Default Display" hardware driver. Thinking this might be the issue I edited the inf file in the windows build files to remove the LG 995E drivers from the MS inf files. The LG monitors defaulted then to "Plug and Play Monitor" but still behaved the same way. I then removed the PnP monitor class and now windows defaults to "Default Display" with the LG displays as well but it still doesn't correct the resolution not being assigned the correct params. We have tried clean rebuilds of the system on each test described above but still can't determine why the unattended install behaves in this way. The LG displays are 19" and have a max resolution /colour depth / refresh of way above the 1024x768x32@75hz specs we are setting in the unattend - but the unattend does not seem to be able to set the required parameters or is being overriden by something. We can change to these specs after a rebuild with no issues and all seems to be ok, but it stuffs up some of our other apps if the resolution is set too low to begin with. The driver tree contains no other LG drivers of any sort and has been static along with the unattend build files and scripts during this whole ordeal. (except for inf file changes as described above) This can also be verified as the old displays still work correctly when attached to the PC and an unattended rebuild of the PC done.

I got a chance to try this yesterday from a clean system install but I still have the same problem. What I neglected to mention from my last post and since realised probably contributes to the problem is that the user which cannot open winamp files by using double click is not the original user who installed winamp. It works fine on the user which originally installed the winamp application. (They both have the same permissions however) Let me know if you need any more information to help solve this problem. Maybe something is written to HKCU which is not transferred across to the new user???

I am having this weird problem with winamp at the moment. I am having trouble opening media files... I have the association set ok and media files have winamp icon. and even say they are "Winamp media file" I can do "Rightclick on file, Open With and Choose Winamp and its a recommended program (media player is only other one)" and it works fine When I double click on a media file winamp will not launch and open file. If I open winamp application with no file open and then do the double click on media file it works fine. It appears there is some problem launching winamp on the double click action. I searched around and fiddled a bit with this but was unable to find a solution??? Anyone got the same issue. I am using the Winamp512.msi file to install with xfull=1 option I also am logged on as Admin as well and have full perms to the winamp program dir... Oh I might also add its not corrupt media file, missing codec etc... The standard demo winamp mp3 also has this issue.

I am wondering if anyone has encountered a problem with diskpart and removable storage devices. I can't seem to remove a mount point from usb mass storage device. Here is the problem in a bit more detail... When running my winpe script to setup systems I run into a issue when the system contains more than one CD, HDD or someone has left a USB mass storage device attached, or doing a RIS install. We clean the first disk in the system in the prep process so that kills any paritions on the system disk. Problem is winpe automatically mounts additional storage devices other than its system volume (mounted as x) as c d e etc.. When we partition the target system disk we create two partitions c & d and assign mount points so we can do a windows unattended install to the drive. For extra CD/DVD drives we found if we put the following commands at the start of the script it would temporarily clear the mount points while in the winpe session so we could do what we want select volume c remove select volume d remove Problem is this does not work for usb mass storage devices!!! If either c or d are a usb mass storage device I get the error "The letter you specified is not assigned to that volume" Doesn't really make sense since I did select volume C remove which drive letter is it talking about - confused???? Is this a bug in diskpart???

I have the very same problem. Any solutions yet? I don' t want to integrate WMP10... The file is present on the HDD btw., the installer seems trying to overwrite it causing that error. At the risk of being a pain I will report that I have the same issue too. I also noticed that the winamp agent shotcut is "WnampAgent" not "Winamp Agent" (needs a space) Also the "User Information" dialog appears when starting, playlist and library are turned on by default and also a message appears about asking to scan system for media. Is it possible to stop these starting up in an enabled or visible way but still installing. I have just upgraded from the 5.08 install so maybe that is the issue. (complete uninstall first) Is this the same for everyone else or does it happen from clean builds also.

In my research to try and get a WinPE CD boot disk working for the nforce 4 network controller I did find a solution for the RIS problem. I don't know if it works because I haven't setup RIS yet but I will be in the near future. There is two parts. Apparently the PXE ROM needs to be at a certain revision as there was a bug in the earlier ones. From my understanding this covered pretty much all m/f (at least abit, msi and asus). I would guess that most have it fixed in their current release BIOS img. I can find out the specific PXE version it was first fixed in if you PM me. The second part is that there is a specific driver for RIS and the nforce released by nvidia. The driver was NDA and I don't think a public version has been released. It has however been leaked onto the internet and is posted on some driver site but its not obvious to find at all. It took me around 4 hours of internet searching to find.

We just did a deployment/install of SAV 10.0.1000 over the top of whatever was existing. The updated SAV software is available for licenced customers to download via electronic distribution from Symantec

Thanks for the release of winamp.msi!! Its so much easier to use the MSI than to try and use an AutoIT script... However I have one question... When you install winamp using the msi it appears to only create shortcuts under the current user profile. This means when someone else logs onto the machine the shortcuts don't follow. I am wondering if this can be fixed with some sort of option or if I have just missed some msiexec switch.. As a side note I have just ammended my script with a couple of lines to copy the desktop and start menu items across to the "All Users" profile. The problem is though that the shortcuts actually use an icon resource which is located in the path "C:\Documents And Settings\Administrator\Application Data\Microsoft\Installer\{556C9B0C-9BAC-48AC-AC3E-41326A4356F8}". This means the icons don't regen when a new user profile is created and you get blank (but usable) shortcuts. This is caused from what I can see because the default icon path is "%APPDATA%\Microsoft\Installer\{556C9B0C-9BAC-48AC-AC3E-41326A4356F8}\NewShortcut1_556C9B0C9BAC48ACAC3E41326A4356F8.exe" which evaluates to the original user who installed the program not necessarily the user who is having their profile created. If the current user can't see inside the profile of the user who originally installed the program the blank icons appear. A fix for this would be to change the installer resource location from "%APPDATA%\Microsoft\Installer\{556C9B0C-9BAC-48AC-AC3E-41326A4356F8}" to something like "%SYSTEMROOT%\Installer\{556C9B0C-9BAC-48AC-AC3E-41326A4356F8}" I have noticed that many programs actually take this approach. Maybe you can consider this for a later build of your msi? Or you could be really nice and re-release it with the update!!!" The workaround for this is just to use a script at the end of the install to move the installer resource and just delete & re-create the icon shortcuts manually but that seems like the hard way around something the installer should be doing right in the first place???