spectrum48k

Ok, just been through all of that again. Went into ADSI Edit and checked for the creation of: (which is there)
CN=Windows2003Update,CN=DomainUpdates,CN=System,DC =dn path of domain you are upgrading exists

so ADPREP /forestprep and ADPREP /domainprep were successfully invoked prior to adding the Win2k3 DC to the domain.

Is there anything to gain from mentioning the Win2k DC originally (7 years ago) was upgraded from NT4 Server ? (think I heard a long groan there!)

Hanley

I'm beginning to run out of ideas mate.

You need to establish whether this issue is the 2K / 2003 mix.

In order to do that you'd need to bin off your 2003 DC, ensuring you use DCPROMO to remove AD.

Then install Windows 2000 Server onto the box and try to configure it as a DC and see what happens.

If you manage to establish a second functioning domain controller on Win2K then it gives a clear idea where the problem lays.

All good fun eh?

Look on the bright side, your experience of AD has probably shot right up the past few days

spectrum48k

According to the Win2k3 server its log is telling me the problem here:

Event Type: Error
Event Source: NTDS Replication
Event Category: Replication
Event ID: 1084
Date: 27/02/2009
Time: 21:24:14
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: DOMAINCONTROL
Description:
Internal event: Active Directory could not update the following object with changes received from the following source domain controller. This is because an error occurred during the application of the changes to Active Directory on the domain controller.

Object:
CN=,CN=ObjectMoveTable,CN=FileLinks,CN=System,DC=G KC,DC=LOCAL
Object GUID:
ab3fc985-ef1f-4384-9dda-330a2ca2a062
Source domain controller:
ce5a8212-3eaf-4dde-a915-f21f04c50bb4._msdcs.GKC.LOCAL

Synchronization of the local domain controller with the source domain controller is blocked until this update problem is corrected.

This operation will be tried again at the next scheduled replication.

User Action
Restart the local domain controller if this condition appears to be related to low system resources (for example, low physical or virtual memory).

Additional Data
Error value:
8442 The replication system encountered an internal error.

For more information, see Help and Support Center at Events and Errors Message Center: Basic Search.





When I try to delete the object GUID on the Win2k DC, using LDP, it tells me it can't as its "BUSY"

Hanley

You may need to boot the server into DSRM mode....or whatever the Windows 2000 equivalent is, I can't remember now

Hanley

Try disabling the Distributed Link Tracking Server service on your Windows 2000 box...it should be disabled by default on the 2003 server but check anyway

Then re-try replication

spectrum48k

Ok mate - will try.

I've bothered you enough now. I'll head off to google and check out some Windows server forum where I can bother someone else for a bit!

spectrum48k

Yeah, as part of my background reading on google, I found that one and disabled it on the Win2k box. Lnock on effect is DCDIAG reports it failing its SERVICES test, as its see it as disabled.

Will check the Win2k3 box to see if its disabled on there.

Hanley

Don't worry about that....we disable 80% of services on DC's that sit in our DMZ

hodgy0_2

can you ping the GUID, listed in DNS of both servers -- output looks like below?

do you have the service records for both DC's in DNS?

S:\>ping 1f0489a8-4926-493f-a1fd-1155bc9c3c14._msdcs.XXXX.local

Pinging server3.XXX.local [172.16.1.4] with 32 bytes of data:

Reply from 172.16.1.4: bytes=32 time<1ms TTL=128
Reply from 172.16.1.4: bytes=32 time<1ms TTL=128
Reply from 172.16.1.4: bytes=32 time<1ms TTL=128

hodgy0_2

also make sure the DC's dates & times are sync'd

if they are more than 5 mins out they will not replicate

spectrum48k

thanks mate - checked and yes, I can ping - the object in question lies on the Win2k DC

spectrum48k

dates and times are identical

spectrum48k

I'm convinced these problems are coming from the Win2k DC having something up with it SOMEWHERE. Do you think it's worth running a repair from the original CD ?

I've found a spare computer I'm going to install Windows 2000 Server onto and try and make that an additional DC.



I want to check out any issues with SYSVOL, as brought up in the DCDIAG results which mentions any problem with SYSVOL could result in AD not starting.

Could someone be kind enough to check their SYSVOL against mine ? I want to know what's in the SYSVOL folder, who has access to what, and what is shared

At present I have
c:\winnt\sysvol\ (not shared)

Inside I have
domain, staging, staging area, sysvol (shared)

Is there a way to check integrity of SYSVOL ?

hodgy0_2

That looks correct to me

the sysvol should be shared as part of the netlogon service

yes you can edit the registry and do an authoritative restore of sysvol

in my experience the FRS service is a bit flaky and sometimes needs to be kicked in action

see the following articles

How to rebuild the SYSVOL tree and its content in a domain

Recovering missing FRS objects and FRS attributes in Active Directory

Recovering FRS objects and files using system state restores

Hanley

I agree you should try and build another Windows 2000 server and see if you can promote that to a DC

Being only a single DC environment you wouldn't have noticed any SYSVOL and / or replication errors prior to installing your second DC.

You may after all, have to bite the bullet, and go for an upgrade of your existing box.

spectrum48k

Thanks Hodgy, will check that. Much appreciated.

spectrum48k

Gulp! That fills me with dread! I suppose the best way to upgrade the existing Win2k box to Win2k3 would be to use a strategy something like this...

1. Introduce an additional Win2k DC to the domain. Make sure its replicating properly so it can be used as a replacement for the old Win2k DC, in case anything goes wrong with step 3 (below)

2. Take a full backup image of the existing Win2k DC. We use Acronis True Image. Must make sure Acronis can boot from DOS and see the Ultra320 scsi drives the old Win2k box uses.

3. Perform the upgrade of the old Win2k DC to Win2k3 - can I use our Win2k3 Standard Edition CD to do this ? We should then have a Win2k3 DC (running on old hardware)

4. Add the new Win2k3 box to the Wink3 domain as an additional DC. Check replication, etc....

Sound like a plan ?

Hanley

If you introduce a second Windows 2000 DC and it manages to replicate with your original server without any problems then I would try the following before doing an upgrade:

1. Transfer all the FSMO roles to the new 2000 DC
2. Take your old DC offline (power off)
3. Ensure users can log-on and all AD functions are working as they should
4. Build a Windows 2003 server and promote to a DC

If you do the above and the 2003 DC operates fine then you can decommission your Windows 2000 DC's - personally I would still want to build a second 2003 DC for my own piece of mind.

If you do the above and you're still having problems then refer to your upgrade plan....as well as your Acronis backup I would also use NTBackup to take a system state backup and lock it away in a cupboard somewhere.

I'm not sure if you can use your exisitng Windows 2003 media...only one way to find out.

hodgy0_2

or, if you've only got 20 machines and a similiar number of users

just build a brand new infrastructure along side your exitsing one -- at least then you know you are not introducing any **** into it

create the users -- will give you the ability to sort out groups/permission properly -- add the workstations, job done

Hanley

If you're going to go down that route then use the Active Directory Migration Tool

See here for a good guide

hodgy0_2

for that number of users and workstation I wouldn't bother

you can use the GPMC tool to list all your GPO setting etc -- copy logon scripts etc

recreate all the groups etc

the only advantage the migration tool would give you is keeping passwords etc

In these situations I often use the "moving train” approach, bring your new infrastructure "up" along side existing one, get its all functioning, recreate groups gpo’s etc then move the users a and workstations over

File servers can be moved in and permissions set by scripts etc

All this is assuming you don’t have a really complicated AD -- and the beauty is you can document it all and start from a known good base

Often migration tools just allow you two migrate all the crap with all the good stuff

All in my opinion off course

Hanley

I agree, to some extent.

Having always worked in fairly large corporate AD environments it wouldn't be an approach we would use often.

But it would work

spectrum48k

UPDATE:

Thought you guys might want to hear this. I found a spare PC (old Supermicro 1u server) and installed Windows 2000 Server on it. Added it to the domain then DCPROMO'd it. The wizard finished successfully, but a quick check of the event logs showed replication wasn't happening!

Same problem as the last time - there's an object in the AD which is either orphaned or something that's preventing initial syncronization / replication. So this kind of confirms the problem was NOT with any of the new servers I'd created - the problem was with an issue in the AD on the main Win2k DC.

Sooooo.....

My options right now are:

1. Use NTDSUtil to go into the AD and perform a FILES > INTEGRITY check and possible FILES > REPAIR, then possibly a Semantic Database Analysis (listen to ME, I almost sound like I know what I'm talking about )

2. Perform an upgrade of the same problem server to Win2k3 in the hope it clears up the issue as part of the upgrade ?

3. Take your advice and create this new infrastructure alongside the old one. Do you mean create a new Win2k3 domain controller on a new domain and recreate the user accounts ,etc... I think this would be pretty straight forward.

spectrum48k

meant to say this proves the problem WAS NOT with any of the new servers I added. The problem lies with the original server

hodgy0_2

yep -- thats what I would do, in a small AD environment wouldn't take long

the only thing is these would be new accounts so they would have to enter new password

obviously you would have to recreate the groups, if less than 20 groups I would enter manualy any more and you can write a simple script

but the beauty is you always have the original AD to refer to

spectrum48k

That does appeal - starting from scratch so to speak. So I can create this server and test it away from the domain. Could I use the same domain name we already use ?

What do you mean by GROUPS ? User groups ? We don't really bother as the 20 LAN members are easy to maintain individually. The all use a global logon script too, mapping them to the public folder on the server.

No exchange or anything like that. Just an financial accounts application that will need to be moved (reinstalled) to the new server, along with a MySQL database that talks to a ColdFusion application I wrote.

hodgy0_2

depends what you mean by domain if you mean external DNS domain yes

if you mean AD domain then no, unless you build on a seperate LAN, because you will get naming conflicts otherwise

my advice is to call your AD domain something generic like group.ad or ad.local, its much more flexible way of doing things

groups -- yes that what i meant -- even easier, you prob don't use group policies either

spectrum48k

ok, so current domain is gkc.local , and the new one could be gkc2.local ?

can you have 2 domains on one LAN ? eg. currently the LAN uses IP ranges 192.168.0.1 - 254

could I just create the new DC, with the new domain name, and put it at 192.168.0.20 ? I'd asssume none of the workstations would be affected as they're not members of the new domain ?

hodgy0_2

yes -- with one proviso

you can only have one DHCP server, which is not to much of a problem because the new server/s will be static, and when you are ready to change the workstations over just commission the DHCP scope on the new AD

you just have to manage the change over carefully, thats all really

spectrum48k

All PC's are assigned a static IP as there's only 20 of them. We do use a DHCP server, but its on the SonicWall.

Once I'm ready to switch over, I'll just change the DHCP settings - specifically setting the clients to use the new DNS server (which will reside on the new Win2k3 DC)

Sounds like a plan!