Re: HELP!! Cannot Find Domain When Logging on to Windows Server 20

Tech-Archive recommends: Fix windows errors by optimizing your registry

Okay Wrench:)

You basically confirmed my own stupidity:( But that's okay. One thing I
can safely say is that the customer went against our recommendation of fixing
the old server and decided to buy a new one...which we screwed up...but not
on purpose.

So I think I get your user profile explanation...I will try that and respond
to this once I get that running. Although it will be somewhat time consuming
given that I will have to get to each machine while they are there and they
dont like it when I need to push them away...but if they want it fixed...oh
well:)

As far as backup goes...they had a tape backup previously but it went KAPUT!
So they took their old consultants recommendation and bought a Buffalo
Terastation to replace it. I understand the offsite need and explained that
to them initially so they are aware of the possibility of losing everything
if there was an onsite disaster.

My question though is the following: Based on what I have available to me, I
setup BE to do three weeks worth of backups to the Exchange Store. I used
the wizard and created full backups of each day (M-F) and allowed overwriting
the media. Am I correct in thinking that if I choose the option to append to
existing media that it will simply add the changed data to the previously
full backup rather than overwriting everything...thus saving the life
expectency of the terastation hard drives? I can easily change that since I
have just configured this recently since the current NTBackup's are virtually
useless in restoring individual messages. Oh and BE says that I can purge
transaction logs as each backup appends or overwrites the previous...is this
what needs to happend in reference to what you said about purging the logs?

Also...in reference to above, other than using recovery storage group (which
sounded too complicated before I had these problems) BE says during setup
that I can enable it to allow me to restore individual messages. Is that
true and is it something that is easily done or would it take too much effort
on my part that could in fact screw things up even more?

At this point, we are so close of losing the client that we may not have the
chance to make things right. If you can tell me about the above and give me
some assurance that I am on the right track with the BE backups and being
able to restore messages from those...I would appreciate it.
Lastly...regarding BE backups...if I have the three week rotation setup on
them...would it be easier and less time consuming on both mine and
terastations part to continue with full backups over three weeks or should I
do incremental or differential and would I still be able to easily restore
messages from that if lost?

Thanks for your help and if it comes down to it...I may need your contact
info and pay your consulting fees to get out of this. As of now...I am more
in fear of my job than losing the customer...and any help to that effect
would be well worth it. Please use the email address from previous to send
me your contact info and prices if it comes to that. Thanks.
--
Thanks,

Binarydaddy
IT Consultant
Northwest Ohio


"Lanwench [MVP - Exchange]" wrote:

binarydaddy <binarydaddy@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
LAN,

Well it seems apparent that I did not know what I was doing:( I
guess I can tell you what I have done since installing the new server
and you can tell me if what I did makes sense and if you see that
there is anything else I need to do. Looks like a refresher course
in server installation might be a good thing for me at this point:(

Set up a lab - virtual servers make this stuff easy. The whole point of AD
is that you're not limited to a single server with a local SAM - you can add
domain controllers, retire old ones, etc - you pretty much never need to do
what you did. Migrations and server work also require careful planning, and
research beforehand...don't just charge in, even if you're absolutely sure
of what you're doing.

I hope you don't take this badly, but you've gotten the network into a bit
of a dog's breakfast now, and the client has a right to be annoyed. You
should be able to fix this, but it's going to take some work - you may
consider bringing in someone else with a bit more experience to help out &
speed the process; it will likely pay for itself quickly enough.


Okay...so yes, I basically installed everything on the new server,
verified the settings, policies, AD and components were identical to
the old server.

To the human eye, they may have been. However, the SIDs are entirely
different. What you have now is a brand new domain - with brand new user
accounts, and so forth.

I then backed up data and the email store through
WinBackup

NTBackup?

and shut down the old server. I then restored the data and
email to the new server.

If you were using Exchange, and were able to do this, you were d__d lucky if
you got the stores to mount cleanly (or at all).


Once complete, it seemed the main problem we had was that email wasnt
reconnecting as it should have. The solution I know of and confirmed
on this discussion board was to first, try to disable and reenable
the cached exchange mode (including rebooting before and after to get
a fresh updated ost file). WHen that didnt seem to work, I then
recreated a fresh profile on each machine and that seemed to take
care of that.

No, you will still have problems. Disjoin the workstations from the old
domain (which no longer exists, remember) & put them in a workgroup. Rejoin
the new domain.

You will have orphaned your user profiles - what you may wish to do first
is:

While the computer is still in domain A, create a local user account,
clearly named to distinguish it from the domain user (e.g, LauraLocal as
opposed to Laura).
Log in once as the local user account.
Log out.
Log back in as an account with admin rights (but *not* the real domain user)
Go to control panel, system, advanced....in User Profiles, click the
Settings button
Select the domain user's profile, click on Copy To, and browse to the new
local user's c:\documents and settings\username folder.
Click OK.
Click the Change button in "Permitted to use" and pick Everyone
Close out.
Log in as the local user and make sure the settings look right.

If so, you should be good to go...disjoin the computer from the domain,
making sure you know the local admin credentials....and then join the new
one.

Then, you can reverse the process, so the new domain user has the local
profile copied up to *it*.



The next issue that has been ongoing is that users where not able to
login from time to time to the domain

Not surprising!

at the bootup screen of XP Pro.
After much runaround on here and so forth, this morning I changed all
of their internal PC's to static IP's

Not necessary -

and specified the DNS address
on the server and am about to remote into the server and add the DNS
host records. What confuses me is that the DHCP and DNS services on
the old server had added the host files in DNS through DHCP.

Host files aren't relevant to DNS, so I don't think that's what you mean....

It has
not done that on the new server

How did you set up DNS and DHCP on the new server? You should have
AD-integrated DNS running, and the DHCP server should be dishing out *only*
the internal IP address of the new server for DNS. No public DNS servers.
The primary DNS suffix must be correct & match the AD domain name (e.g.,
company.local). Automatic client DNS registration should be happening
....well, automatically.

which is what prompted me to change
to static IP's and add the host records manually since I am leary of
adding DNS records for DHCP clients when their leases could expire
and thus giving them new IP's that are different from those
associated to their respective computer names on the DNS records.

Don't mess around in your DNS.... at least not yet.

Again...just what I am seeing and trying to determine...If I am wrong
on this, please let me know:(

So as of now, the issues seem to all be worked out

I wouldn't say that, not yet...

and this change to
the DNS and static IP's appears to be what the concensus is

You haven't mentioned what you did with DNS, and you should not need static
IPs.

on MS
Newsgroups as to what the problem is and what needs to be done to fix
it. Again, please inform me if I am wrong and what to do.

See if the above helps.

FInally...a third party app on one of the local machines had
attempted to pull the new profiles I created for Outlook into a PST
file instead of a general mailbox. I have seen this issue once
before and it did the same thing as before by exchange seeing the
problem and stopping the profile setup and deleting the PST
file...reverting back to the original profile when it had failed.
However, this time around, the pst file was deleted automatically
when the error occurred and about 1 weeks worth of email was already
in the pst file when it was deleted (pulled in 1 week to the inbox in
about 2 seconds before failing and deleting).

I don't understand how a PST file could be automatically deleted from the
system - search for it! If the mail was downloaded to it, it wouldn't be a
single PST file for multiple mail profiles. But, if you have mail that was
downloaded to PST, and then the PST file was deleted & can't be recovered,
and you have no backup of the mail store made prior to that, the data is
gone. PST files don't belong on a network w/Exchange.

If this third party app causes problems, uninstall or disable it for now.

Fix your profile problems & many issues should go away. You need to edit
your mail profiles so there are no PST files or Internet mail in them. Just
Exchange.

In reference to the above, the old server was setup by a different
company had not been backing up exchange at all. We spotted the
issue and let WinBackup do exchange backups on the new server. The
problem is that I am not able to restore the individual messages
through the WinBackups because it is prompting me to restore the
entire mailbox from a specific date...which doesnt include mail from
the period after the backup was finished...thus the potential of
losing more email (have I lost you yet??).

Normal NTBackup does not back up invididual mailboxes - it backs up the
whole store. If you have E2003 and up you have the Recovery Storage Group as
an option, but that isn't for the faint of heart. If you support Exchange
you should start doing a little reading up on this stuff, seriously. :-)

So...we found out later that the weeks worth of email was lost and the
backups only went back 1 week and had already been updated. We have
since then recovered local mail from inside users from that date
range...but the backups have since been overwritten

Ouch. This is Not Good. Backup media should be stored offsite.

and the email
from that range from outside sources is no longer avialable. The old
server did not have recovery storage group setup...but they had
Backup Exec 11d that could have been used. They did not have the
media for that until recently and we have set it up to back up and
allow recovery of individual messages through backup exec and
extended their backup schedule to three weeks of full backups.

I don't personally recommend brick/mailbox-level backups - I use BE in some
locations, but I only back up the stores. Brick level sucks up way too much
time/media and is useless for disaster recovery -use it only if you're also
doing full online backups which purge the committed transaction logs.

I just say that to make sure I am covering every detail based on what
we did and the issues we have come across and our solutions to them.
If you see anything in here that catches you as being incorrect or a
different solution recommended...please let me know:) Thanks, LAN,
for your help.

FYI - I know some of this is exchange related...but given the
circumstances, I wanted to cover everything in one thread so you can
see what was done and offer any solutions without referring to other
posts. Also...if in fact you might be able to offer any assistance
off of this discussion board, my email address is bstossel@xxxxxxxxx
if you would allow me to forward you any useful information via
screenshots or otherwise. I cant afford $250+ a pop for some MS
flunky to try and guide me over the phone...I have wasted over $600
through that service and nothing has been fixed. I get better help
from guys like you and you personally have replied to numerous
threads of mine and your input is the best so far...thanks again and
sorry for the lengthiness.

No problem. Hope this helps. Sorry, can't do individual email support unless
you want to pay *my* consulting fees :-)

binarydaddy <binarydaddy@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Danny,

While your input seems logical...this is a single server
environment. The old server was setup improperly about 4 years ago
and it was only a matter of time before the 9GB primary partition
was going to be full after updates and service packs.

Yes, understood, but that isn't really relevant here, I think.

The new server is a replacement to the old server and the old server
was the only server. This is a small environment (only about 15
users total). The old and new server are acting as a DC, File
Server, DNS and DHCP Server...as well as an exchange server.

But exactly *how* did you install the new server? Based on your
description, it isn't clear. This should have been simple - set up
the R2 server in the existing domain as a member server, than do the
schema updates for R2 and promote it to a DC. Then install Exchange,
and mov mailboxes & rehome public folders (never ever run dcpromo on
an Exchange server).

Then you'd install DHCP/WINS, copy your data files (I like robocopy
with the /sec switch), make sure the new server has AD-integrated
DNS working properly, make it a GC.....and transfer the FSMO roles
to the new server. Then followed the official procedures for
removing the first Exchange server from the domain. At that point,
you could've kept the old one up as a secondary DC or shut it
down...everything would be on the new box.

If you didn't do the above, what you've got now is a totally
different AD domain, regardless of what you named it,and in that
case, yes, loads of things aren't going to work right. Your
computers would all need to be disjoined/rejoined to the new domain,
your user profiles migrated (ugh), and all sorts of ugly tweaks
would likely be required.





So unless there is still some validity in your resolution to the the
problem in a single server environemnt...I am not sure that it will
help.

I will say that after much research...I think it is a DNS problem.
The remote users arent having any problems. Only local users...and
I see that if I were to specify the DNS server address but let the
DHCP handle the rest of the requests...everything should work just
fine. Does this sound like a viable solution?

One of the biggest issues yet to be fixed is that some users
cannot connect
at initial login. They get Domain not found or not available.

This is a symptom of DNS not being setup properly.

Only happens with certain
users. Once we setup the new server, mimicing the old one's
settings, we were able to reestablish connections just fine. But
than, several users get
this error and it takes sometimes 5+ attempts before they can
connect to the
domain. All user accounts and settings were recreated with same
settings as
the old server.


My concern is with this step. When you set up the new server was it
connected to the existing domain?

The proper way to set up a new server in an existing AD domain is
to add the server to the domain as a member server, then run
dcpromo to make it a DC. Running dcpromo without the server being
connected to the existing domain will create a new domain. Even if
you gave it the same name as the old, it's still a new domain to
the AD clients because the SID is different. Different SID = new
domain to the clients of the old domain. This "sounds" like what
happened in your case because of this: " All user accounts and
settings were recreated with same settings as
the old server." statement.

Done correctly the user accounts would replicate from the old
.

Quantcast