[THIN] Re: Best way to set-up user registry
- From: "Braebaum, Neil" <Neil.Braebaum@xxxxxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Mon, 23 Feb 2004 11:44:04 -0000
Comments inline...
> -----Original Message-----
> From: Eyles, Richard [mailto:richard.eyles@xxxxxxxxxxxxxxx]
> Sent: 23 February 2004 11:09
> To: 'thin@xxxxxxxxxxxxx'
> Subject: [THIN] Re: Best way to set-up user registry
>
> >>>> So my plan is to use the CLIENTNAME environment variable to
> >>>> identify the hardware and set the registry accordingly.
> My dilema
> >>>> is whether to use lots of reg files and just load the
> appropriate
> >>>> one or to set-up a database of the settings then look up
> the client
> >>>> and set the registry.
> >>>
> >>>When you say access a database - what would be in it, and why?
> >>
> >> Terminal ID - specific to the application
> >
> >By that do you mean CLIENTNAME?
>
> Not quite, if only it where that easy. The application
> software only allows a terminal id of up to 6 characters.
Would you logically derive the terminal ID from CLIENTNAME, though, or
would you need some other details?
> Also there are a number of settings that are at this terminal
> id level which are set centrally so the system manager needs
> to know of all of them. Unfortunately some terminal settings
> are also set at the client level at the HKCU level one of
> which is the terminal ID. This stems from the history of the
> application which used to be accessed via telnet and the
> terminal id was the answerback.
>
> Also I do not have control over what the CLIENTNAME
> environment variable will be, obviously it could be the thin
> client device ID or the PC name.
So what do you do, in that scenario? If there is an algorithm, there,
you should be able to script that.
Having said that, though, if you need to store numerous other details,
specific to the terminal, then I suspect one more field in a database
makes little difference.
> >> Terminal specific default search parameters
> >
> >Are these derivable, or specific to many different terminals?
>
> Devirable in that once I know the CLIENTNAME I know what the
> settings would be, some settings may be the same for some
> terminals, but in the final analysis the potential exists for
> each device to have it's own unique set. :-(
Do they all start off as the same?
And what sort of profiles do you use for your TS users? Local, roaming,
mandatory, hybrid?
> >> >What sort of domain do you have? AD, or an NT domain?
> >>
> >> NT currently but I believe at some point, no idea when, our
> >> I.T. wish to move to AD
> >
> >Ah, well. I was sort of wondering if you used AD, if it could be the
> >repository for this information.
>
> That would be nice for the future, but I can't wait that long!
All I'd say, is that if the CLIENTNAME / terminal machine is in the
domain as a computer, you could make use say the description field, in
the domain, for some details - and you could then access them via ADSI
(using the WinNT provider), and perhaps save yourself the trouble of
using an interim database.
Just a thought - may not be tenable, especially if there are numbers of
client machines that aren't objects in your domain.
> >> One last thing, this application while it runs in the
> >> terminal server environment was not written for it!
> >
> >The application you are talking about, though, and the database for
> >terminal settings are two distinct and different things?
>
> Of course, sorry, I was just highlighting that getting the
> application to work in a different manner or changing to
> another application is not an option I have!
>
> So, do I go for a database of the terminal specific settings
> or loads of reg files?
It's going to come down to what you are going to be able to develop and
support.
> I'd prefer the database, Access is preferrable, but how do I
> query such a database in a logon script?
Normally you'd use ADO.
Because automating actual use of Access using office automation would
requite that the application exists where the code is running.
As it stands, you may have no other option than to use a database
(consider whether a CSV file would be just as usable, though). Unless
there is scope for using existing fields of the domain database for
computer objects (not much use, though if many / all your client
machines won't actually be present in your domain).
And you will need to write stuff to the registry.
WSH scripting provides very limited capabilities for registry stuff -
anything more than simple values being read (there's limits on the size
and type of values you can write), and it's going to run out of steam -
to say nothing of being unwieldy to do. Using WSH / vbscript, and using
*WMI* to access the registry would overcome some of those restrictions,
but again, is complex, and a bit unwieldy - especially if you're new to
scripting.
Personally, my feeling is that for *login* scripts, where you need to
access files and / or the registry, WSH / vbscripting is not a good fit
- it's overly complex for that sort of thing, and is quite restricted
and crippled, unless you using other technologies for stuff like the
registry.
Kixtart would suit what you need to do much better. The registry support
is comprehensive, and much easier to code - just use of functions,
rather than needing to use external providers, create objects, and use
numerous sub methods and functions to do it.
Also, you can make the same use of ADO to access a database, that you
can in WSH scripting - so you get the best of both worlds.
Neil
***********************************************
This e-mail and its attachments are confidential
and are intended for the above named recipient
only. If this has come to you in error, please
notify the sender immediately and delete this
e-mail from your system.
You must take no action based on this, nor must
you copy or disclose it or any part of its contents
to any person or organisation.
Statements and opinions contained in this email may
not necessarily represent those of Littlewoods.
Please note that e-mail communications may be monitored.
The registered office of Littlewoods Limited and its
subsidiaries is 100 Old Hall Street, Liverpool, L70 1AB.
Registered number of Littlewoods Limited is 262152.
************************************************
********************************************************
This weeks sponsor Vizioncore, Inc.
--> vc-iMonitor - Performance Monitoring, Control & Reporting
--> vc-iControl - Desktop & Start Menu Management & Reporting
--> vc-iMapper - Drive, Printer & COM Management & Reporting
http://vizioncore.com/products.html
**********************************************************
Useful Thin Client Computing Links are available at:
http://thethin.net/links.cfm
***********************************************************
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thethin.net/citrixlist.cfm
Other related posts:
