Here is a link to a VBscript that will do
this:
http://www.microsoft.com/technet/community/scriptcenter/compmgmt/scrcm31.mspx
As mentioned, it only works with Windows
XP or Windows Server 2003 boxes.
From: rpuckett
[mailto:[EMAIL PROTECTED]
Sent: Friday, April 30, 2004 2:07
PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Joining
Workstations to our domain
Mark,
If you boxes are
working with Windows XP, there are a few scripting options available to you
that can help with this. WMI's Win32_ComputerSystem class supports a
method called JoinDomainOrWorkgroup, that will allow you to programmatically
join systems to a target domain. You could use this function in
conjunction with a validation script that a.) checks for an active network connection,
b.) checks for the availability of a Domain Controller prior to activating the
join process. It could even be used to send prompts to users like,
"hey, plug yer box in!" before firing off a join request. You
could also add in a few ADSI calls to add Domain groups/users to local
groups to complete the process.
If you are still
running Windows 2000, there are associated Win32 APIs (NetJoinDomain) that can
be used with compiled languages like VB/C++ to generate simple domain join
utilities that can also be leveraged by scripts or written to encompass the
functions referenced above. This is what we did here to get around the
remote build process/domain join dilemma.
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Creamer, Mark
Sent: Friday, April 30, 2004 3:11
PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Joining
Workstations to our domain
We are
doing what you guys are suggesting to a point. Currently the vendor prepares
the PC to the point where it’s ready to plug into the network at the
remote location. When the end user receives it, if he follows the instruction
sheet, he plugs it in to the jack and powers up. The PC gets a DHCP address,
and sysprep runs a script asking for a few pieces of information that are
sitting in front of the user. It then creates the PC name, joins to the domain,
reboots, and comes up ready use. The problem had been that the users
don’t always plug in to the jack, so the script fails, and there was no
loop built in – if it fails, it doesn’t try again. So that
generates a help desk call.
The goal
here is to take that last piece out of the user’s hands and have the
vendor join the PC. Then it could be not only ready to use, but could be fully
patched and AV’d beyond whatever is on the ghost image.
I did an
ethereal capture this morning, and I think I now know all of the ports
I’ll need (definitely not all the ports listed below as far as I can tell
so far). We intend to use a firewall to limit the allowed traffic, and a
Contivity VPN to manage the connection. Apparently the VPN box includes the
ability to pare down the allowed times of day the PC can be connected.
Thanks for
the excellent suggestions and pointers to further info
-----Original Message-----
From: Roger Seielstad
[mailto:[EMAIL PROTECTED]
Sent: Friday, April 30, 2004 2:56
PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Joining
Workstations to our domain
Problem
with Sysprep is that its not ready for the user to use. That would work well,
however...
--------------------------------------------------------------
Roger D. Seielstad - MTS MCSE MS-MVP
Sr. Systems Administrator
Inovis Inc.
From: Rich Milburn
[mailto:[EMAIL PROTECTED]
Sent: Friday, April 30, 2004 2:45
PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Joining
Workstations to our domain
If you
have them use sysprep with a script (sysprep.inf) and give them an account and
password delegated to join the domain, then it would do what Roger
suggested. It works very nicely, and it can ask the user for their name
when they boot it up if you want, etc – or it can be totally automated.
Rich
Sample
code from sysprep.inf:
[Identification]
JoinDomain=domain.com
DomainAdmin=deploy.windows
DomainAdminPassword=Winq34v8%shn3AFc8$2
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Seielstad
Sent: Friday, April 30, 2004 1:09
PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Joining
Workstations to our domain
It
might make more sense to do something akin to a script of an application that
they add to the runonce at startup - so when the machine gets booted for the
first time, it joins the domain and is rebooted, then its ready to roll.
--------------------------------------------------------------
Roger D. Seielstad - MTS MCSE MS-MVP
Sr. Systems Administrator
Inovis Inc.
From: Mike
Hogenauer [mailto:[EMAIL PROTECTED]
Sent: Friday, April 30, 2004 2:03
PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Joining
Workstations to our domain
Mark,
I personally wouldn’t consider doing this but I can see why
you might want to. AD can make your firewalls look like swish cheese. You could
create an account for your vendor and delegate that account to join
workstations to the Domain.
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/deploy/confeat/adrepfir.mspx
Ports
|
RPC endpoint mapper
|
135/tcp, 135/udp
|
|
Network basic input/output system (NetBIOS) name service
|
137/tcp, 137/udp
|
|
NetBIOS datagram service
|
138/udp
|
|
NetBIOS session service
|
139/tcp
|
|
RPC dynamic assignment
|
1024-65535/tcp
|
|
Server message block (SMB) over IP (Microsoft-DS)
|
445/tcp, 445/udp
|
|
Lightweight Directory Access Protocol (LDAP)
|
389/tcp
|
|
LDAP over SSL
|
636/tcp
|
|
Global catalog LDAP
|
3268/tcp
|
|
Global catalog LDAP over SSL
|
3269/tcp
|
|
Kerberos
|
88/tcp, 88/udp
|
|
Domain Name Service (DNS)
|
53/tcp1,
53/udp
|
|
Windows Internet Naming Service (WINS) resolution (if
required)
|
1512/tcp, 1512/udp
|
|
WINS replication (if required)
|
42/tcp, 42/udp
|
|
|
|
Hope that helps,
Mike
From: Creamer,
Mark [mailto:[EMAIL PROTECTED]
Sent: Friday, April 30, 2004 5:15
AM
To: [EMAIL PROTECTED]
Subject: [ActiveDir] Joining
Workstations to our domain
Good morning, I’d like to see what the group thinks about
this. We have a vendor who prepares PCs for us with our image, and then ships
them out to our field locations pre-configured. They’d like to take that
a step further, and actually pre-join the PC to the domain before it leaves
their facility. To do this, we would have to set up a secure connection between
our facility and the vendor’s. If we do this, I’d obviously like to
make this as limited as possible in terms of what the user at the vendor is
allowed to do.
My initial thoughts are:
1.
see if I
can determine what ports are needed for a PC to join a domain, and limit the
ports to those
2.
see if I
can limit the rights of the vendor “user” to be able to do nothing
but join a PC to the domain
Right now, I have no idea if this is a good idea, common practice,
etc., so I’m very interested in the advice from this list –
especially if there might be a good solution to this problem other than the way
we’re considering. Thanks as always,
Mark Creamer
Systems
Engineer
Cintas
Corporation
Honesty
and Integrity in Everything We Do
-------APPLEBEE'S INTERNATIONAL, INC. CONFIDENTIALITY
NOTICE------- PRIVILEGED / CONFIDENTIAL INFORMATION may be contained in this
message or any attachments. This information is strictly confidential and may
be subject to attorney-client privilege. This message is intended only for the
use of the named addressee. If you are not the intended recipient of this
message, unauthorized forwarding, printing, copying, distribution, or using
such information is strictly prohibited and may be unlawful. If you have
received this in error, you should kindly notify the sender by reply e-mail and
immediately destroy this message. Unauthorized interception of this e-mail is a
violation of federal criminal law. Applebee's International, Inc. reserves the
right to monitor and review the content of all messages sent to and from this
e-mail address. Messages sent to or from this e-mail address may be stored on
the Applebee's International, Inc. e-mail system.
|
