JohnGruhn

Just a thought but what is preventing you from using ITMU now? The hardest part of your solution is creating the detection logic and that alone is valuable time that SMS could be fixing your computers. Within one detection cycle after advertising the sync agent you would have a complete picture of what you need to fix and the packages you need to create. Even better, the reports for software compliance are updated along with the inventory so you can track your progress much mroe easily, something your homegrown solution will probably not do. OS detection is easy but ITMU gives you the rest of the detection. If your waiting for SMS 2003 SP3, that will be out on 27 APR 07 (ie Friday) and its more than worth it to switch and take two weeks to figure it out rather then reinvent the wheel. If your network is as borked as you say it is (been there, done that way too much), spending the week or so to figure out how to use ITMU which is not that hard will more than payoff in total time to completion. SGT Gruhn, John L BCT1 D101 S6 AMO NCOIC

If most of your computers are Windows XP, 2000, and 2003 (the mainline support OS from Microsoft), why are you not using ITMU v3 (http://www.microsoft.com/technet/prodtechnol/sms/sms2003/downloads/tools/msupdates.mspx) for detection and distribution of patches? ITMU v3 will detect and push anything pushed by Microsoft Update, ie Windows, Office, SQL, Exchange, etc. NT4 ITMU v3 will not work because it is way out of lifecycle. For those you will have to use you detection logic from above but you should be able to take out the OS detection and make a collection based on the OS. SMS2003's default collections allow for targeting by OS to reduce bandwidth. If you need to further define collections based on critera, you probably should have your AD structured to account for the different policies so you can make collections based on that for the patch pushing. Implementation of this will last for SMS 2003, although as a previous poster has pointed out, eventaully it will go to a WSUS server setup in SCCM 2007. It will still be controlled via SMS, but the back operations will be SUS with a little added on. If you want to know more about SMS; most of the user groups I use are on www.myitforum.com. That covers the entire System Center Family (SMS, MOM, etc) SGT Gruhn, John L BCT1 D101 S6 AMO NCOIC

Does anybody know command line options for VistaSetupPrep.exe ? Im interested to know if it leaves the extracted Vista DVD files after the install. On another blog it tells the process (https://blogs.msdn.com/windowsmarketplace/archive/2007/01/29/what-do-you-get-when-you-download-windows-vista-from-marketplace.aspx) If it does, can this be used with the WAIK or BDD 2007 to create a bootable Vista DVD? Im thinking I could use oscdimg.exe, but curious if someone else has figured it out. I don't like the idea of downloading Vista and then not having a bootable physical copy of it.

Hello, Im trying to change the default autorun sequence for USB disk drives only. I have a script that detects drives that use USBSTOR.sys and matches them against a list of known good PNP IDs named USBDetect.vbs. If unauthorized, the script then shuts down USB Storage via devcon and sends an alert to an admin. Id like this script to run each time someone inserts a USB device. If this works, the easier it is to deploy in my domain the better. Any ideas on where to look? I have looked at google and yahoo and have yet to find what Im looking for. Thanks in advance

That may be true. However, as a sysadmin in the military and having used the Vista beta2 and being aware of the Longhorn beta builds, I can tell you there are things in Vista to like from a military point of view. Network Access Control, USB access control, more modular design, and IE7+ all seem worthwhile things. Bitlocker, ALSR, and some of the new wizards are also nice from the security point of view. Additionally, the expanded group policy is something that interests me as a Army sysadmin. Will we move to it at RTM? Almost certaintly not. Having said that does it make sense in the Longhorn timeframe? Yes, assuming that they work the kinks out. I admit that the beta sucks up memory, but internal builds that have not gone public improve upon this alot. The real time to make that decison is after it RTMs and we can commit to a full torture test. I for one look forward to the offical testing. I will judge it then.

I installed Dell's mraid35x mass storage drivers for Win2k3 by editing txtmode.sif and moving a makecab compressed copy of mraid35x.sys into my i386, replacing the previous versionn. I am using RIS on Win2k3 and setup runs fine, identifying my Dell 1750's raid, formatting, installing updates etc. Upon the first boot after setup however, the driver seems to be lost and I get a 0x7B BSOD. If it worked during setup, what would casuse it to not use it post setup? The relevant settings for mraid35x from my txtsetup.sif are listed below. [SourceDisksFiles] mraid35x.sys = 1,,,,,,4_,4,0,,,1,4 [HardwareIdsDatabase] PCI\VEN_101E&DEV_9010 = "mraid35x" PCI\VEN_101E&DEV_9060 = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_11121111 = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_11111111 = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_09A0101E = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_11111028 = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_04671028 = "mraid35x" PCI\VEN_101E&DEV_1960&SUBSYS_04711028 = "mraid35x" PCI\VEN_101E&DEV_1960&SUBSYS_04931028 = "mraid35x" PCI\VEN_101E&DEV_1960&SUBSYS_04751028 = "mraid35x" PCI\VEN_1028&DEV_000E&SUBSYS_01231028 = "mraid35x" PCI\VEN_1028&DEV_000F&SUBSYS_013B1028 = "mraid35x" PCI\VEN_1028&DEV_000F&SUBSYS_014A1028 = "mraid35x" PCI\VEN_1028&DEV_000F&SUBSYS_014C1028 = "mraid35x" PCI\VEN_1028&DEV_000F&SUBSYS_014D1028 = "mraid35x" PCI\VEN_101E&DEV_1960&SUBSYS_05111028 = "mraid35x" PCI\VEN_1000&DEV_1960&SUBSYS_05181028 = "mraid35x" PCI\VEN_1000&DEV_1960&SUBSYS_05201028 = "mraid35x" PCI\VEN_1028&DEV_0013&SUBSYS_016C1028 = "mraid35x" PCI\VEN_1028&DEV_0013&SUBSYS_016D1028 = "mraid35x" PCI\VEN_1028&DEV_0013&SUBSYS_016E1028 = "mraid35x" PCI\VEN_1028&DEV_0013&SUBSYS_016F1028 = "mraid35x" PCI\VEN_1028&DEV_0013&SUBSYS_01701028 = "mraid35x" PCI\VEN_1000&DEV_0408&SUBSYS_00011028 = "mraid35x" PCI\VEN_1000&DEV_0408&SUBSYS_00021028 = "mraid35x" [SCSI.Load] mraid35x = mraid35x.sys,4 [SCSI] mraid35x = "AMI MegaRaid RAID Controller" -- Gruhnj

You can automate the process using dsquery and dsrm. Run from the command prompt dsquery computer -inactive X >InactComps.txt where X is the number of weeks of inactivty you want to check for. After you check this file place a ";" at the end of each line using search and replace. Then run the following command line to delete them. for /f "delims=;" %i in (InactComps.txt) do dsrm -noprompt %i This same procedure can also be used for users; just replace computer with user and you get a similar list of inactive users.