Re: [ActiveDir] Migration issues(OT)

[Tom Kern]

Thanks. I already did the secondary of target on source and source on target dns, James. Sorry forgot to mention that.

 

I'll look into the kerberos over tcp, Jeff.

Thanks.

 

Another issue, is that some of the clients DHCP servers are still in the old domain(clients update their own A records) so the client gets a connection specific suffix of the old domain and a primary dns suffix of the new domain.

I don't know if this would screw things up.

However, all clients have a suffix search list for resloving flat names that includes the new and old domains.

 

Also, some clients have drives mapped to a Windows NT domain(no trust) in their login script. the script passes a user account and password in the NT domain to do the mappings. I find sometimes this breaks as well. The account used to do the mappings gets locked out sometimes.

 

 

 

 

To further elaborate my dns senario-  The target forest has an empty root. The child dns zone has been delegated to dns servers in the child domain.

DNS is AD intergrated(replicated to all DNS servers in the domain).

 

Thanks again, guys!

 

On 12/28/05, Jeff Salisbury <[EMAIL PROTECTED]> wrote:

Tom - I saw very odd behavior in one of our offices when we migrated them to AD. It affected some, but not all machines, where they couldn't talk to the domain controller and weren't running group policy. Rather than DNS, it turned out to be a Kerberos authentication issue. Something in the network was fragmenting Kerberos UDP packets, which breaks authentication. We found a KB article (don't have it handy but should be easy to search for) that tells you how to force Kerberos to use TCP by making a registry change.

 

The local AD domain controller and clients were all within a local well connected (100 Mbps) network. We never did find out what was causing the Kerberos UDP packets to be fragmented. Either the packets were too big compared to our other offices, or somehow one of the network switches was enforcing a restrictive MTU (not likely). Most other offices did not have this problem, although we did have a few machines here and there that did.

 

Hope this helps!

 

Jeff Salisbury

---

From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Tom Kern
Sent: Wednesday, December 28, 2005 6:39 AM
To: activedirectory

Subject: [ActiveDir] Migration issues(OT)

 

I'm running Quest's AD Migration Manager and some workstations are experiencing issues post migration.

 

Their login scripts don't run(legacy not GPO scripts) and hence their drive mappings don't work.

This is sporadic as some users are fine.

 

The only thing these non working users have in common is that they all log a event id 1000-

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1000
Date:  12/28/2005
Time:  7:28:49 AM
User:  NT AUTHORITY\SYSTEM
Computer: OP5041534335
Description:
Windows cannot obtain the domain controller name for your computer network. Return value (59).

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp .

 

From eventid.net, this seems to indicate network connectivity issues but I don't think that applies here. Many users in the sam location are fine and all workstations are standard images, i,e; indentical.

 

The background is as follows- we are migrating from a win2k native mode forest to a win2k3 FFL win2k3 forest using Quest ADMM.

The servers and user machines are all double ACL'ed and sid history is enabled(sid filtering disabled).

The users have access to their old profiles.

 

The only thing I think could be an issue is DNS.

When the client is moved, he points to the DNS in the target forest. This AD intergrated DNS server forwards anything it dosen't know to a BIND 9 server which conditionally forwards to the source domain if a query is made for something there.

As it stands, all users/workstations have been migrated(copied) but some servers still remain in the source domain as we are in an interim stage right now.

 

Any help or ideas would be great.

Thanks a lot!

Confidential
This e-mail and any files transmitted with it are the property
of Belkin Corporation and/or its affiliates, are confidential,
and are intended solely for the use of the individual or
entity to whom this e-mail is addressed.  If you are not one
of the named recipients or otherwise have reason to believe
that you have received this e-mail in error, please notify the
sender and delete this message immediately from your computer.
Any other use, retention, dissemination, forwarding, printing
or copying of this e-mail is strictly prohibited.