Windows 2003 server. Cannot access domain!
Windows 2003 server. I recently restored Active Directory and now when I try to log on from a workstation, it says that the domain is not available. I can log onto to the domain server locally, however.
Tried the usual reboots but no avail.
Any suggestions?
Tried the usual reboots but no avail.
Any suggestions?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
and the solution is to exit the domain and join again ;o)
ASKER
Yes it was older than 60 days - just a few more days so.
So I have to do that for ALL the workstations?
So I have to do that for ALL the workstations?
Well, restoring after tombstone is a risky proposition. Everything from day 60+ is gone.
Quote:
Age
A backup that is older than the tombstone lifetime set in Active Directory is not a good backup. At a minimum, perform at least two backups within the tombstone lifetime. The default tombstone lifetime is 60 days. Active Directory incorporates the tombstone lifetime into the backup and restore process as a means of protecting itself from inconsistent data.
Deleting an object from Active Directory is a two-step process. When an object is deleted in Active Directory, the object gets converted into a tombstone, which is then replicated to the other domain controllers in the environment to inform them of the deletion. Active Directory purges the tombstone when the tombstone lifetime is reached.
If you restore a domain controller to a state prior to the deletion of an object, and the tombstone for that object is not replicated to the restored domain controller before the tombstone expires, the object remains present only on the restored domain controller, resulting in inconsistent data. Thus, you must restore the domain controller prior to expiration of the tombstone, and allow inbound replication from a domain controller containing the tombstone to complete prior to expiration of the tombstone.
Active Directory protects itself from restoring data older than the tombstone lifetime by disallowing the restore. As a result, the useful life of a backup is equivalent to the tombstone lifetime setting for the enterprise.
:End Quote
Reference: http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/maintain/opsguide/part1/adogd03.mspx
Rejoining workstations to the domain is likely a small portion of the issues you're going to see.
Quote:
Age
A backup that is older than the tombstone lifetime set in Active Directory is not a good backup. At a minimum, perform at least two backups within the tombstone lifetime. The default tombstone lifetime is 60 days. Active Directory incorporates the tombstone lifetime into the backup and restore process as a means of protecting itself from inconsistent data.
Deleting an object from Active Directory is a two-step process. When an object is deleted in Active Directory, the object gets converted into a tombstone, which is then replicated to the other domain controllers in the environment to inform them of the deletion. Active Directory purges the tombstone when the tombstone lifetime is reached.
If you restore a domain controller to a state prior to the deletion of an object, and the tombstone for that object is not replicated to the restored domain controller before the tombstone expires, the object remains present only on the restored domain controller, resulting in inconsistent data. Thus, you must restore the domain controller prior to expiration of the tombstone, and allow inbound replication from a domain controller containing the tombstone to complete prior to expiration of the tombstone.
Active Directory protects itself from restoring data older than the tombstone lifetime by disallowing the restore. As a result, the useful life of a backup is equivalent to the tombstone lifetime setting for the enterprise.
:End Quote
Reference: http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/maintain/opsguide/part1/adogd03.mspx
Rejoining workstations to the domain is likely a small portion of the issues you're going to see.
yup.. you will have to do that for all computers ..
if the restore was older than 60 days you will also get issues with passwords expired.. group memberships, new users that are unknown. etc etc.
if the restore was older than 60 days you will also get issues with passwords expired.. group memberships, new users that are unknown. etc etc.
ASKER
Actually I didn't use a restore - I used a mirrored hard drive - so once the workstations are clean out and rehoind, tombstone shouldn't be an issue, right?
Whatever method you used, the AD is out of date.
Once you rejoin the workstations, you'll have to also reset all the user passwords that are NOT set to never expire.
Then we'll see what else is broken.
Once you rejoin the workstations, you'll have to also reset all the user passwords that are NOT set to never expire.
Then we'll see what else is broken.
ASKER
I don't follow. What determines that the AD is out of date? If the hard drive with the entire windows installation on, including system files and AD, was mirrored, then as far as I can see, emptying the profiles and rejoining the workstations could work
How about temporarily putting back the date on all the machines?
How about temporarily putting back the date on all the machines?
Timestamps on all objects compared with current time and date is what determines currentness.
Once you've booted into the server the current time and date are written in the directory so rolling back the clocks will just create more issues.
You stated this mirror is more than 60 days old. If the mirror was current (as in the day the primary drive failed) then there should be no issue if you boot from it.
Once you've booted into the server the current time and date are written in the directory so rolling back the clocks will just create more issues.
You stated this mirror is more than 60 days old. If the mirror was current (as in the day the primary drive failed) then there should be no issue if you boot from it.
ASKER
>If the mirror was current (as in the day the primary drive failed) then there should be no issue if you boot from it.
Sorry, can you explain this? Don't follow...
Sorry, can you explain this? Don't follow...
Mirrored drives are normally both installed in the server - one drive is primary and the other is a mirror. Is this what you mean by mirrored drive?
ASKER
We use dynamic drives (yeah I know sux) that mirror each other. So I guess one is a mirror and another primary but if the primary fails the mirror will boot, and the boot.ini is modified automatically. I happened to have a disk containing either a mirror or primary that was about 3 months old, and it was easier to try this, update the file server from a recent back up, rather reinstall the whole operating system.
I'm a bit worried about this AD problems I might be faced with, but am prepared to spend a few days to fix them, if fixing them is feasible. Thanks for your help so far - it's been most useful.
I'm a bit worried about this AD problems I might be faced with, but am prepared to spend a few days to fix them, if fixing them is feasible. Thanks for your help so far - it's been most useful.
If you have a recent backup why aren't you using that?
ASKER
It was just a manual backup of the contents of the file server.
if you can I would do a windows repair on the bootless disk so it creates a boot section on the disk this way your ad is newer.
ASKER
>if you can I would do a windows repair on the bootless disk so
>it creates a boot section on the disk this way your ad is newer.
Unfortunately, the drive letter changed on the bootless disk. I moved the boot sector manually, and then found I couldn't log on. Nor could I log on to do a windows repair. I still have the disk and if I could log on to it I could repair it. Anyway, I'm using the earlier back up. Some people came in to the office today and were able to log on without any problems. I have not experienced any password problems. It seems only my laptop was affected so far.
>it creates a boot section on the disk this way your ad is newer.
Unfortunately, the drive letter changed on the bootless disk. I moved the boot sector manually, and then found I couldn't log on. Nor could I log on to do a windows repair. I still have the disk and if I could log on to it I could repair it. Anyway, I'm using the earlier back up. Some people came in to the office today and were able to log on without any problems. I have not experienced any password problems. It seems only my laptop was affected so far.
use a windows cd ... boot from the cd and tell it to install. I should find the current installation (independed on the drive letter) than choose repair.
ASKER
In order to carry out a repair as you suggest, I need to log on via the windows CD in the command screen. I cannot log on. This was the whole problem!!!
ASKER
Anyway - I've decided to go with the old AD option and fix the isues that arise - that is if they are all fixable. We don't have the possibility now to have the server offline except for short periods now and again. I personally have some time (a few days) to fix any problems that may arise out of this.
What I would really appreciate is a worse case scenario with this type of operation.
What I would really appreciate is a worse case scenario with this type of operation.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
>let us know if youhave any other problems and we can address them as they come up
Thanks!!
Thanks!!
How's it going? Any problems since the restore?
If not, can you please close this questions so that we know you are up and working :)
If not, can you please close this questions so that we know you are up and working :)
ASKER
Ok, only one problem noticed so far. Some Group policies aren't working.