Location ini

[ccoll23]

I've seen a few posts of "mrmovie" that refer to a logon script referencing an ini file. I am interested in putting together a logon script that references this for mapping drives, printers and other things. Our company has about 1000 workstations which are spread out over 7 physical locations, and as mrmovie said, I would like to have a single logon script if possible to avoid chaos.
Thanks for any help...ccoll23

 

[acl03]

Are you in active directory? The easiest way to roll out a logon script is with Group Polcy.



Thanks,
Andrew

 

[acl03]

http://www.tek-tips.com/faqs.cfm?fid=5798

Markdmac has written a very powerful login script at the FAQ above. It's served as a great reference for me (as well as many others I'm sure).





Thanks,
Andrew

 

[ccoll23]

Yes I am in AD. I currently run logon scripts with gp, but have many OU's with different requirements,(mostly different printers)and am curios about calling an ini file from the logon script, if I understand the concept correctly.
Thanks

 

[EBGreen]

I would suggest using an XML file rather than an INI if you really want to go that route. I feel that the support available for reading and writing XMLs with VBScript is greater than that of INIs plus you will be learning skills that will stand you in good stead for other tasks as well.

[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]

 

[ccoll23]

this is the link I am referring to: thread329-751336

 

[EBGreen]

I would still recommend an XML rather than an INI. Mark has a lot more login script experience than I do, but I still say XML is a much more extensible solution if you will pardon a really bad joke.

[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]

 

[mrmovie]

i would agree with the XML comment in general, it is a great new skill to have.
however i would temper this that for simlpe key and value data an ini file is easier to read, this is important for things like logon scripts as you want people in other locations to be able to manage it and ask them to read xml and they will pee their pants.

i use this to read ini files, it returns a dictionary object of dictionary objects.

the root dic object is the ini file, each dictionary contained in that represents an ini file section and its key and values:


Set dicGlobal = ParseAllINI(str2inifile)

'then something like
Wscript.Echo dicGlobal.Item("INI_SECTION_NAME").Item("key_name")
'would give you the #VALUE of
'[INI_SECTION_NAME}
'key_name=#VALUE

Function ParseAllINI(strIniFileName)
On Error Resume Next
Dim ParseAINI, blnFoundSection, strSection
Dim intEquals, sKey, sVal, i, sLine, tsIni

blnFoundSection = False
Err.Clear

If FSO.FileExists(strIniFileName) Then

Set tsIni = FSO.OpenTextFile(strIniFileName)
Set ParseAllINI = WScript.CreateObject("Scripting.Dictionary")

Do While Not tsIni.AtEndOfStream
sLine = ""
sLine = Trim(tsIni.ReadLine)
If sLine <> "" Then
If Left(sLine,1) <> ";" Then
If Left(sLine,1) = "[" Then
blnFoundSection = True
'Msgbox sLine & " section found"
strSection = Left(sLine, Len(sLine) - 1)
strSection = Right(strSection, Len(strSection) - 1)
Set ParseAINI = Wscript.CreateObject("Scripting.Dictionary")
ParseAllINI.Add UCase(strSection), ParseAINI
Else
'key and value logic
intEquals = InStr(1, sLine, "=")
If (intEquals <= 1) Then
'msgbox "error: the following line is invalid " & sLine
Else
'weve found a valid line
sKey = Left(sLine, intEquals - 1)
sVal = Right(sLine, Len(sLine) - intEquals)


Err.Clear
ParseAINI.Add Trim(LCase(sKey)), Trim(sVal)
If Err.Number <> 0 Then
'msgbox "unable to add to dictionary object"
End If
'msgbox strSection & " " & sKey & ";;;;" & sVal


'key and value logic end if
End If
End If
End If
End If
Loop

tsIni.Close
Set tsIni = Nothing

If blnFoundSection = False Then
Set ParseAllINI = Wscript.CreateObject("Scripting.Dictionary")
End If

Else
Set ParseAllINI = Wscript.CreateObject("Scripting.Dictionary")
End If


End Function



'i used it to have a [MAPDRIVE], [MAPPRINTER] etc section.
on top of that i had the fact that one could have an ini file for each office location (luckily all our PC's had a registry key which stated where their 'HomeLocation' was from) so when they logon read the HomeLocation from the registry and then you know to read a specific ini file, ontop of that read their 'CurrentLocation' from AD site info and then you can load another ini file. ontop of that i had it so that you could have an ini for an AD group, or an AD user, so you could have lots of ini files to read at logon. all this was hirachecal where userINI was the most powerful and Location was the least so you could override settings when you wanted to.

anyway i go on,

 

[EBGreen]

I will grant you that an INI file is in general easier to read for the average user. But then again I don't want my average user poking around in my login configuration files anyway so that doesn't really bother me. Here is an XML file and an INI file with essentially the same mappings. The INI is easier to read but the XML isn't terribly hard to read either IMO. It is all really a moot point since I've always maintained that especially with a scripting language if it does what you want then it is the right way to do it.

XML:
<?xml version="1.0"?>
<root>
<DriveMappings>
<Mapping>Apps Folder
<Letter>F:</Letter>
<UNC>\\Server\Apps</UNC>
</Mapping>
<Mapping>Backup Folder
<Letter>g:</Letter>
<UNC>\\Server\Backup</UNC>
</Mapping>
<Mapping>Test Folder
<Letter>H:</Letter>
<UNC>\\Server\Test</UNC>
</Mapping>
</DriveMappings>
</root>

INI:
[DriveMappings]
F:=\\Server\Apps
g:=\\Server\Backup
H:=\\Server\Te

[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]

 

[mrmovie]

ini and xml aside my implementaion of drive mapping was something like

[MAPDRIVE]
AD_Group_X=H:\\server\folder,True,False

where the True was if you wanted to disconnect H if it was mapped to somewhere other than \\server\folder and False if you wanted to make it a persistant mapping.
the AD_Group_X was that despite the reason or where you got the source file from (location, group or user) the drive mapping was always done on group membership (one can make this 'always' happen by using DomainUsers as the group name. (the same logic was applied to all actions in the logonscript, i.e. Scripts, Printers...

anyway my point would be that this would be a good reason to use the xml format as the 'Value' is no longer a simlpe single string, it is delimited and i then had to write a dodger split and then people had to remember or read the docs to figure out what the comma delim'd params are...xml is much better at this

<drivemapping disconnect=true persistant=true adgroup=....etc, etc