VBScab

have inherited a VB Script driven by an XML file. The XML file is in a format which the developers refuse to change so I'm stuck with it. A fragment of the file looks like this:<configuration><NTCredential ID="BTS_IHOST_GROUP" DisplayName="BizTalk Isolated Host Users Group" Description="Windows group for accounts with access to the Isolated BizTalk hosts"><NTAccount ScopeType="105" UpLevelFlags="132" DownLevelFlags="2147483654">thedomain\domainuseraccountname</NTAccount></NTCredential><more, unrelated elements, etc></configuration>There are a dozen or so 'NTCredential' elements whose 'ID' attribute is unique.I need to modify the script so that it finds a particular 'NTCredential' element, then changes the ScopeType, UpLevelFlags and DownLevelFlags attributes AND the value 'thedomain\domainuseraccountname'.I *think* I need to use the "getElementsByTagName" method but am a complete newbie with XML. If someone can help me out with some snytax, that'd be great: as long as I can get one to work, I can handle passing in an array to a function which I will build around that syntax (I already have a WSC for updating single fields).I'm using CreateObject("Microsoft.XMLDOM") as my XML handler.

Yes, you can create VBSs and your ASP knowledge will stand you in good stead. Use devguru.com as a reference. cwashington.netreach.net has some fabulous scripts, too.I think there is a utility that will convert scripts to EXEs but why not use a has of some kind? My scripts are protected by calls to a component which produces a hash from (among other things) the script's size, creation date and name. Each script has its own hash recorded in a Const. It checks its own hash via the component so, if anyone has messed with it, the hashes don't match and the script bails. It's not 100% bullet-proof, but it'll stop the idiot users who want to use the system-level calls (which some of our scripts use) for their own evil purpose. You know the sort of thing, I'm sure - making themselves members of local admin group, etc...