RogueSpear

HE LIVES!! Welcome back buddy.. good to see you again

The problem is that the RealTek NIC drivers do initialize the TCP-IP stack in time for the machine to authenticate to the domain. What ends up happening is that machine GPOs cannot be processed, including running machine startup scripts defined in the GPO. I've had this happen on multiple domains, with different generations of RealTek NIC and NIC drivers. The problem has been documented by others as well on various web sites including Expert Exchange. The latest gen of RealTek NIC and the latest drivers to go with them go one step further. It takes a full 45 to 60 seconds after the CTL-ALT-DEL screen appears before you can even log in using a domain account (provided the account's credentials aren't already cached). No amount of tweaking service dependencies seems to fix the issue either.

Are you using roaming or non-roaming profiles? I used to use roaming profiles (decided they were way more trouble than was worth the effort). It can be done either way. I use scripting to copy down the ntuser.dat file.

This is a general rant, but you may learn a thing or two... In the past I have railed against RealTek for both their NICs and audio systems. That was quite a while ago and pertained to hardware that was often two generations behind what's current today. Well today I am saying this - they still suck. And not just a little bit either, they suck a** big time. It used to be that I swore on Gigabyte mobos. So much so that I built my own personal system using one. Well it looks as though they've cheapened up and starting using all this RealTek garbage. Let me state this as plainly as I possibly can. If you are installing computers that will be a member of a domain then for God's sake do not use a RealTek NIC. It got to be so bad that I went out and paid a good penny for a dozen 3com PCI NICs. It used to be with RealTek you had to use the Microsoft supplied drivers in XP for it to work right. Well with these new ones, the MS drivers don't work. You must use a RealTek driver and those drivers will not work right. I'm still going through a nightmare with the RealTek HD Audio, trying to get that to install without my intervention. All of this makes me incredibly nostalgic for the days of the Intel BX chip set, Intel Pro 100 NIC, SB Live value audio (good enough for corp use), and the trusty Matrox G400 Dual Head video adapter. The dozens of computers I have out there running this exact configuration have been rock solid since before XP was even officially given a name. I don't know what is going on lately with these companies like Analog Devices, RealTek, etc.. heck even nVidia can't seem to get mobo chipset and RAID drivers to work worth a ****. And don't even get me started with ALi, SiS, and VIA If you want reliability Intel seems the only way to go. I don't work for Intel or even own any of there stock (unless my mutual funds buy into them). Just relaying my personal experience. If you want it to work the first time, everytime, Intel is the only vendor who has given me that experience. If I ever go postal, I've got my list of third rate vendors who might get a visit from me.

Ok, the WINNT.SIF file method didn't work for me either. BUT, it appears as though DEP isn't yet functional at the svcpack.inf stage of setup. Through lots of arm twisting and fiddling around, I actually managed to make a perfect switchless silent installer of Adobe Audition. Perfect except that, just like the original installer, it generates a DEP event. But not from svcpack.inf, which is where I install about 98% of everything anyway. So my immediate problem was solved and if I do end up needing to diable DEP, I'll use the command line provided by Gee. Thank you to everyone who helped!

Well... it's particular to the way I set up my RIS build! Once I's compressed a couple of key files everything worked fine (these files are usually compressed and I needed to expand them to perform some operations on them). Thanks, Andy ← That same mistake has cost me at least a few years off of my life

Yea, I would personally recommend against using M3 at this point. There was a time when it was viable, but there's just too many drivers now. For RIS I always use M2 which works without a hitch.

Just for troubleshooting I would rename any other .sif file to .bak so that the indended .sif file is the only possible one to be used. If it still isn't working, then something more fundamental is wrong. Do you have more than one RIS image installed?

It took 2.2 seconds for me to get an answer. Thanks! Seeing that this isn't documented in the deploy.chm, I don't feel so bad for not finding it. Couldn't find a thing about it on Microsoft's site either. They must really not want you to know about this one.

I've run across this problem a couple of times now where an installation routine that uses the windows installer will trigger DEP. DEP then produces a dialog box in which you have to acknowledge the event. I know you can disable DEP by editing the BOOT.INI file, but what I would like to do is make this setting integrated into my installation. So far as I can see there is no BOOT.IN_ file in the i386 directory. And doing searches I haven't been able to find any entries within the .hiv files. My gut tells me there must be a way somehow to get around the default "optin" in favor of "alwaysoff". Any ideas?

Talk about one heck of a bloated pig this thing is. I think that the way to do this one is a complete repack. Should be able to cut down the size to about a third or even smaller.

It might help to know what got your computer in this situation. Did you install any repackaged applications? This happened to me once when I made a repack of Winamp and didn't strip out a registry entry pertaining to the CD-R drive before compiling the package.

Now why the heck didn't I think of that? Ok, now I'm off to experiment some more...

That's an interesting take on determining Laptop vs. Desktop. What I've found in my personal experience is that your major brands - Dell, HP, Gateway, Sony, Toshiba, etc. - reliably return an appropriate chassis value. The off brands that don't return the value correctly, unfortunately also tend to give you bogus returns when you check for SODIMMs. Another issue is that depending on how close to the ACPI spec a manufacturer adheres can have quite an impact on what you'll find for a battery. Lastly, if you simply include the expansion chassis as a hit for laptop, you probably wouldn't need to do checking for overriding values.

I'm currently working on using PnP identifiers for the purpose of installing drivers and applications that are for the proprietary keys on specific notebooks. In one environment, there are four different models of HP-Compaq laptops and each one has it's own "One Touch" keys Not too mention the couple of Gateway models they have as well. Makes things a pain in the rear for sure.

No, actually PnP would not be better in this circumstance. For this particular client, if the computer is a laptop then it should have the AirCard and VPN client installed. If I went to a PnP based routine here it would only complicate matters. There are indeed times when the only thing you want to determine is the formfactor of the unit.

I think that you need to have a base image on your RIS server prior to creating the RIPrep image. RIPrep was essentially the inspiration behind Microsoft creating the grovler service. The idea is to never have a duplicate file on the partition. So if you have your base image, and let's just say the i386 directory is 500MB (to make things easy). Your RIPrep images will differ only in the application installs and configurations. So for every image you are "saving" 500MB of hard drive space per image. And let's say two of your images contain essentially the same MS Office install, then you'll save that amount of space as well. In the end I believe you need this base to get things started.

Yes I do want to install the software no matter what. We have a fleet of notebook computers which outnumbers the AirCards. But they all need to be outfitted to run the AirCards. I did some major tweaking to the AirCard msi file - like removing the Network Access Monitor and it runs so much smoother than the stock install. It's really working out nice.

Like a moron, I never ran the script on a desktop PC, just laptops Looks like getting rid of the End Sub statements got it going. The original script has been edited to reflect that.

I recently performed a disc based unattended on a Dell Inspiron 6000 laptop. Everything was going just ducky until RunOnceEx. I run so scripts at this time that take a very long time to complete. It's not uncommon for my first round of RunOnceEx scripts to last over an hour. Well the darn thing went to "sleep". Luckily this happened during an AutoIt script and when the laptop was turned back on it was right at the same spot. The AutoIt script had to be ditched in favor of manually going through the remaining steps of that stage, but it all worked out. The problem is that this obviously removed a great deal of the "unattendedness" of the install. I'm unable to get my hands back on this unit to tinker around and fix the issue myself. Further, I can't seem to recreate the problem with anything I can get my hands on. So I'm curious.. is it possible to change the power settings with a registry import at cmdlines.txt and then change them back again with another registry import as one of the final steps of the install? Like I said, I'm unable to sit down and hammer this one out because I don't have the hardware to do it. Just wondering if someone else has already tackled this issue.

No, it does not. Just manually enter the ip address or the domain name (risserver.mydomain.local) when you click on Add Server in the DHCP snapin.

I ran into a problem where I wanted to install Sierra Wireless AirCard software and the Cisco VPN Client on only computer that were portable (makes sense right?). So I came up with a fairly simple script to determine the computer type and then take appropriate action. I made switchless silent installers for the software to make things easy on myself. As I usually do, I made this into a subroutine for easy integration into your own script. I hope some of you find this to be of use. Dim ws Set ws = WScript.CreateObject("WScript.Shell") Sub InstallVPN Dim strComputer, objWMIService, colChassis, objChassis, strChassisType strComputer = "." Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2") Set colChassis = objWMIService.ExecQuery("Select * from Win32_SystemEnclosure") For Each objChassis in colChassis For Each strChassisType in objChassis.ChassisTypes Select Case strChassisType Case 1 'Other Case 2 'Unknown Case 3 'Desktop Case 4 'Low Profile Desktop Case 5 'Pizza Box Case 6 'Mini Tower Case 7 'Tower Case 8 'Portable ws.Run("\\MyDomain.Local\DfsRoot\Software\AirCard.exe") ws.Run("\\MyDomain.Local\DfsRoot\Software\CiscoVPN.exe") Case 9 'Laptop ws.Run("\\MyDomain.Local\DfsRoot\Software\AirCard.exe") ws.Run("\\MyDomain.Local\DfsRoot\Software\CiscoVPN.exe") Case 10 'Notebook ws.Run("\\MyDomain.Local\DfsRoot\Software\AirCard.exe") ws.Run("\\MyDomain.Local\DfsRoot\Software\CiscoVPN.exe") Case 11 'Handheld ws.Run("\\MyDomain.Local\DfsRoot\Software\AirCard.exe") ws.Run("\\MyDomain.Local\DfsRoot\Software\CiscoVPN.exe") Case 12 'Docking Station ws.Run("\\MyDomain.Local\DfsRoot\Software\AirCard.exe") ws.Run("\\MyDomain.Local\DfsRoot\Software\CiscoVPN.exe") Case 13 'All-in-One Case 14 'Sub-Notebook ws.Run("\\MyDomain.Local\DfsRoot\Software\AirCard.exe") ws.Run("\\MyDomain.Local\DfsRoot\Software\CiscoVPN.exe") Case 15 'Space Saving Case 16 'Lunch Box Case 17 'Main System Chassis Case 18 'Expansion Chassis Case 19 'Sub-Chassis Case 20 'Bus Expansion Chassis Case 21 'Peripheral Chassis Case 22 'Storage Chassis Case 23 'Rack Mount Chassis Case 24 'Sealed-Case PC Case Else 'Unknown End Select Next Next End Sub InstallVPN Please note that I have no clue at all what some of these chassis types are. They're what I found on Microsoft's WMI SDK web site. Also this script is adapted from a RIS install routine, but you can obviously change the path to suit a local source.

I read your post in a little bit of a rush, but from what I could gather your difficulties seem to lie in DHCP authorization. As you know, you have to authorize all DHCP servers in a forest. This is to prevent the neophyte down the hall from sticking up a DHCP server without the admin knowing about it. What I've noticed on a few occasions is that when someone is setting up RIS for the first time, they forget to authorize the RIS server in the DHCP management tool. Even if your RIS server is not actively running DHCP, it still needs to be authorized since it is what your clients are booting to. EDIT: You can authorize a RIS server just by selecting "Add Server" in the DHCP snap in and then authorizing it. In my main shop I have RIS running on a member server seperate fromt the domain controller that DHCP is running on.

One thing that drives me nuts is that every hardware vendor feels as though they have some sort of divine right to populate my tray area with useless icons. Particularly in an enterprise environment, I don't want end users tinkering around the settings, possibly generating a help call. I'm hoping that this thread can become a repository for registry tweaks that disable tray icons. That's it. The ongoing series of reg tweak threads get way too polluted with discussion and other detritus. So to start off with I've located the reg entries for the Intel Extreme Graphics series 1 and 2 adapters: [HKEY_LOCAL_MACHINE\SOFTWARE\Intel\Display\igfxcui\igfxsrvc\TrayIcon] "ShowTrayIcon"=dword:00000000 ; Intel Extreme Graphics - Disable the Tray Icon [HKEY_LOCAL_MACHINE\SOFTWARE\INTEL\Display\igfxcui\igfxtray\TrayIcon] "ShowTrayIcon"=dword:00000000 ; Intel Extreme Graphics 2 - Disable the Tray Icon I would particularly love to get the reg entries for all of the substandard sound chips that people are tossing into notebooks these days.

While I don't have a familiarity with setting up SonicWall products, I've heard almost nothing but praise for them, especially from my friend who helps me out with the PIX implementations. It's sort of a funny story for me though. I had a client who knows a little.. enough to be dangerous. He went out and bought these Linksys end points and only then asked me to set them up. Of course I groaned heavily when I heard "Linksys", but you know they really work pretty nice and have been solid to boot. That's my own little story