Vista - Script Execution Over Network

I'm currently working on revising my company's logon script. When a
user logs on, a remote batch file is executed that checks if the
client already has a file named "logonscript.vbs" on their PC. If
they do, it generates and compares the CRC checksum of the file to a
"logonscript.vbs" that exists on the domain controller. If the two
CRCs match, we know that the client has the latest version of the
script. However, if they do not, the latest version of the script is
copied from the domain controller to the client, and then executed by
the client workstation.

This seems like a lot of back-and-forth to me, and I'm having trouble
gauging whether it's the most efficient way of doing things. Part of
me wants to simplify things by simply running "logonscript.vbs" from
the domain controller without making a copy on the client's PC first.
This would eliminate the need to perform a CRC checksum comparison.
Is there a way for me to figure out how much bandwidth this would cost
on a per-logon basis? Any thoughts or suggestions? I'm pulling my
hair out over this (it doesn't really need much help, though, but
that's a separate issue entirely).

Thanks in advance.

"Justin R." <JRusbatch@xxxxxx> wrote in message
news:9e2823a0-65b3-4495-bc99-b4fcb984fd4d@xxxxxxUnless you have a huge logon script, the bandwidth requirements would be
minimal. What is the size of your script? A few kBytes? Trivial! Remember: A
100 MBits Ethernet can transfer up to 10 MBytes per second.

If you're still reluctant to have your script reside on the server then you
could use "xcopy.exe /d" to ensure that the user has the latest version of
the script. This is a single line of code and it is much simpler than
creating and comparing CRC checksums.

"Pegasus (MVP)" <I.can@xxxxxx> wrote in message
news:OHiOBMeYJHA.5156@xxxxxxOf course there is the bandwidth required to copy the logon script.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

On Dec 19, 12:46*pm, "Richard Mueller [MVP]" <rlmueller-
nos...@xxxxxx> wrote:I think I know what you mean, but I don't think you would've posted if
your point was that simple. Can you elaborate, Richard?

"Justin R." <JRusbatch@xxxxxx> wrote in message
news:f0db0038-7739-4369-97cd-96d0865c5f71@xxxxxx
On Dec 19, 12:46 pm, "Richard Mueller [MVP]" <rlmueller-
nos...@xxxxxx> wrote:I think I know what you mean, but I don't think you would've posted if
your point was that simple. Can you elaborate, Richard?

------
I don't know the details, so I hesitate to say too much. However, I think
more bandwidth is required to copy a program than to execute the program.
When a program is run it is loaded into memory, which is fast, so the
transfer over the network doesn't need to wait much. A logon script should
run from local memory. When a program is copied the local drive controller
is the bottleneck. The same number of bytes are transferred, but more
traffic may be needed.

Long ago when we had 10 Mbps networks and 100 MHz clients we never had
trouble running logon scripts over the network, even when many people logged
on at once (such as after a server reboot). And we had some elaborate logon
scripts. The exception was logon scripts that installed software over the
network. That caused problems.

My recollection is that batch files are loaded and run one line at a time,
but VBScript programs (and all *.exe programs) are loaded all at once and
then run.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

"Richard Mueller [MVP]" <rlmueller-nospam@xxxxxx> wrote in
message news:uKE6YEiYJHA.5476@xxxxxxAnd you are forgetting the bandwidth taken up by the program that reads the
script on the server to compute its CRC checksum...
That is exactly right. If you have a complex batch script or set of them,
there *might* be some efficiencies involved in copying them down locally,
but there are reasons why you would not want to, including:

- all users would need to have write access to a local folder assumed to
contain trusted executables;
- complexity itself will increase the cost of maintenance and the risk of
changes causing unexpected errors.

My suggestion: concentrate on simplifying the code itself, rather than
introducing complexity, as the best way to make your logon script operate
efficiently (and reliably).


/Al

"Richard Mueller [MVP]" <rlmueller-nospam@xxxxxx> wrote in
message news:uKE6YEiYJHA.5476@xxxxxxIf reading the logon batch file on a line-by-line basis is a speed/bandwidth
issue then it can easily be overcome by using the following code:
@echo off
if /i "%1"=="run" then goto Run
xcopy /d /y \\server\netlogon\netlogon.bat c:\Windows > nul &
c:\Windows\netlogon.bat run
:Run
[Remaining lines of code]

This method has the following properties:
- Only three lines of code need to be read from the server's netlogon share.
- All remaining lines are read from a local file.
- The local copy of the script is always up-to-date.

"Pegasus (MVP)" <I.can@xxxxxx> wrote in message
news:eJ4j7niYJHA.1328@xxxxxxOne additional "property" of this method is that the user must have write
access to the "C:\windows" folder. IMHO, that is just too dangerous a
configuration change to make in order to attempt to speed up the logon
process. How much of a performance improvement would result is questionable,
but this would seem to be greater for a long batch file. But I suspect that
a long batch file would be better optimized by rewriting in vsbcript.

But for those who insist, I would shorten the number of lines read in from
the netlogon share by cmd.exe to one, by moving the operational logon script
code to a separate file. The actual domain logon script file could contain
this:

@copy /d /y "%~dpn0_copy.cmd" "%appdata%" & "%appdata%\%~no_copy.cmd"

If that file were called logon.cmd, then a file called logon_copy.cmd would
be updated in the user's local profile from the netlogon share.

Not ideal, as someone could substitute a rogue logon_copy.cmd file into the
appdata folder with an old timestamp on it. And it still introduces a level
of complexity probably not warranted for the gains to be made (imho, at
least).

/Al

Having read the very enlightening thread, my mind got to wondering about
what happens if the network is down - do the Logon Scripts cater for it
satisfactorily ??

Pete (Northolt UK)

"Justin R." wrote:

"p byers" <pb@xxxxxx-ltd.co.uk> wrote in message
news:494C89C3.2A1C8813@xxxxxx-ltd.co.uk...This depends somewhat on what you would consider satisfactory.

Domain-based logon scripts will only run for domain users logging on at
workstations having network connectivity to at least one domain controller.
They will not run for local user accounts, or for anybody if the network is
not accessible.

So, the basic answer would be that the logon scripts themselves, since they
would not run at all without network connectivity, would not cater for
anything.

That said, once a domain user is logged on with cached credentials he could
certainly run a "local copy" of the domain logon script manually if such a
file was maintained as per some of the suggestions in this thread. But the
"satisfactoriness" of the result would depend on what that script was
supposed to accomplish, and whether or not network connectivity was required
for it to succeed. If the network is down, then no drives will be mapped to
any server shares, and no network printers will be installed.

Our workstations map the "my documents" folder to a folder in the user's
home directory, which is on a server share. If they logon with cached
credentials, they can work locally, but if their profile has not yet run MS
office, they will have some problems. In some cases I have setup a batch
script that runs from the START - All Programs - Startup folder. If it finds
that the drive letter normally mapped to their home folder does not exist,
it will do something like this:

subst M: "%USERPROFILE%\mY dOCUMENT