Ausmith1

Procedure for adding boot support for the HP (Compaq) KGPSA-xx / Emulex LightPulse 950 PCI-Fibre Channel HBA to a Windows 2000/2003 install CD. This is very useful if you are trying to install in a boot from SAN configuration. 1) Add the following to DOSNET.INF [Files] d1,cpqkgpsa.sys [OptionalSrcDirs] svcpack 2) Add the following to TXTSETUP.SIF [SourceDisksFiles] cpqkgpsa.sys = 2,,,,,,_x,4,0,0 [HardwareIdsDatabase] ; Compaq / Emulex KGPSA-xx PCI-Fibre Channel HBA PCI\VEN_10DF&DEV_F700&SUBSYS_F7000E11 = "cpqkgpsa" PCI\VEN_10DF&DEV_F700&SUBSYS_F70010DF = "cpqkgpsa" PCI\VEN_10DF&DEV_F800&SUBSYS_F8000E11 = "cpqkgpsa" PCI\VEN_10DF&DEV_F800&SUBSYS_F80010DF = "cpqkgpsa" PCI\VEN_10DF&DEV_F095&SUBSYS_F0950E11 = "cpqkgpsa" PCI\VEN_10DF&DEV_F095&SUBSYS_F09510DF = "cpqkgpsa" [SCSI.Load] cpqkgpsa = cpqkgpsa.sys,4 [SCSI] cpqkgpsa = "Compaq/Emulex KGPSA-xx PCI-Fibre Channel HBA" 3) Add the following to HIVESYS.INF [AddReg] ; Compaq/Emulex KGPSA-xx PCI-Fibre Channel HBA HKLM,"SYSTEM\CurrentControlSet\Services\cpqkgpsa","ErrorControl",0x00010003,1 HKLM,"SYSTEM\CurrentControlSet\Services\cpqkgpsa","Group",0x00000002,"SCSI miniport" HKLM,"SYSTEM\CurrentControlSet\Services\cpqkgpsa","Start",0x00010003,4 HKLM,"SYSTEM\CurrentControlSet\Services\cpqkgpsa","Tag",0x00010003,259 HKLM,"SYSTEM\CurrentControlSet\Services\cpqkgpsa","Type",0x00010003,1 HKLM,"SYSTEM\CurrentControlSet\Services\cpqkgpsa\Parameters",,0x00000012 HKLM,"SYSTEM\CurrentControlSet\Services\cpqkgpsa\Parameters\Device","NumberOfRequests",0x00010001,0x32 HKLM,"SYSTEM\CurrentControlSet\Services\cpqkgpsa\Parameters\Device","MaximumSGList",0x00010001,0x21 HKLM,"SYSTEM\CurrentControlSet\Services\cpqkgpsa\Parameters\Device","DriverParameter",0x00000000,"EnableDPC=1;ElsRetryCount=6;NodeTimeOut=60;ScanDown=1;SimulateDevice=1;Topology=2;" HKLM,"SYSTEM\CurrentControlSet\Services\cpqkgpsa\Parameters\PnpInterface","5",0x00010003,1 HKLM,"SYSTEM\CurrentControlSet\Services\disk","TimeOutValue",0x00010001,0x3c HKLM,"SYSTEM\CurrentControlSet\Control\ScsiPort\SpecialTargetList\GenDisk","LargeLuns",0x00010001,1 HKLM,"SYSTEM\CurrentControlSet\Control\ScsiPort\SpecialTargetList\GenDisk","SparseLUN",0x00010001,1 ; Compaq/Emulex KGPSA-xx PCI-Fibre Channel HBA HKLM,"SYSTEM\CurrentControlSet\Services\EventLog\System\cpqkgpsa","EventMessageFile",0x00020002,"%SystemRoot%\System32\IoLogMsg.dll" HKLM,"SYSTEM\CurrentControlSet\Services\EventLog\System\cpqkgpsa","TypesSupported",0x00010003,7 Be extremely careful to ensure that you don't change the wrapping of lines in HIVESYS.INF, I found that if I opened HIVESYS.INF in Notepad with word wrap on, that it would sometimes change the line wrapping upon saving, effectivly corrupting the file. So turn word wrap off! Or better yet use a better text editor like UltraEdit. 4) Create the following CD structure +---$OEM$ | +---$1 | \---Drivers | +---SCSI | \---cpqkgpsa \---I386 +---SVCPACK +---SYSTEM32 \---UNIPROC Place all the extracted KGPSA driver files in \$OEM$\$1\Drivers\SCSI\cpqkgpsa Copy cpqkgpsa.sys to \i386 Copy cpqkgpsa.cat to \i386\SVCPACK 5) Make the following modifications to SVCPACK.INF [Version] Signature="$Windows NT$" BuildNumber=2195 MajorVersion=5 MinorVersion=0 [SetupData] CatalogSubDir="\i386\svcpack" [ProductCatalogsToInstall] cpqkgpsa.cat I'm not 100% positive that you have to add the CAT file to the SVCPACK.INF. Anyone know for sure? 6) Add the following to WINNT.SIF [Unattended] OemPreinstall=Yes OemFilesPath="..\$OEM$" ; See http://support.microsoft.com/default.aspx?scid=kb;EN-US;q250380 for why this must be = Ignore DriverSigningPolicy=Ignore OemPnPDriversPath="Drivers\SCSI\cpqkgpsa;" Beware that lines posted here may possibly wrap! If you paste wrapped lines into your INF or SIF files they will NOT work.

Good, I'm glad it worked out for you. Could you please post any possible differences / changes you had to make from the above posts in case someone else needs to do this in the future? I'll post another thread with the HP KGPSA settings that I use in case anyone needs those in the future.

There is a great article on "The Tyranny Of Choice" in the current edition (April 2004) of Scientific American. Unfortunately you can't read the whole article online without being a subscriber, but here is the basic lessons to be learned from it (and this is what I've been telling people for years regarding buying computers) Choose when to choose We can decide to restrict our options when the decision is not crucial. Learn to accept "good enough" Settle for a choice that meets your core needs rather than searching for the elusive "best". Then stop thinking about it. Don't worry about what you're missing. Consciously limit how much you ponder the seemingly attractive features of options you reject. Teach yourself to focus on the positive parts of the selection you make. Control expectations. "Don't expect too much, and you won't be disappointed" is a cliché. But that advice is sensible if you want to be more satisfied with life. What I always advise is to buy one step back from the "bleeding edge" of computing, you will get a product that has had the initial bugs ironed out, the price will be much better and ultimately you will be happier with it. A year or so later you can upgrade to a faster chip and more memory and still have a great system on the cheap. If you really wanted the best desktop right now, you would have already bought a G5 anyway, right?

The mp3's are on a heavily protected Samba share at work, There are about 20 of us in my division that contribute CDs to it. About 1/2 of the music is from my own CDs, most of the rest is from 3 or 4 of the others. And the PC configuration is for real, what will really get you is that I got it for free from IBM. How's that for a nice little present for spec'ing out a bunch of IBM servers I had coveted one of the T221 monitors ever since I first laid eyes on the original Big Berta LCD at the SC2000 supercomputer show in Dallas, of course the feds stepped in and bought the whole first years production, so it took a while before you could actually buy one... Imagine my surprise when my boss came in one day and said that IBM were sending us one and did I want it? Little did he know what he was giving up Needless to say it's locked to my desk now in case he changes his mind.

Yes, that about how many there are. We were re-indexing them just a few days ago... You can see a small portion of them in this screenshot from about a year ago, I only had about 50GB then. I've had to buy two 120GB drives to house them on. (They are in the window in the far bottom right corner of the screen capture)

Why not just Opera? It has a decent download manager built in. It's way faster than IE too. These days the only things I use IE for are to access MSDN and our internal ERP apps. IE just plain sucks compared to Opera.

It's been a year or so since I last used IEAK so I'm a little rusty on it... Yes, that's true but if I recall correctly, by default IE 6.0 SP1 will install a bunch of components that you may not want, such as AOL ART file support, international fonts, Flash etc. IEAK allows you to specify which of these extra components, if any that you want. It also allows for setting a bunch of other default IE settings and can update the install with the latest service packs and patches. It can be very useful in a corporate setting where a proxy is used for example or to set the location of the mail servers etc. So all in all I've found it's a useful tool to use for my installs. One thing to bear in mind is that I install on servers only, so that the defaults that I use may not be suitable for use on a standard users workstation... Hope that clears things up.

Over 35,000 (180GB) here last time I checked. I've found the program UltraTagger to be very useful for sorting and renaming older mp3s that I ripped before the days of cddb and music that I've downloaded in the past. Oh, and I normally use AudioGrabber & Lame to rip these days, I used to use RipEnc with Lame on BeOS before that.

Well the first thing that I would say is to take it one card at a time and just add the section for the card that you actually have, if that works then just copy it's settings for the rest of the models listed just in case you ever need them in the future. The Adaptec card I posted a listing for has about 40 HBAs listed, they just had a better formatted TXTSETUP.OEM file to work from... If you are not sure which model of HBA you have, use the Devcon utility to probe its PCI ID values and compare it to those in the TXTSETUP.OEM file. Use the following devcon syntax to probe the PCI IDs. This restricts the info dump to just Emulex devices (installed or not). devcon hwids *10DF* I have the HP KPGSA HBA (Which is based on the Emulex LP950) integrated into a CD at work, I'll be able to access it later and send you the exact settings I've used. No assurances that it will be the same though... Your DOSNET.INF looks fine. Your TXTSETUP.SIF should look like this though: [SourceDisksFiles] lpxnds.sys = 1,,,,,,4_,4,1,,,1,4 [HardwareIdsDatabase] ; Emulex LightPulse SCSI Adapters PCI\VEN_10DF&DEV_1AE5&SUBSYS_1AE510DF = "lpxnds" PCI\VEN_10DF&DEV_F700&SUBSYS_F70010DF = "lpxnds" PCI\VEN_10DF&DEV_F800&SUBSYS_F80010DF = "lpxnds" PCI\VEN_10DF&DEV_F900&SUBSYS_F90010DF = "lpxnds" PCI\VEN_10DF&DEV_F980&SUBSYS_F98010DF = "lpxnds" PCI\VEN_10DF&DEV_FA00&SUBSYS_FA0010DF = "lpxnds" PCI\VEN_10DF&DEV_F085&SUBSYS_F08510DF = "lpxnds" PCI\VEN_10DF&DEV_F095&SUBSYS_F09510DF = "lpxnds" PCI\VEN_10DF&DEV_F098&SUBSYS_F09810DF = "lpxnds" PCI\VEN_10DF&DEV_F0A5&SUBSYS_F0A510DF = "lpxnds" [SCSI.Load] lpxnds = lpxnds.sys,4 [SCSI] lpxnds = "Emulex LightPulse SCSI Adapters" In other words the lines like this: id = "PCI\VEN_10DF&DEV_F0A5&SUBSYS_F0A510DF", "lpxnds" should be reformatted to look like this instead: PCI\VEN_10DF&DEV_F0A5&SUBSYS_F0A510DF = "lpxnds" The [sourceDisksFiles] bit is something I don't 100% understand either, I recall reading something on gosh's site that described it somewhat though. For HIVESYS.INF I'm pretty sure that just one set of entries for all the Emulex cards should do since they are all identical anyway. What this section does is builds the device driver parameters nodes in the initial registry so that the system can boot in GUI mode, if these are wrong then you might get a BSOD. You can also get a BSOD if it can't find the driver files in GUI mode, that's why you have to have them in two seperate places seemingly. Usually the info to be put into the HIVESYS.INF file needs to taken from the OEMSETUP.INF file and reformatted. It can get a little complex here as you have to install the "Simulate" device also... I'll post the rest of this later when I get a look at the way I did it before...

You should try creating a custom CD with the Emulex drivers on the CD, that's worked for me in the past for SAN boot systems. There are various guides on here as to how to do this, if you are still unsure what to do or have problems, post the txtsetup.oem file for the HBA and I can help you with it. It's not very hard to do though when you know how... Here is a post I created a week or so ago showing how to do this for a similar card.

Drive Snapshot will save its backup files as 650MB parts by default. This isn't mentioned on the website...

That's actually reserved space for the NTFS MFT (Master File Table). You can read all about it here How NTFS Reserves Space for its Master File Table (MFT)

Well, Windows shortcuts are not the same as UNIX symlinks and so the lnk file that works on one system will often not work on another system. This is because when a shortcut .LNK file is copied to another machine, then by default the shortcut's target will be automatically updated - e.g. create a shortcut on Machine1 to C:\AUTOEXEC.BAT when copied to Machine2 the shortcut will point back to \\Machine1\c$\AUTOEXEC.BAT To change this default - add this to the registry before creating the shortcut: HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer "LinkResolveIgnoreLinkInfo"=dword:00000001 The Shortcut utility can fix these problems with existing lnk files, but I have found it to be easier just to generate new shortcuts. Here is a link to another utility that will do the same thing for you. Another option is to use a wsh script: (optional args are commented out) Set oWS = WScript.CreateObject("WScript.Shell") sLinkFile = "C:\MyShortcut.LNK" Set oLink = oWS.CreateShortcut(sLinkFile) oLink.TargetPath = "C:\Program Files\MyApp\MyProgram.EXE" 'oLink.Arguments = "" 'oLink.Description = "MyProgram" 'oLink.HotKey = "ALT+CTRL+F" 'oLink.IconLocation = "C:\Program Files\MyApp\MyProgram.EXE, 2" 'oLink.WindowStyle = "1" 'oLink.WorkingDirectory = "C:\Program Files\MyApp" oLink.Save

Actually all Windows does is take the last color in the image palette and sets it to be the Alpha channel. Just make sure that you use a palletized BMP image (16 or 265 colors). True color images won't work...

Try Drive SnapShot. It's not freeware, but you can continue to use it to restore after the 30 day trial period is up.

Because I'm running this code on Windows 2000 Advanced Server systems...

Judging on the latest benchmarks I've seen for 3Com cards, I'd steer clear of them in a server. Their CPU utilization rates were 5 to 10 times that of a Broadcom or Intel NIC. Other than that I never had a problem with one...

You could use the "Shortcut" utility from the resource kit to actually create shortcuts wherever you want them. Here is how I do it: shortcut.exe -f -t "%ProgramFiles%\SysInternals\autoruns.exe" -n "%ALLUSERSPROFILE%\Start Menu\Programs\AutoRuns.lnk" -i "%ProgramFiles%\SysInternals\autoruns.exe"

I think that we can agree to disagree and be civil about it. I still don't think that you quite get the concept of hard links though...

AutoIt works great for situations like this.

I get the distinct impression that you have no idea whatsoever of what I was talking about. Let me try to explain: In the UNIX way of doing things, efficiency is paramount. That means not having duplicates of any files on your system if it can possibly be avoided. This of course was all born out of necessity when computers had only a few megabytes of RAM and disk space and efficiency was an absolute necessity. Today people just don't care if their installer drops a huge duplicate file in the system path, most people would never notice it anyway on a 100GB drive. So unlike in Windows where there were traditionally no means to have one file be in two place at once, UNIX has two such ways of doing such things, hard links and symbolic links. Hard links are simply a duplicate entry in the inode (FAT) table that describes where a file is. So a file could exist in many different directories at once and yet have only a single instance exist on disk. Symbolic links are essentially the same thing but can span different volumes. As to placing files in the system folder, it's one the (un)written rules that Microsoft frequently break that no files should be placed in the system folder. In the UNIX world few reputable software authors would dream of placing a bunch of libraries in the system folders, instead you create an environment variable that tells the system where to find your libraries. In fact more and more Windows system administrators are demanding that applications should not place any DLLs in the system folders. Guess who the biggest culprit to blame here is though? That's right, Microsoft, they can't even follow their own rules. If nobody placed DLLs in the system folder then DLL hell would never have existed. UNIX sysadmins just shake their heads and laugh at the very idea. And as to the idea of just dropping in the two RDP 5.2 executables in the system folder and expecting them to just work when called on. Well this is Windows remember and don't you forget it! This might work on XP but I'd doubt that it will work on a Windows 2000 system. The RDP client needs to be registered in the system so that RDP files can be acted upon if clicked on and so on. Somehow I doubt that the MSTSC binary is so smart that it contains all the logic to re-register itself if it notices that it's not correctly registered... And if the next version of the RDP software installs to a different folder than it did before, that that doesn't say much for the talents of its install package creator. In fact the very fact that the 5.2 install does not correctly update the 5.1 version that's already on disk on an XP system really shows how badly this package is written. And here is the Dibert strip in question. ----------------------------------------------------------- Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live. Anonymous

Why not just use the Filesystem=ConvertNTFS line in Winnt.sif? Personally I'd be somewhat (make that extremely) wary of using any utility that didn't come from Microsoft to create an NTFS partition. NTFS data structures are barely documented and all the third party utilities for it were reverse engineeered. That's why the Linux NTFS drivers are typically read only by default... So to be 100% safe I'd recommend formatting with FAT/FAT32 (which is very well documented and well understood) and letting Windows handle the filesystem conversion. I guess that my opinions on this are somewhat colored by the fact that I build unattended install CD for servers and I can't afford to have something that "should work OK" on there. For what I do it just has to work 100% of the time. You wouldn't like it very much if the X-Ray generators computer controller was to crash and give you a lethal radiation dose the next time you go to the hospital, now would you?

I see your point, it all depends on what you are trying to do I guess... I recently saw some DOS utilities that I think would do most of what you are wanting in IBM's xSeries Scripting ToolKit. The fdisk32 & format32 utilities sound like they would do the trick. The hwdetect utility in the toolkit is also a very useful utility...

It works in Windows PE/BartPE. Why are you still using DOS?

Have a read of this page, it explains the whole deal pretty well. Bart's Preinstalled Environment (BartPE) bootable live windows CD/DVD