Export/import of computer accounts

Hi everybody,

If I have a little local network with just one "old" DC (DC
= domain controller) "Windows 2003 server" with theses
features :

- DNS name of the domain : yourcenar.local
- DNS name of the DC : srv.yourcenar.local
- NetBios name of the domain : YOURCENAR
- IP : 172.20.0.2

Let's suppose I want to install "new" DC in a new computer
with exactly the same features (the same OS, the same dns
name, the same IP etc). Of course, first I turn off the
"old" DC, and secondly I install the "new" DC.

Then, I create the same computer accounts which were in the
Active Directory of the "old" DC (with a .csv file and a
little script for example). If I try to open a session on a
client PC with a user account, it doesn't work (it would be
too simple). Is it possible to import the computer accounts
so as to open a session in a client PC without ever
configurating the client PC (particularly without joining it
manually to the "yourcenar.local" domain)?

To be more clear, I'm going to make a comparison with the
user accounts. If, in the "old" DC, I create myself the user
accounts and If the users can't change the password, I can
make a csv file like this :

user1;password1
user2;password2
user3;password3
etc...

Thus, in the "new" DC, I can import the user accounts and
the users keep their password and don't realize the change
of DC. Is it possible to make an export/import of the
computer accounts by the same way?

Thanks in advance for your help.


--
François Lafont

"francois" <> wrote in message
news:...
> Hi everybody,
>
> If I have a little local network with just one "old" DC (DC = domain
> controller) "Windows 2003 server" with theses features :
>
> - DNS name of the domain : yourcenar.local
> - DNS name of the DC : srv.yourcenar.local
> - NetBios name of the domain : YOURCENAR
> - IP : 172.20.0.2
>
> Let's suppose I want to install "new" DC in a new computer with exactly
> the same features (the same OS, the same dns name, the same IP etc). Of
> course, first I turn off the "old" DC, and secondly I install the "new"
> DC.
>
> Then, I create the same computer accounts which were in the Active
> Directory of the "old" DC (with a .csv file and a little script for
> example). If I try to open a session on a client PC with a user account,
> it doesn't work (it would be too simple). Is it possible to import the
> computer accounts so as to open a session in a client PC without ever
> configurating the client PC (particularly without joining it manually to
> the "yourcenar.local" domain)?
>
> To be more clear, I'm going to make a comparison with the user accounts.
> If, in the "old" DC, I create myself the user accounts and If the users
> can't change the password, I can make a csv file like this :
>
> user1;password1
> user2;password2
> user3;password3
> etc...
>
> Thus, in the "new" DC, I can import the user accounts and the users keep
> their password and don't realize the change of DC. Is it possible to make
> an export/import of the computer accounts by the same way?
>
> Thanks in advance for your help.
>
>
> --
> François Lafont

You already have an Active Directory domain. I assume your users log into
the domain. They do not logon with local accounts on their client computers.
You can install Active Directory on another computer and specify that it is
in the existing domain. This computer will become a DC in the domain. All of
the accounts (and passwords) in the copy of AD on the first DC will
automatically replicate to the new DC. You don't need to do anything. This
is the purpose of Active Directory. Users will still logon to the domain and
one or the other of the two DC's will authenticate them. The new DC needs to
have a different IP address and NetBIOS name. Does this make sense?

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

Richard Mueller [MVP] a écrit :

> You can install Active Directory on another computer and specify that it is
> in the existing domain. This computer will become a DC in the domain. All of
> the accounts (and passwords) in the copy of AD on the first DC will
> automatically replicate to the new DC. You don't need to do anything. This
> is the purpose of Active Directory. Users will still logon to the domain and
> one or the other of the two DC's will authenticate them. The new DC needs to
> have a different IP address and NetBIOS name. Does this make sense?

Ok, I understand and it's a meaningful answer.

But the fact of recreating my "Active directory" accounts
just with files (csv files and scripts files) pleases me. I
find my question interesting for itself. My domain is
relatively simple: 600 user accounts (for each user, just
one share folder which will be his "My documents on the
network" and 220 computer accounts). But here is the real
reason of my question.

In fact, I have just one and old DC. I'm a teacher in a high
school and I look after the network during my free time. My
fear is the crash of our DC. In this case, the school will
command a new server and, in the best case, we would receive
it in one month. And at this moment, I should recreate a DC
from scratch. This is why I post my message about the
import/export of computer account. The computer accounts are
a little mysterious for me (especially the password of a
computer account).

Thanks Richard for your anwser.



--
François Lafont

You can create certainly script the creation of objects in your
directory. There are two problems though:

1. User Account Security Identifiers cannot be imported: This will
invalidate all of the rights associated with the existing user,
including the user profile on their computer.
2. The computer still has to be joined to the domain, even if you
prestage the account.

Those two combined tend to make the kind of migration you're performing
one of the most time-consuming. Last time I did one like this I
provided estimates that the IT tech's we'd brought in would be able to
completely fix up one machine every 15 minutes. The value is dependant
on a lot of things, but whether you do it in 5 or 15 it still represents
a significant commitment.

I wonder if you might somehow get a second Windows server license and
set that up on a Virtual Machine (under something nice and portable like
VMWare). Keep it running when the domain is alive and take away
snap-shots of it regularly, should the server fail you can rebuild using
the snapshot and most of your client problems go away.

Chris


francois wrote:
> Richard Mueller [MVP] a écrit :
>
>> You can install Active Directory on another computer and specify that
>> it is in the existing domain. This computer will become a DC in the
>> domain. All of the accounts (and passwords) in the copy of AD on the
>> first DC will automatically replicate to the new DC. You don't need
>> to do anything. This is the purpose of Active Directory. Users will
>> still logon to the domain and one or the other of the two DC's will
>> authenticate them. The new DC needs to have a different IP address
>> and NetBIOS name. Does this make sense?
>
> Ok, I understand and it's a meaningful answer.
>
> But the fact of recreating my "Active directory" accounts just with
> files (csv files and scripts files) pleases me. I find my question
> interesting for itself. My domain is relatively simple: 600 user
> accounts (for each user, just one share folder which will be his "My
> documents on the network" and 220 computer accounts). But here is the
> real reason of my question.
>
> In fact, I have just one and old DC. I'm a teacher in a high school
> and I look after the network during my free time. My fear is the crash
> of our DC. In this case, the school will command a new server and, in
> the best case, we would receive it in one month. And at this moment, I
> should recreate a DC from scratch. This is why I post my message about
> the import/export of computer account. The computer accounts are a
> little mysterious for me (especially the password of a computer account).
>
> Thanks Richard for your anwser.
>
>
>

--
Blog: http://www.indented.co.uk
DnsShell: http://code.msdn.microsoft.com/dnsshell

Chris Dent wrote :

> You can create certainly script the creation of objects in your
> directory. There are two problems though:
>
> 1. User Account Security Identifiers cannot be imported: This will
> invalidate all of the rights associated with the existing user,
> including the user profile on their computer.

Yes, but as I said, my AD is relatively simple. All users
have the same *mandatory* profile (stored in the DC) and the
profile is cleaned on the local machine on each logoff (the
users are pupils). Each user has just one share folder (to
store his documents on the network). I have a csv file which
contains (among other things) sAMAaccountName and password.
So, with a script, I can recreate user accounts and rights
within 10 minutes.

> 2. The computer still has to be joined to the domain, even if you
> prestage the account.

Even if the computer has already joined the domain of the
"old" DC (knowing that the "new" DC has the same parameters
as the "old" DC)? Naively, I thought if I had a csv file
containing computerName *and computerPassword*, I could
create the computer accounts and I wouldn't need to join
each computer to the domain of the "new" DC. Is it more
complicated than that? How does it work? This is exactly the
object of my post.

> I wonder if you might somehow get a second Windows server license and
> set that up on a Virtual Machine (under something nice and portable like
> VMWare). Keep it running when the domain is alive and take away
> snap-shots of it regularly, should the server fail you can rebuild using
> the snapshot and most of your client problems go away.

Yes, a virtual machine with a simple snapshot of my DC, that
would be great. But, I need a server with good capacity
(RAM, processor...). Waiting for this, I have just one and
old DC and, as I said, *in the best case*, my high school
can obtain a new server in one month, but in fact in six
month, or even one year.

Thanks for your answer Chris, I keep in mind the idea of
virtual machine. However, I'm always interested in the
initial object of my post (export/import computer accounts
without joining again each computer to the domain of the
"new" DC).



--
François Lafont

> Yes, but as I said, my AD is relatively simple. All users have the
> same *mandatory* profile (stored in the DC) and the profile is cleaned
> on the local machine on each logoff (the users are pupils). Each user
> has just one share folder (to store his documents on the network). I
> have a csv file which contains (among other things) sAMAaccountName
> and password. So, with a script, I can recreate user accounts and
> rights within 10 minutes.

This is the easiest restriction to pass if you're prepared and have
sufficient desire. Mandatory profiles certainly simplifies things

>
> Even if the computer has already joined the domain of the "old" DC
> (knowing that the "new" DC has the same parameters as the "old" DC)?

Yes. No matter how much you make it match on the surface the domains are
not the same. The underlying unique identifiers, SIDs and GUIDs will be
different.

> Naively, I thought if I had a csv file containing computerName *and
> computerPassword*, I could create the computer accounts and I wouldn't
> need to join each computer to the domain of the "new" DC. Is it more
> complicated than that? How does it work? This is exactly the object of
> my post.
It's extremely hard to find explicit detail on that operation, security
subsystems are always tricky in this respect. For the most part you end
up hovering around API documentation from MSDN. For example:

http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

To be honest I would discard the computer password. It's no good to you
because the computer must agree it with the domain when it joins and
negotiate change thereafter. I honestly don't think you'll get to a
stage where you can do anything useful without, ultimately, performing
the domain join operation.

Instead, and if the VM isn't going to work out, you may be better
investigating remote execution of netdom (via WMI perhaps) to join
systems to the new domain. Credentials can be passed along with a WMI
connection allowing you to use a local administrative account to
complete the operation. Add multi-threading and off you go, maybe an
hour to join them all if you stagger it. That's not entirely different
from the process used by tools like ADMT.

Chris

--
Blog: http://www.indented.co.uk
DnsShell: http://code.msdn.microsoft.com/dnsshell

"francois" <> wrote in message
news:%...
> Richard Mueller [MVP] a écrit :
>
>> You can install Active Directory on another computer and specify that it
>> is in the existing domain. This computer will become a DC in the domain.
>> All of the accounts (and passwords) in the copy of AD on the first DC
>> will automatically replicate to the new DC. You don't need to do
>> anything. This is the purpose of Active Directory. Users will still logon
>> to the domain and one or the other of the two DC's will authenticate
>> them. The new DC needs to have a different IP address and NetBIOS name.
>> Does this make sense?
>
> Ok, I understand and it's a meaningful answer.
>
> But the fact of recreating my "Active directory" accounts just with files
> (csv files and scripts files) pleases me. I find my question interesting
> for itself. My domain is relatively simple: 600 user accounts (for each
> user, just one share folder which will be his "My documents on the
> network" and 220 computer accounts). But here is the real reason of my
> question.
>
> In fact, I have just one and old DC. I'm a teacher in a high school and I
> look after the network during my free time. My fear is the crash of our
> DC. In this case, the school will command a new server and, in the best
> case, we would receive it in one month. And at this moment, I should
> recreate a DC from scratch. This is why I post my message about the
> import/export of computer account. The computer accounts are a little
> mysterious for me (especially the password of a computer account).
>
> Thanks Richard for your anwser.
>

As noted, there are tools that can export information about users and then
later import (ldifde for example). However, there are more than 200
attributes of user objects and some cannot be updated. For example, the SID
and GUID values will be different. Another option is to backup AD. If you
backup the System State, you should be able to restore AD on the DC from a
backup. If you only have one DC, this should be relatively simple.

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

Chris Dent wrote :

> Instead, and if the VM isn't going to work out, you may be better
> investigating remote execution of netdom (via WMI perhaps) to join
> systems to the new domain. Credentials can be passed along with a WMI
> connection allowing you to use a local administrative account to
> complete the operation. Add multi-threading and off you go, maybe an
> hour to join them all if you stagger it. That's not entirely different
> from the process used by tools like ADMT.

Ok. Yes indeed, I have tried some tests of migration of
computer accounts (Windows server 2000 --> Windows server
2003) and I have noticed that the concerned computers must
be turned on during the migration, as if a kind of "netdom
join" command was running. If ADMT, a Microsoft tool, needs
that the computers are turned on during the migration (from
a domain "A" to a domain "B"), definitively it means that my
idea of Export/Import of computer accounts, without touching
the computers (the computer could be turned off) is
impossible. :-)

That's clear now. Thanks Chris for these explanations.

However, this discussion led me to try a migration with ADMT
for my first time: a migration of just one computer account
(let's call it "XPclient") from Windows Server 2000 (the
"source" domain) to Windows Server 2003 (the "target"
domain). These two domains are completely separated (in
different forests). I have just one problem: when I ran ADMT
on the "target" domain with an administrator account of this
domain (let's call it "adminTarget"), it didn't work because
this account wasn't local administrator of the "XPclient"
(and the access to "\\XPclient\ADMIN$" was impossible). If I
add "adminTarget" account to the local Administrator group
of "XPclient", the migration works well. But I have one
question: in my test, I have just one computer, but if I
have 60 computers, do I have to add the "adminTarget"
account to the local Administrator group *for each
computer*? Is it possible to avoid this step?

Naively, I thought after this command

netdom trust targetdomain.local /uo:adminTarget /po:***
/d:sourcedomain.local /ud:adminSource /pd:*** /add /twoway
/enablesidhistory

the "adminTarget" account was administrator of "source"
domain too and, consequently, was local administrator for
each computer of the "source" domain. Is it possible to have
this, by systems of including groups? This point is not
clear for me.


--
François Lafont

Richard Mueller [MVP] a écrit :

> As noted, there are tools that can export information about users and then
> later import (ldifde for example). However, there are more than 200
> attributes of user objects and some cannot be updated. For example, the SID
> and GUID values will be different.

Ok, that's clear now. ;-)

> Another option is to backup AD. If you
> backup the System State, you should be able to restore AD on the DC from a
> backup. If you only have one DC, this should be relatively simple.

Ok, thanks for the suggestion. Just one question about this:
does the "active_directory_backup.bkf" file depend on the
platform? For example, if I have an
"active_directory_backup.bkf" file obtained on a "Dell" PC,
can I use this file in a new installation on a "HP" PC?


--
François Lafont

>
> However, this discussion led me to try a migration with ADMT for my
> first time: a migration of just one computer account (let's call it
> "XPclient") from Windows Server 2000 (the "source" domain) to Windows
> Server 2003 (the "target" domain). These two domains are completely
> separated (in different forests). I have just one problem: when I ran
> ADMT on the "target" domain with an administrator account of this
> domain (let's call it "adminTarget"), it didn't work because this
> account wasn't local administrator of the "XPclient" (and the access
> to "\\XPclient\ADMIN$" was impossible). If I add "adminTarget" account
> to the local Administrator group of "XPclient", the migration works
> well. But I have one question: in my test, I have just one computer,
> but if I have 60 computers, do I have to add the "adminTarget" account
> to the local Administrator group *for each computer*? Is it possible
> to avoid this step?
>
Only by running ADMT as an administrator from the source domain instead
of the destination.

It's (generally) easier to grant an administrator from the source domain
the necessary rights in the target domain rather than the other way around.

Alternatively you can fix up local group membership via Restricted
Groups in Group Policy, or small computer start-up scripts (net
localgroup administrators /add remotedomain\administrator).

It's a little bit limited because you cannot add the domain local groups
to the local Administrators group on the PC. And, of course, the foreign
security principal (the user from the trusted domain) can only join
domain local / local groups.

>
> the "adminTarget" account was administrator of "source" domain too
> and, consequently, was local administrator for each computer of the
> "source" domain. Is it possible to have this, by systems of including
> groups? This point is not clear for me.
>

It only creates the trust, it doesn't give rights to any account on
either domain. You would still have to modify rights or group membership
on each domain.

Chris

--
Blog: http://www.indented.co.uk
DnsShell: http://code.msdn.microsoft.com/dnsshell