Monty Carter

A tool that has been indispensible for me is WMICodeCreator ( http://www.microsoft...&displaylang=en ). It is a Microsoft freebie, and is basically a GUI WMI browser. To top it all off, it will generate code in VBScript, VB, or C# that performs the query you selected in the GUI. It is pretty handy. Another tool that I have started liking alot lately is PowerShell. It has a cool Get-Member cmdlet that shows you all of the properties and methods of an object. You can see all of your options, and then query the object for one of its values, or perform one of the objects methods. The following example gets the Win32_BIOS object, enumerates the object's properties and methods, and then queries the object for its BIOS version and Manufacturer PS C:\Documents and Settings\mcarter> $oBIOS = Get-WmiObject Win32_BIOS PS C:\Documents and Settings\mcarter> $oBIOS | Get-Member TypeName: System.Management.ManagementObject#root\cimv2\Win32_BIOS Name MemberType Definition ---- ---------- ---------- BiosCharacteristics Property System.UInt16[] BiosCharacteristics {get;set;} BIOSVersion Property System.String[] BIOSVersion {get;set;} BuildNumber Property System.String BuildNumber {get;set;} Caption Property System.String Caption {get;set;} CodeSet Property System.String CodeSet {get;set;} CurrentLanguage Property System.String CurrentLanguage {get;set;} Description Property System.String Description {get;set;} IdentificationCode Property System.String IdentificationCode {get;set;} InstallableLanguages Property System.UInt16 InstallableLanguages {get;set;} InstallDate Property System.String InstallDate {get;set;} LanguageEdition Property System.String LanguageEdition {get;set;} ListOfLanguages Property System.String[] ListOfLanguages {get;set;} Manufacturer Property System.String Manufacturer {get;set;} Name Property System.String Name {get;set;} OtherTargetOS Property System.String OtherTargetOS {get;set;} PrimaryBIOS Property System.Boolean PrimaryBIOS {get;set;} ReleaseDate Property System.String ReleaseDate {get;set;} SerialNumber Property System.String SerialNumber {get;set;} SMBIOSBIOSVersion Property System.String SMBIOSBIOSVersion {get;set;} SMBIOSMajorVersion Property System.UInt16 SMBIOSMajorVersion {get;set;} SMBIOSMinorVersion Property System.UInt16 SMBIOSMinorVersion {get;set;} SMBIOSPresent Property System.Boolean SMBIOSPresent {get;set;} SoftwareElementID Property System.String SoftwareElementID {get;set;} SoftwareElementState Property System.UInt16 SoftwareElementState {get;set;} Status Property System.String Status {get;set;} TargetOperatingSystem Property System.UInt16 TargetOperatingSystem {get;set;} Version Property System.String Version {get;set;} __CLASS Property System.String __CLASS {get;set;} __DERIVATION Property System.String[] __DERIVATION {get;set;} __DYNASTY Property System.String __DYNASTY {get;set;} __GENUS Property System.Int32 __GENUS {get;set;} __NAMESPACE Property System.String __NAMESPACE {get;set;} __PATH Property System.String __PATH {get;set;} __PROPERTY_COUNT Property System.Int32 __PROPERTY_COUNT {get;set;} __RELPATH Property System.String __RELPATH {get;set;} __SERVER Property System.String __SERVER {get;set;} __SUPERCLASS Property System.String __SUPERCLASS {get;set;} PSStatus PropertySet PSStatus {Status, Name, Caption, SMBIOSPresent} ConvertFromDateTime ScriptMethod System.Object ConvertFromDateTime(); ConvertToDateTime ScriptMethod System.Object ConvertToDateTime(); Delete ScriptMethod System.Object Delete(); GetType ScriptMethod System.Object GetType(); Put ScriptMethod System.Object Put(); PS C:\Documents and Settings\mcarter> $oBIOS.BIOSVersion DELL - 27d7060d Phoenix ROM BIOS PLUS Version 1.10 A17 PS C:\Documents and Settings\mcarter> $oBIOS.Manufacturer Dell Inc. PS C:\Documents and Settings\mcarter>

When you say "bulk id" creation, are you referring to creating AD User Accounts? If so, and you don't want to use an excel spreadsheet to provide input for the script, you'll need another source to provide a list of accounts to create. This could come from, as Greg suggested, a csv file. It could also be piped in from many different sources (e.g., SAP, or even a simple text file.) You can't automate data entry without a source of data (Unless, of course, the script generates the data, in which case I am not understanding at all what you are trying to do...) We can't really offer you any more help than that without knowing exactly what kind of "bulk id" you are trying to create, and what data source you intend to use as input for the script.

So basically this is just to filter out systems that aren't running one of the prescribed OS's, correct? In this case, you just need to add the identifiers for Windows 7 (and every other OS you want to detect) as cases to your select statement. Specifically, you'll need to add a short variable for each string to be added, and then throw a case for each short variable into your select statement. I don't know what versions of Vista, 7, and 2008 you'll be using (home, home premium, ultimate, standard, datacenter, etc.), but I'll assume you only need to detect Windows 7 Ultimate for my example... sWXPP = "Microsoft Windows XP Professional" sW2KP = "Microsoft Windows 2000 Professional" sW2KS = "Microsoft Windows 2000 Server" sW2KAS = "Microsoft Windows 2000 Advanced Server" sW2KDS = "Microsoft Windows 2000 Datacenter Server" sW2K3S = "Microsoft(R) Windows(R) Server 2003, Standard Edition" sW2K3W = "Microsoft(R) Windows(R) Server 2003, Web Edition" sW2K3E = "Microsoft(R) Windows(R) Server 2003, Enterprise Edition" sW7U = "Microsoft Windows 7 Ultimate " <============== Defining the short variable sUnkOS = "OS Unknown or NOT supported" . . . Select Case sWbemOpSys Case sWXPP Case sW2KP Case sW2KS Case sW2KAS Case sW2KDS Case sW2K3S Case sW2K3W Case sW2K3E Case sW7U <============== Set the case where sWbemOpSys==sW7U Case Else sContent = sFJImg & "<h3><center>OS Not Supported:" _ & " " & sWbemOpSys & "</center></h3>" oDialogWindow.document.body.innerHTML = sContent WScript.Sleep 1000 oDialogWindow.Quit WScript.Quit End Select You'll need to add additional lines like the ones above for each OS you need to detect. To find the strings on each OS you might consider using a tool called WMICodeCreator ( http://www.microsoft...&displaylang=en ). It is a handy tool, from Microsoft, that allows you to browse WMI, and even create VBscript code from the selections you have made in the GUI. It is pretty straight forward to use. You'll want to run WMICodeCreator on each OS you want to collect, and get the Caption value from the Win32_OperatingSystem class.

Are you using WDS to provide only a boot image via the PXE boot service and using MDT to deploy 2003, or are you actually deploying the installation image from WDS? (Usually, MDT uses WDS to provide just a boot image. Then, all installation images, scripts, task sequences, applications drivers, etc. are pulled from the MDT distribution share, instead of from WDS... WDS can, however, be used to provide installation images, by itself.) If your installation images are, in fact, coming from MDT's distribution shares, rather than from WDS, you may be interested in upgrading to MDT 2010. MDT 2010 introduced a new feature that provides "linked" distribution shares. Basically, the contents of your MDT distribution shares can now be replicated between multiple MDT servers. Using this, all installation images, applications, drivers, packages, scripts, task sequences, etc. will be replicated between your multiple MDT servers. You would need to set up WDS at your 2nd site, in addition to MDT, and then link MDT in your 2nd site to MDT in your 1st site. MDT automatically recreates boot images at the 2nd site to reflect the new UNC path for the distribution share in the 2nd site (without this auto-update feature, if you simply copied the boot image from WDS at site 1 to WDS at site 2, clients booting at site 2 would still connect to the MDT distribution share at site 1, because the distribution share details are injected into the boot image itself). If you are actually deploying installation images directly from WDS then I would imagine that there should be a way to utilize the MDT configuration in site 1, assuming that you aren't installing any drivers, applications, or packages, during your task sequences. I haven't actually worked with a configuration like this, so I can't speak without some investigation, but I don't see why you shouldn't be able to put something together where an installation image is pulled from WDS, which then connects to the MDT at site 1 to recieve the task sequences over the WAN. But if you are installing apps and drivers and such from the MDT distribution share at site 1, you will run in to bandwidth troubles on slow links.