RogueSpear

Try adding this to your WINNT.SIF file: [Data] AutomaticUpdates=0

I'm not sure that you could ever safely conclude anything when it comes to the half baked device drivers that some of these hardware companies spew forth, but I've been using the DP's for quite a while now and at one time was plagued with the dreaded portcls.sys BSOD. The only way I could get rid of the problem was to eliminate those RealTek Drivers. I don't know how I deduced this (it was a while ago), but I found that when performing a UA on a machine with an Analog Devices sound adapter that did NOT have the HWIDs in place, a BSOD would result with the RealTek drivers present. Without the drivers, the Analog Devices chip simply would not install, but at least the setup continued unfettered. Now how in the world a RealTek driver could so completely screw up an install if another company's sound adapter was present is beyond me. You can never rule out demonic posession.

@dgould393, the line that you quoted is for attaching to the server via WMI for the purpose of restarting the BINL service. You won't find a directory root\cimv2 on the hard drive. It's a reference to the tree structure within WMI. You can use WMI for about a million different things and the beauty behind it is that the syntax is identical whether your manipulating something on the local host or a remote host. @jguderian, I'm having a hard time getting a handle what exactly is going on. Have you run the RVM Integrator against a standard XP SP2 source? Meaning not a RIS image, just a plain old SP2 source. If it's not working in that fashion, then you're having some issues I can't really support. You may want to pay a visit to RyanVM's forums and see if there are any solutions over there. EDIT: I didn't write the integrator program, Siginet did, however from what I've seen and everything that I've read, it doesn't seem even remotely possible that the Integrator would mess around with your local Windows directory unless you somehow pointed it to go there.

If you remove or simply rename the RVM Integrator so that AutoRIS doesn't see it, it will skip that section entirely.

I always remove the RealTek driver myself, though I do leave the RealTek HD drivers. It doesn't seem to be as much of a problem these days as the vast majority of HWIDs for Analog Devices sound chips have been included now. But just for good measure I do remove it as I've yet to encounter a system with that particular RealTek in it.

It's not a DOS application. There a service that runs in the background and you use a GUI client to access the remote computer. My personal suggestion is to install the service ahead of time and then configure it. Trying to manipulate the settings ahead of pushing out the service has always been a little troubling for me. But you can configure it for completely silent operation. Just like when you're going to give a presentation, test it first. Get all the unexpected stuff out of the way before going to production.

Off hand it sounds to me as though you have some NTFS permission problems going on or there's a lock on a file / directory. I am wondering if you could outline your entire procedure for me and specify what Windows Server version you are using. I'm curious to know if everything is working ok before the RVM integration. Are you running AutoRIS using a domain admin account?

I always use DameWare NT Utilities for monitoring a system when there are behavioral issues being investigated. It's not free, but it's easily one of the best networking admin bargains I've ever seen. Like BO2K mentioned above it does take a little bit of configuring, but configured right, most novice users would never know it's running. Also like BO2K, the DameWare Mini Remote module is now picked up by most AV products. I can confirm that Symantec Corp does. Be careful with what you're doing though when it comes to spying on someone. Make sure that you're in compliance with the laws of your Country / State. In the USA, depending on where you are located, you could find yourself in far more trouble than whoever it is you're monitoring if you don't follow proper procedure.

I actually do a bit of all three types of scripting - pure VBS, VBS w/ AutoItX, and pure AutoIt. I've found circumstances when any of three are most appropriate believe it or not. What I was really asking about was pure standalone AutoIt and you provided just what I was looking for I have gone into the AutoIt forums searching for answers, but in all honesty the majoriy of discussion there seems way over my head. Most of what I've learned in VBS has come from trial and error but also four different books on the topic. I really wish there was the same offering in publications for AutoIt. That way I wouldn't have to keep on pestering you guys Thanks for the help!

I made a silent switchless installer of this one. What a pain in butt too. First I had to tweak the msi file so that it would let me make AIP and while I was in there I nuked all of the foreign language parts. You need to go under custom actions I believe and there's an action under Admin Install to delete. I don't remember the name of it now, but when you're in there it's obvious which one to delete. Then I found that you must pass the serial on the command line, you can't put it in the msi file or even pass it through using an mst file. So my last issue was the dreaded DEP problem. Well I discovered that if I call the switchless silent exe I made from svcpack.inf, that it installs without any problems. Apparantly DEP isn't yet active at that stage of setup. Here's the best part - the install exe file is only 15MB.

What I did was use the msi version of the Cisco VPN installer. First I made an AIP, then tweaked the msi file using AdminStudio, and finally turned the whole thing into 7-zip based switchless silent installer. This way when you execute the file, it will decompress to the temp directory on the local hard drive and install from there, bypassing the network disconnect problem. The whole thing compresses down to 4.15MB too.

Ok, got a couple of questions of my own: 1. I'm rather well versed in VBscript and even though I have done a little bit of AutoIt here and there, I'm still somewhat of a noob in AutoIt. In VBscript I like to do things in subroutines whenever possible. This makes it easy to cut and paste code from one script to the next and it also makes it easy to disable entire sections of a script when testing things out. Does AutoIt have subroutines? Or are functions the closest thing I'm gonna get? 2. When using AutoIt to interact with applications, sometimes there are two or more possibilities as to what dialog box will pop up next. Example: An application will run in one fashion if there is an internet connection, and in an entirely different way if there is not. For instance you might get a particular dialog box warning that there is no internet connection available. What is an efficient manner of coding "if this dialog box appears next do this, otherwise do this instead."

The version you are trying to use is unable to process the integrator.ini file. This functionality was only implemented starting with V1.0 RC13 Beta 4, though that version did have an issue with addon packs. The newer V1.0 RC13 Beta 6 corrected that problem. You can find the latest versions of the integrator in the Members Only forum on Ryan's site. All it takes to become a member is registration on the site. Also thank you for pointing out the problem with the NIC_Drivers folder. That's an oversight I will try to correct tonight.

Yea try that thing, even though it has nothing to do with network monitoring. I hate it when people whore out their own stuff.

I usually don't have DHCP running on the RIS server myself. I'm going to have to do some fooling around with psservice and also detecting the server OS. Shouldn't be overly complex, but I'd certainly like to know if anyone else is having this problem on a 2003 server, whether it's SBS or not. Also, I think in the next version I'm going to include a .SIF file for the end user to modify to their needs and AutoRIS will copy it down to the Templates directory and at the same time delete the default .SIF file.

Ok, so according to your event logs, did the service restart? If so, I'm guessing there's a WMI issue here and this would suck, but I suppose I could call on psservice for 2003 servers instead of keeping it all internal. Would add yet another file to the download.

The account you are using to attempt the service restart on the RIS server from your workstation is assigned to the Domain Admins group, correct? If so maybe try this: download PSTools from SysInternals if you don't already have it and run this on your workstation against the RIS server from a command line: psservice \\RISSERVER restart binlsvc Do not enter in a username and password. This way it will use the credentials of your user account that you're running AutoRIS from.

@krismark Here is a line of code: Set colServiceList = objWMIService.ExecQuery("Select * from Win32_Service where Name='BINLSVC'") If you notice the shortname for the service is defined as BINLSVC. I am wondering if you could check for me what the BINL service's short name is on 2003SBS. Perhaps it is different? If so maybe I can implement server version detection and change the shortname based on that. If the shortname is the same, then I'm truly stumped and will have to investigate further.

@krismark, I want to thank you for your patience and tenacity in continuing to test this out And just so I can make it official.. this was an install image created with Windows 2003 SBS correct?

Version 1.02 has been posted. Along with the changelog in the first post, I did a little editing here and there of the instructions to reflect the changes and to hopefully make it a little easier to understand. I put this version through a lot of testing today and it ran perfect in every instance. The only major issue I could forsee is a possible file copy error or folder delete error due to the OS having a lock on something. It seems things have to coded just so and in just the right order to avoid this problem. Like I said I did a LOT of testing, trying my best to envision all of the various snafus that could come up. I'm sure that I couldn't have caught them all. I'm going to start work on implementing some minor new features and adding in some code for using an .INI file that AutoRIS will use for settings. This way people won't have to actually edit the script themselves (though you're free to if you like). One thing I would like some feedback on is what features would you like to see? I was thinking of including a .SIF file with the basics in there and having AutoRIS edit the .SIF file based on user entries in the .INI file. Check out the sample .SIF that I included in my unattended RIS guide and see what you think. In case anyone was wondering why I don't have AutoRIS launch nLite for the user. nLite requires that the "working directory" or if you check out a windows shortcut, the "Start From" entry, be defined. This is something that I have been unable to figure out in VBscript. I'm going to see if AutoIt has any kind of facility for this or for that matter, does this by default. If AutoIt can do this I could implement the solution very quickly by calling AutoItX.dll as a COM object through VBscript. What this means though is that the end user would have to register that dll file before running AutoRIS. What do you all think about that? The other solution would be to completely rewrite AutoRIS to AutoIt (say that 10 times fast lol). Well in any case I hope that V1.02 works a bit smoother for you patient souls who have suffered through the first version.

Ok, maybe this is where I'm being led off path.. One thing I do remember specifically is that portcls.sys is NOT in i386 after an RVM integration (unless this was changed via updates to the RVM Integrator recently). I remember this because inspecting the latest RVM pack, I noticed several new .SYS files and for some reason they were not cabbed, when so many other files were. What I discovered was that these new .SYS files were not being dumped into i386 like I had though (because I couldn't find a single one of them). So this led me to driver.cab and tada, there's portcls.sys. They say the mind is the first thing to go and in my case it's proving all too true. Now for the duplicate entries in txtsetup.sif and dosnet.inf. I can confirm that this has been an issue for a couple of BASE versions now. I've always gone in and deleted the first set of entries I come across after verifying that there are indeed entries further down the line (where RVM placed them first). I don't know if the duplicate entries do indeed cause any issues, but with so much to keep track of and with so many things that can go wrong with an unattended install, I usually err on the side of caution.

Ok, I had V1.01 up for a short while when I discovered a not so nice error in my code. For the user who isn't versed in VBS, this would render the script pretty much useless since they couldn't fix the error. I'm currently running a test of what should be V1.02. My efforts have been hampered today by my main job (imagine that) and then an emergency call from a client. No rest for the weary. Please keep in mind too that when I run through a test it can take well over an hour to complete. And then some more time to analyze the results. So I'm going to make every effort to get 1.02 out the door tonight. I just want to be a little confident that there aren't any major issues with it. Version 1.0 had been running so smooth for me for like a week. I must have run 20 different tests with it and had no problems at all. The slew of issues that were brought to my attention within hours of it's posting kind of shook me into reality and made me realize this could be more challenging than I had once though.

I just noticed something. For the constant RVMEXE, you put in the path and filename. It should be the filename only. Slightly further down the script is this line: RVM = RISTEMP & "\" & RVMEXE & " " & RISTEMP & """\integrator.ini"" /integrate" AutoRIS expects to find the RVM Integrator (and the RVM Packs) inside of RISTEMP. As you can see from the line above, adding the path to the constant will create issues. Also you are using too old a version of the RVM Integrator. The minimum version level is specified in post #1.

I can't tell you all the details because I just can't seem to follow the entire path of operations here, but I think what RVM is doing is inserting the hotfix into driver.cab. That's why you don't see any of the related hotfix files within i386. Now as it turns out, the .CAT file seems to be needed for this particular hotfix, so the next RVM release should contain it. What I don't know is if this is going to change the way in which Ryan integrates it (whether or not it can be buried inside of driver.cab). All I know for sure is that this hotfix is one pain in the rump. Especially if you're dealing with crap with like a RealTek HD chip.

Ok, just got into work and I'm going to need some coffee before any major work gets done, but I should have V1.01 posted later in the day (it's 8:00AM now where I am). @krismark, don't ya know any better than to run version 1.0 software from a guy who's avatar looks like mine? Ok, seriously.. My XP CD is actually a Gold + SP2 slipstream. I think what I'll do is change the code to only look for and copy WIN51IP.SP2 since that seems to be what we're looking for here. I'll have to test it though to see if both RVM and nLite are satisfied with only that file. Also I'll change the code to leave the tag file in place for future use. I think I was a little too aggressive in my cleanup efforts. Regarding filecase.exe - just a plain old oversight on my part. You can try to get everything down the first time but it never fails, always forget something. In case you're wondering, filecase.exe is actually needed for the proper operation of the script. Some of the compression routines run on the basis of file extension and they're case sensitive. My personal taste is to have everything in one case or the other as it makes it easier to go through a directory with thousands of files that way. So I opted in favor of filecase.exe rather than putting in redundant code to process each file extention twice (once for each case). Regarding your last screenshot error, I think it was line 227. I'll have to put a note about that in the first post. You must be running AutoRIS from an account that has the right to attach to WMI and restart the BINL service on your RIS server. The permission denied error I can only assume was due to an account with insufficient privleges or there was a WMI problem on your computer. Like a lot of programs and general procedures regarding the processing of an install image, if something goes wrong towards the beginning then it all goes to hell. I think this could have something to do with your final problem of NIC drivers not being found. Rest assured I'll get a revision up soon.