RogueSpear

I've put together a nice little MD5 function in VB2005 if you don't mind using that instead of CRC32.

Check out this link which will give you a links to information that should help you out. http://www.microsoft.com/technet/desktopde...En_5.mspx#EFUAI http://www.tomspeirs.co.uk/bartpeonris.htm

This has been brought up several times now and I've yet to see a definitive answer or solution. I wish I could help you out, but I'm also looking an explanation. There has to be someone out there that does this on their workstations.

There's an entire forum dedicated to just this over at codecomments.com. Why don't you look over there. It's swimming with talented programmers. There's a basic protocol for hiring out programmers on mercenary duty and this isn't it.

This is my cmdlines.txt: [Commands] "cscript cmdlines.vbs"There's a line in the VBscript that imports: ws.Run("REGEDIT /S cmdlines.reg"),0,True I see you're using RIPrep however. I can't understand with thread after thread of the same problems why people still insist on using that. Anyway, I can't say for sure what works or not under RIPrep. The above may work, it may not.

cmdlines is too early to make that registry change. You should try doing it from GuiRunOnce or RunOnceEx. It's not that you can't import reg entries during the cmdlines execution, I do it on every install, it's what you're changing. There are numerous registry entries that will not "stick" when made from cmdlines and I think this may be one of them.

Technically speaking, for the PnP enumerated setup of a device in the GUI portion of setup, the only files you need are those that are defined in the .inf file. I just felt that might be a topic that could wait for later as it can be a little more advanced. If you'd like to see what files are needed for a particular device, you might want to check out Bashrat the Sneaky's DriverPack LAN. Decompress the 7-zip archive and navigate your way to the directory that supports your NIC. The support page for DP LAN contains a listing of all supported drivers and which directory in the DP they reside in.

To tell you the truth, in situations where I don't use RIS - usually in shops with less than a dozen computers - I just stick to using CD/DVD for installs. I've found it to be much easier to implement and it goes just as fast.

What you had in post #1 was correct, but you need to additionally place the .inf and .sys file in i386 and restart the BINL service. The drivers in $OEM$\$1\Drivers\NIC should be the total driver set, including files other than .inf and .sys. At a bare minimum you would want to have any .cat files in there.

It sounds as though he works in a place that does photography/video as it's business. A tough environment to be an admin for sure since you would expect the gigabytes to be flying. Where I work we have a forensic laboratory. There's only two guys who work back there, but they're responsible for 80% of the network storage requirements and at least 90% of the network throughput (if you leave out such things as DHCP, DNS, etc). It's all about $$$ in an environment like that.

You'll need to somehow register the associated .cat file with WFP. I remember seeing a thread about this issue over RyanVM's forums quite some time ago. You may want to check out certutil.exe (by default located in System32).

Yea I had quotas set, even set the group policy setting to not consider the desktop as part of the profile. I guess if you were set up in a 2003 R2 environment, you could try your hand at the improvements made to Dfs and see if it works any better for you.

I've had all kinds of difficulties with roaming profiles getting corrupted or completely disappearing. I'm sure that part of the issue was Dfs replication, which actually brings up another issue - availability. You need to make sure that the roaming profiles are highly available in order to prevent logon errors or extremely long logon times. Which reminds me.. watch out for the idiots who store like 2GB of photos on their desktop which is a part of the profile. This has really reminded me of why I stopped using them

Ok, this seemed to work perfect for me: procNlite.StartInfo.FileName = txtNlite.Text procNlite.StartInfo.WindowStyle = ProcessWindowStyle.Normal tspbMain.Style = ProgressBarStyle.Marquee Application.DoEvents() procNlite.Start() Do Until procNlite.HasExited Application.DoEvents() System.Threading.Thread.Sleep(250) Loop At first I didn't have the Application.DoEvents in the Do loop and the interface wouldn't repaint and my progress bar wasn't working. But this seems to do the trick for me. My application reports 0% CPU in Task Manager yet the progress bar works and the interface repaints.

Here you go... 101_AllUsers.7z

Here's an example from MSDN that could prove helpful. The example itself is a little convoluted, but it works. http://msdn.microsoft.com/library/default....yclasstopic.asp

I'm not sure about cscript.exe from DetachedProgram, but I'm sure a compiled AutoIt script would work just fine.

I've been struggling with this problem as well. One thing to watch out for with the solution you gave is the possibility of putting your application in a race condition. Take a peek at Task Manager when you execute. If I can find a better solution I'll be sure to post it here.

If you're in a place like mine where there's only 100 or so workstations, I would definitely prestage them. If you ever need to re-install a machine, all you have to do is a RIS boot and an hour later you have a new computer. It's better to just take the time the first time and do it right. On the other hand, if you're in an enterprise with several hundred or even several thousand computers, it would be impractical at best, impossible at worst to prestage everything. But then again, if you're in an environment like that you should also have SMS throughout.

Another issue with your post is that you state you are deploying Windows 2000 Pro as your client (?) It's been a long time since I've done that and I just didn't feel qualified to help you out. Back when I was deploying Win2k was before I began automating everything, so I'm not really familiar with all of the tricks and rules that apply to 2000 vs. XP.

I can't say enough bad things about RIPrep. I haven't messed with it for over three years now. IMO you'd be better off using standard flat images and automating all of the post setup chores.

I'm sure that if there is a way to get something to work, you're the one who can do it

Sounds as though you're using RIPrep ?

GUIDS or UUIDS (depending on who is speaking) are supposed to be unique to every computer in the world. But like MAC addresses and Social Security numbers in the USA, little glitches in the system can arrise. At one work site I have 5 identical Toshiba laptops that are quite old now. They were put out when the whole GUID thing was still pretty new. I applied a BIOS update to all of those laptops and ever since have been living with a rather big mistake on the part of Toshiba. They hardcoded the GUID into the BIOS update, therefor all 5 have the same GUID. To get around this situation is easy, but a pain. RIS a laptop and then after the install is finished, go into Active Directory Users and Computers and change the GUID in the computer object to the MAC address preceeded with twenty numerical zeros (0). Here's a second scenario. Sometimes the GUID for a computer is not readily available until you boot the computer and go through the RIS menus, where you will see it on the final screen before setup starts. In that case, a computer account was created in your AD under the Computers container. What you can do is write down the GUID, delete the computer account from AD, then go to Active Directory Sites and Services and force replication between domain controllers. Then create your new computer object in the OU of your choice, select the checkbox for "This is a managed computer", and enter in the GUID. Lastly, if a computer does not have a GUID at all, you can make one by doing what I described above - enter in twenty zeros and then the MAC address.

I'm not much of a modem expert anymore. It's been so long since I've needed to use a standard landline. But I think what you're asking could present some pretty serious problems. I think in order for the modem to "read" your touch tones, it would have to be "off hook" so to speak. And I don't know how you could get the modem to do that automatically whenever you pick up your handset. A couple of the secretaries where I work have landline phones with bluetooth in them, where they use a cell phone style headset. You could probably find some software, like FMA, that would monitor things that way.