Search options (Page 1 of 3)

Wow, just found something very very cool for you Ghost users...   Symantec Ghost Solution Suite 2.5 now supports using a VDMK file as your image file directly, though you cannot use Ghost Explorer to open it.  But digging through the help file (yes, amazingly I'm a male IT person reading documentation, go figure), I found that there is a new switch that can be ran on GHOST32.EXE.  If you use "/AD=<full path to VDMK file>" you can specify a VM disk directly and it'll show up in your list of disks to send an image from.  This means no more booting from a DOS-mode ISO within VMWare Workstation, which means no more 100% non-throttled CPU usage.  Testing it right now as we speak and so far I'm very impressed!!

Edit:  I put this here as a response to the convo about using VMWare Converter, which didn't seem to work for me.  This isn't really a Driverpacks topic, but it's big enough news for me, and not sure where else to say it.

Well...  I was going to try an M1 install, but I don't want them integrated into the image itself (I mean, this is network repository right? lol).  It did create the QSC for me though, and saved me about 1GB of space on my server as a result when I transferred those files over.  The problem I'm running into is that DPInst is a bit... well.... "lacking" would be the word I'd use.  It doesn't seem to install drivers nearly as well as Mini-Setup does, and one thing that was overlooked when OverFlow and I were talking about this was that Mini-Setup isn't capable of having network support.  And no, as we also found out, you cannot pass a "DetachedProgram" parameter to Sysprep - it really is "Mini" when it comes to the setup, because the portion of setup that would normally run the DetachedProgram parameter isn't even initialized for this.  So there isn't a workaround for network support during Mini-Setup meaning I would absolutely rely on DPInst (or something similar if someone used a different program).  Now, one thing I am wanting to try is the program by another member on here (sorry, drawing a blank at the moment and too tired to even try to search for who it was), but not sure how well that's going to work just yet as it's definitely a work in progress at this stage.

Jaak, got a link to this "DUPEFINDER"?  Only one I see is in Linux.  I usually use Easy Duplicate Finder, but it doesn't have a setting to do a simple file name check, it actually does a true duplicate file check only with no other options for it.

Gonna give it a try...  but lets be honest, I can see what you are doing here.  You want me to go through the 3 hours of rebuilding my image to point out that Sysprep is not the way to go with deployment, aren't ya?!  lol 

What you say makes sense, but just wondering how it's going to handle things when it comes to NIC drivers since obviously if they aren't installed it won't be able to do that search path.  This might be interesting how this all goes though... never thought about doing a KTD to the network share.  Though that's going to be a major pain in the butt when all I'm trying to do is update my image from time to time... maybe I'll tell it to KTD to a "temp" Drivers share at the exact same UNC path with maybe a modification of the HOSTS file so it thinks it's going to the server, but rather pointing to my host OS, then remove the HOSTS entry.  It's a thought anyhow, and it'll store the UNC path just the same, and still pull from the same path "automagically".

My question is, why would it save 1gb on the server using M1?  Sorry, I am an M1 noob, clearly.  I don't know how it works exactly, I've pretty much always used M2, going back a couple years now.  M1 always seemed to be a lot more inefficient, but maybe I was missing the point of it.  That and I was making physical CD's rather than ISOs that are mounted which can be infinitely big (within reason of course).

Well, it appears that the drivers for the ATI IDE controller don't want to be installed over the Standard IDE drivers.  I'm going to try again using DPInst with the forced flag and with legacy mode and see if that'll let it update.  It's not a signed driver, so the hardware update wizard sees the standard drivers as more suitable.  *sigh* back at it again.  Be back later when I get a chance.

unseen, I'm going to take back what I said about the dupes, I'm getting them too it seems.  I'm going to keep my image the way it is now, but also add in the MassStorage drivers locally for use at Mini-Setup and see how that goes.  Hopefully that resolves it.  Not ideal in any way, but I'd rather see the computers using the proper driver rather than some compatibility driver.  Will post again here with my results.

Yes, you do need the drivers added to your image at some point, but you don't need to integrate your original install of Windows to make it all work.  Remember, I've been trying to find a good use for OfflineSysprep in my implementation (as it is, it was meant more for someone using WinPE, which I am not using), and the injection of HDC drivers makes it absolutely golden to me.  Is it required for me to have my image work though?  No, it's just relieving a BIG amount of work needed to maintain my images.

Before, I had to use a script to parse all the HDC INFs to get a list of paths and HWIDs.  From this list, I would have to remove all the references to drivers that are for 2000 or 2003 and not for XP.  Then I would have to remove all the duplicate HWIDs.  Add on to that, some drivers cause problems with Sysprep (such as the V and V4 folders, and even more recently the SC folder containing the AMD64 driver which can easily be removed).  All of this work is unneeded if you inject the drivers from OSP.  This method also makes it so it doesn't install services that are unneeded and that can be installed by Windows later when it's required.

Just remember, install only what is needed for your VM to work ok, then update to your Standard IDE drivers, and then make a snapshot before executing commands like Sysprep and setting up your ROE.  Typically, my snapshots are one from right after installing Windows, one from right after installing .NET (1.1 through 3.5 in my case, with reboots between each version) since that is kind of a critical point, and right before booting into OSP and injecting drivers.  Then one from right before Sysprep (actually have command lines open with all the commands I'm about to run right there so all I have to do is hit Enter... leaves very little room for error that way and this is the most critical point of your whole image), and one after Sysprep shuts my VM down.

Don't worry, if you make the drivers available, either via SysprepMassStorage or via OSP injecting drivers, so long as you have Standard IDE set, you should be ok.

lol, Yes you are correct, it was the shade, though it's WC3, not WoW3

I'm not really sure why you are seeing the dupes in there.  You said you were using VMWare, which I am using as well, so not sure where you are getting those from.  The difference I guess is I'm not integrating the DriverPacks into my install, and I would suggest you don't either if you are using a Sysprepped image.  That's not really needed as what you are planning on doing is using Sysprep to identify the basic devices and then have DPInst pick up after Mini-Setup to install all the remainders.

On my VM, I don't even have video drivers loaded, nor do I load the VMWare Tools as I don't want them to end up on every non-VM machine afterwards.  I still get to run at 800x600 on XP, though on 2000 I actually do load just the video driver for VMWare as the Java control panel doesn't function properly without at least 800x600 and 16-bit color.

I did make a LOT of headway on the DPInst on Network today though... I'll post more over there on that thread.

Just found out one other tidbit - if I run DPInst without the scanHardware flag (whether by XML tag or by command line parameter), it will make the attempt to install the driver and give me the error about it not being available until restart (even in silent mode).

And yet another thing that seemed to get me a step closer to the solution.  I removed amdk8.* from the folder.  I then added a second <subDirectory> for the CPU directory (I want to run with different parameters for this directory... get to that in a second).  I want to run on this directory WITHOUT the scanHardware flag, apparently this driver isn't PnP, so the attempt to install is effectively nil if it tries to see if it's useable.  I think the Hardware Update Wizard does it this way as well, it was the only way of installing the driver before I figured this part out.  So installing with the parameters "/c /s /path C:\D" (don't path to C:\D\CPU or that will fail, you have to specify the last directory for it to look in within the XML file, so effectively when I say C:\D it looks for C:\D\D and C:\D\CPU and only the latter one exists) seemed to install the latest driver fine.  amdk8.sys appears to be an old driver while amdppm.sys is new and "should" work on all AMD CPUs, K8 or better.

Now the only problem I may have is it might try to install this driver on a non-AMD system.  I'm going to try this out within the next couple hours.

lol.... and TOTALLY unrelated to anything, everytime I look at your username I think "I go unseen...."   Guess the game where that is said repeatedly.

I had thought about an old driver as well, but then we're losing support for the newer CPUs, which also defeats our purpose.  I might write an email to AMD and see if we can get any reasonable fix for this as I'm sure they would want as much support for their products in large environments as possible.  I might even look at the INFs and see if they have a simple syntax error or some such that utilities might be a bit more sensitive about.