RogueSpear

Is it in fact necessary to have your Cisco device acting as a DHCP server? I've never run across a situation like that before. In any case, it's to my understanding that RIS is fairly intertwined with DHCP and Active Directory for many reasons. Among them being that you don't want unauthorized DHCP servers and you don't want any old person performing a PXE boot on your network. If you truly need to run things like that, then you may want to take a peek at Experts Exchange. They have some of the best networking experts I've ever run across and have gotten me out of a pickle or two.

I think if there's ever going to be a Driver Pack HID that it's going to have to come with some code to go along with it, along the lines of what I mentioned earlier. The gathering up of drivers should be no problem at all. Microsoft has one each for keyboard and mouse. Logitech is probably similar. Between those two you have like 80% of the market covered (not counting the proprietary laptop button drivers). It just drives me nuts the way HID and display monitors are implemented.

Perhaps this article from Tom's Hardware could help a little. http://www.tomshardware.com/howto/20050909/index.html

Actually what should be first is the question: This BSOD happens when installing Windows XP x64? or standard 32-bit? And was portcls.sys even mentioned in the BSOD?

I had the same thing happen on a Dell Latitude laptop. Reminded me of my more carefree youth and experimentation with uh.. well anyway it also worked out in the end for me. I look at it as a sign of poorly designed hardware or drivers or both. Something else too.. I've been working with some Compaq Evo N1020v laptops (pieces of junk) that also have ATI chips in them. Instead of the 1960's inspired psychedilics though, the screen starts to get the scrolling lines. Almost like when you see a CRT screen on the news, where the sync doesn't match up. But that too goes away after the first reboot.

I spent the better part of two days trying to repack DT4 and kept on getting the same error as the screenshot pic posted above. After really looking into this closely, my conclusion is that the install routine is taking steps to protect itself and evade detection by rights management software. And this will make it extremely difficult, if not impossible, to successfully repack into an .msi file. There's another issue though. I can't say for certain, but from what I have read, it would appear as though the Daemon Tools development team is readying a "Pro" version (read you pay for it). I've seen screenshots that show a rather professional looking interface and features not even hinted at in this newest V4 release. Plus the "Pro" in my mind almost always denotes that it ain't freeware no more. Just look at DeepBurner, DVD Rebuilder, and a long list of others that were for a long time freeware before going pro. So perhaps the toolbar, while optional during install, will find it's way on to enough desktops when click happy people whiz through the install routine without reading anything.

Sorry about that.. a hwid (hardware ID) is the "code" assigned to a specific piece of hardware. Some hardware vendors, like Analog Devices, assign a different hwid to every single thing they've ever made, even if the hardware is completely identical. Using the Analog Devices example, they make the SoundMAX audio component found in a ton of laptops these days. Let's just say for the sake of argument that they make a sound chip called the AD-SM1 (completely ficticious as far as I know). Well if Dell, Toshiba, and HP all use the AD-SM1 chip in laptops, not only will the hwid vary by vendor, but it will even vary by laptop model. So a Dell Inspiron 1000 with the AD-SM1 and the Dell Inspiron 1100 with the AD-SM1 will have a different hwid for their respective sound adapters. This would be all fine and dandy if Analog Devices published a driver set that worked across their entire line, but they don't. When you get your Dell Inspiron 1000 it comes with a CD (or you can download) that has a driver install for only that specific computer. So you can see what a pain in the butt this can be. There is a link in Bashrat the Sneaky's signature for a tiny littl utility called Get_hwids. Using this will create a small txt file that contains all of the hwids found on a given computer. Using this information, BTS can see if your particular WiFi adapter has a yet undiscovered hwid that has not been integrated into a pre-existing driver in the driver packs. In order to properly get the hwid though I think you need to have the device up and running properly with the driver you have there that works. I'm sorry if this was a bit longwinded, but hopefully others will see it as well and understand the issue and hopefully start submitting more and more hwids to make the Driver Packs as good as they can be.

I'm attaching the program to this post. Here is an example of the config.txt from what I packed last: ;!@Install@!UTF-8! RunProgram="RunHiddenConsole.exe /w msiexec /i FFDShow20050803.msi /qn" ;!@InstallEnd@! Much simpler context eh? Also don't forget to UPX your 7z sfx module. What I do is rename the file to 7zSorg.sfx. Use Resource Hacker or whatever you want to change the icon and then UPX it with this command line: upx -9 -o7zS.sfx 7zSorg.sfx Then combine it all to make your switchless silent installer: copy /b 7zS.sfx + config.txt + FFDShow20050803.7z FFDShow20050803.exe I realize that you may already know some of this, but I thought I'd include a little more for anyone else out there reading the thread. RunHiddenConsole.7z

I stopped using StartX.exe a long time ago in favor of runhiddenconsole.exe. Runnhiddenconsole is much smaller than startx and it doesn't seem to have as many limitations to it.

I believe that the Cisco PCMCIA WiFi adapters were all Xircoms. Well actually I think the opposite is true. In any case, if you get the hwids for the adapter and which Xircom equivalent it matches up to, perhaps BTS could add the hwid to the appropriate driver.

Nice find, but I still don't believe you'll get the installer itself to work from svcpack.inf or cmdlines.txt. At least I've never been able to.

Using DP Sound B V5.11 the following SoundMAX controller detected as a C-Media. This is from a Compaq Evo N1020v laptop. Here is the hwid. hwids.txt

@digitalfrost, that's where I seem to be stuck as well and I have a feeling that the measures implemented in DT to protect itself against being blocked are going to make this an very difficult if not impossible repack. @MHz, having been a VBscript guy for so long now I've gathered a long list of annoyances and to tell you the truth, I found AutoIt to be a huge breath of fresh air. It is frustrating though. AutoIt can do so much more than vbs, but not everything that vbs can do and vice versa. So I have to maintain skills in both languages. EDIT: BTW, when I said I like to think of AutoIt as a method of last resort, it was not meant as a bad remark on AutoIt itself. The same would hold true for VBscript or any other language for that matter. I just hate to dig in and write code for installing a single app. I prefer to keep my scripting to system maintenance or configuration chores.

@MHz, don't get me wrong, I've used AutoIt plenty of times where I felt it was appropriate (Microsoft Student, activating Adobe applications, etc). And it certainly has enabled me to do an awful lot that I otherwise would not have been able to do. Maybe my background would clarify where I'm coming from. My initial purpose and to this day, my main purpose for repackaging applications to .msi files, is for deployment via Group Policy. Upgrading an app then is as simple as telling GP to uninstall the old and install the new. At some point, maybe about a year ago in these forums, I found a how to on making 7z based switchless silent installers. For the most part they've never done me wrong either. I've learned so many little tricks to repacking things, the stuff you need to watch out for, that I'm pretty confident in not only my abilities to repack something, but also that I know when to say when. I fully realize that there are some apps that simply aren't meant to be repacked. And this new version of Daemon Tools is starting to look like one of those apps While there are some pros and cons to every method, one of the things that drives me to my methods is saving space. I have plenty of installs that dictate using a CD instead of a DVD and 700MB is pretty restricting. Plus there's just the comfort zone I'm in with that method. I know it well, so it's what I tend to default to.

I like to think of AutoIt as a last resort myself. I can always get a smaller file size through repacking, they seem to install quicker, and are much more reliable. But when the fat lady sings, sometimes you gotta go with what works.

I'm having major grief in repacking this bugger. I've repacked literally around 100 apps and this is maybe the 3rd one to give me such headaches. The 2nd one was .NET 2.0 which I still can't get to install from svcpack.inf. I haven't given up on this yet, but it's not looking so promising either.

It may be easier to make your own driverpack for these drivers. There's a sticky that shows you how. This is the method that I use for some of the odd ball drivers I need to support. It's also the method by which another member created and posted driver packs for modems, infrared, TV adapters, etc. The Driver Pack Base was designed with modularity in mind. As long as you follow the conventions you should be all set.

What I am considering doing is making the script install the appropriate driver / utility if one of the hwids is found and do nothing if none of them are found. Of course this is all much easier said than done It's been on my "to do" list for months. I figure I could at least get it up and running to support all of the hardware that I run across regularly and if anyone wanted to send other hwids to me I could put them in the script as I get them. Some day... unless another enterprising soul wants to grab the lead on this one.

One problem that I have always had with devices that fall under "Human Interface Device" is that some of them like to install to whatever machine you're working on regardless of whether or not it's correct or not. Synaptech touchpad drivers, touchpad and touchscreen drivers for Panasonic ToughBooks, Microsoft Intellipoint and IntelliType.. they all just seem to install no matter what. I've started to see if I can collect hwids and vbscript the whole thing, but it's seeming like quite a task with the endless numbers of mice and keyboards out there.

I've been using WMI in vbs for quite some time now for a number of tasks. Unfortunately detecting hardware capabilities and properties is something where you are often at the mercy of the hardware vendor. It seems optional as to whether or not they implement proper reporting. BIOS strings are a famous example of this.

I repacked Daemon Tools V3.x ages ago and it always worked fine. I'll see if I can do the same with this one - minus the adware. EDIT: Sheesh, they make you reboot right in the middle of the install.

Yes exactly BTS. I was simply stating that the presence of RealTek drivers are indeed a part of the problem. For instance in the absence of RealTek drivers, you will not get a BSOD. In fact if there are no RealTek drivers present AND no SoundMAX drivers with appropriate hwids, you will more than likely find that Windows will attempt to use C-Media drivers instead of simply giving you an "unknown device". 1. RealTek drivers are like the explosives. 2. No hwid for SoundMAX is like the match. It goes kaboom

Do a Google search for LSRUNAS. It allows you to run a process under a different user and encrypt the password so that they aren't in plain sight within your batch file. The documentation will give you the exact command line parameters which you can incorporate into your batch file.

It sounds as though the applications you are installing write registry values to the user's registry. There are multiple solutions to the problem. Probably the easiest would be to capture those settings with something like regshot and then import the settings to the default user profile so that any new profile created on the machine will have the settings (assuming you're not using roaming profiles). There are some instances where an application truly does need to be installed by the specific user who will use the app, but this is quite rare and usually is because of some sort of encryption key creation that is dependant upon randomized data. If you get a little more specific as to what the problem is that you're facing and the ultimate goal, perhaps I or others could help out a little more.

Yes, the presence of the RealTek drivers is part of the equation here. I long ago started to remove the RealTek 97 drivers. I figure in the off chance I come across something with that particular chip in it, either myself or the computer owner can install the drivers on their own. Then I advise them to try to avoid RealTek products at all costs. I first documented this problem close to a year ago. At first I found it hard to believe myself, but after many rounds of testing, it seems rather conclusive.