Wireless Computers and Logon Scripts (Windows 2000)

[Chris]

There is a huge issue in our organization with wireless
computers not being able to execute the logon scripts from
the 'domain controllers', (this is based on the wireless
client not being able to validate with the domain
controller, so as a result, clients are logging on
using 'cached credentials'. We need to implement a
centrally managed solution for logon script execution to
replace our current solution. Many of our clients will be
using wireless connections in the future so the solution
must work with wireless clients. Executing the logon
script locally on each computer at startup might not be a
viable solution based on the fact that we would have to
update the logon script on 120 computers each time there
is a change with the logon script. Microsoft strongly
suggests the use of domain logon scripts as best practice.
Is there a workaround for this issue which would force all
wireless clients to to logon using thier 'domain' account
and password and not use cached credentials?

 

[Cary Shultz [A.D. MVP]]

Chris,

What are the client machines: WIN2000 or WINXP Pro? What is your current
solution? Do you have non-wireless clients? If so, does the logon script
work for them?

Cary

 

[Chris]

Currently, all client machines in the firm are Windows
2000, and will be upgraded to Windows XP in August. Our
current solution (in my department) is the use
of 'Kixstart' logon scripts executed from an NT 4.0 Domain
controller. The login.bat file is specified in the user's
account profile for all users in this department.
The 'company' at the enterprise level, has implemented AD
and now ask our department to join in. We need to migrate
all of out NT accounts into AD first. Once our
department's AD user accounts are created we need to
access resounces back in the department's NT domain
through a trust relationship (until phase 2 in July, which
is migrating our servers into our respective OU). The AD
administrator is telling us login scripts will not run
from AD domain controllers for wireless computers.
Currently, We do not have wireless clients.
Thanks,
Chris

 

[Cary Shultz [A.D. MVP]]

Chris,

POINT 1: Kixtart has a little different set up. Logon.bat does not work
without the kix32.exe ( IIRC ). And I am not sure that you can use
'logon.bat' - I *think* that you need to use 'logon.kix'. But I am not 100%
sure on this. We use kixtart in only one location. I prefer to use .vbs
via GPO in a WIN2000+ environment. Naturally, that depends on what you need
the logon script to do. Additionally, you need to make sure that both the
'kix32.exe' and 'logon.kix' files are in the shared NETLOGON folder in all
DCs ( simply place them in one and they will replicate to the other DCs ).
Further, you need to make sure that in each user account's properties in the
PROFILE tab that you have entered 'kix32.exe logon.kix' in the logon script
field.

POINT 2: I am not sure why whoever is telling you that wireless clients can
not authenticate against a WIN2000 AD Domain Controller / run a logon script
is saying that. I can speak from experience that if you set things up
correctly that the wireless clients will work just as well as the wired
clients. I have done this in two locations. Worked very well ( once you
figure out everything! ). There are occasional issues with losing the
signal ( access point is bumped or the clients go out of 'range' or
whatnot ) but it works nonetheless. And the logon scripts ( both .cmd and
..bat in the two cases ) run just fine. This was a year ago and they are
still running strong!

POINT 3: I would consider using NETDOM to set up the trusts between your
WINNT and WIN2000 domains. It works *better* than using the ADDT MMC. You
need to install the Support Tools ( which can be found on either the WIN2000
Server CD or the WIN2000 Service Pack CD in the Support | Tools folder ) to
have NETDOM available.

Have you already migrated the user/computer/group accounts over via ADMT v2
or are you creating the account from scratch in the WIN2000 domain?

Cary

 

[Guest]

Cary,

Point 1. We are using Kixstart because it's easy to run
and mangae changes and allows us many options for mapping
resources and setting env. variables all in one file. I
suppose .vbs script would accomplish the same thing but
Kixstart is essentially the same.

Point 2. I would have to get more information back from
the person who administers the AD clients. He did not
provide me any of the details yet on exactly what happens
with the client, what wireless software and switch is
being used. Once i have those details i will send them to
you.

Point 3. I will definatley research the NETDOM from the
support tools and make that reccomendation. One thing I
can say is we dont have much control over how the Trust
Relationship works. We are completely out of cotrol from
thier operation. They make all the decisions. Sounds good
though.

I will send you the details on the wireless client issue.

Thanks so much!

-----Original Message-----
Chris,

POINT 1: Kixtart has a little different set up. Logon.bat does not work
without the kix32.exe ( IIRC ). And I am not sure that you can use
'logon.bat' - I *think* that you need to

use 'logon.kix'. But I am not 100%

 

[Cary Shultz [A.D. MVP]]

Chris,

in-line....

Cary,

Point 1. We are using Kixstart because it's easy to run
and mangae changes and allows us many options for mapping
resources and setting env. variables all in one file. I
suppose .vbs script would accomplish the same thing but
Kixstart is essentially the same.

I agree. KixTart is a good scripting language. The logon scripts that we
use are very basic. We use Kixtart in the one environment because of a
couple of things that are needed that are fairly easy in Kixtart and a bit
more involved in .vbs.

Point 2. I would have to get more information back from
the person who administers the AD clients. He did not
provide me any of the details yet on exactly what happens
with the client, what wireless software and switch is
being used. Once i have those details i will send them to
you.

The one thing that I would suggest is that you do the research on the Access
Point and the network cards. If you purchase the incorrect NIC for that
particular access ppint you will have a lot of grieve! Really really really
check into this before deploying.

Point 3. I will definatley research the NETDOM from the
support tools and make that reccomendation. One thing I
can say is we dont have much control over how the Trust
Relationship works. We are completely out of cotrol from
thier operation. They make all the decisions. Sounds good
though.

Hopefully they will know. You can indeed establish the trusts with the MMC.
I have seen several times myself - and read several posts in this NG -
where everything is in place and it just does not work when using the MMC.
Do it with NETDOM and there is not an issue. To repeat, this naturally
assumes that everything else is in order.

I will send you the details on the wireless client issue.

Thanks so much!

You are very welcome.

Cary

 

[Cary Shultz [A.D. MVP]]

If I could only spell correctly!

Cary

Chris,

in-line....



I agree. KixTart is a good scripting language. The logon scripts that we
use are very basic. We use Kixtart in the one environment because of a
couple of things that are needed that are fairly easy in Kixtart and a bit
more involved in .vbs.



The one thing that I would suggest is that you do the research on the Access
Point and the network cards. If you purchase the incorrect NIC for that
particular access ppint you will have a lot of grieve! Really really really
check into this before deploying.




Hopefully they will know. You can indeed establish the trusts with the MMC.
I have seen several times myself - and read several posts in this NG -
where everything is in place and it just does not work when using the MMC.
Do it with NETDOM and there is not an issue. To repeat, this naturally
assumes that everything else is in order.





You are very welcome.

Cary