Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

New user doesn't get an e-mail address for some reason. 3

Status
Not open for further replies.

esmithbda

IS-IT--Management
Jun 10, 2003
304
US
We have a new user in our office as of today (a temp). In Active Directory on the Exchange 2003 machine, I copied our most recent temp's user and created our new user from that. I then deleted the previous temp.
I setup the new user with her info and then went to log her into her machine - Outlook loaded up and then said that it couldn't find her username on the server (no mailbox).

I doublechcked that I had spelled/typed it correctly and it was. I even went in, killed her mailbox via Active Directory -> Exchange Tasks and created a new one. Still no luck.

I looked in her Active Directory profile and saw that under e-mail addresses, she had nothing. Previously, when creating users, it would automatically create the e-mail info when we setup the user and their mailbox...

I have tried searching and have phoned our other IT guy and both of us are stumped on this.

Any ideas?
 
Here are some things I looked at - it is so frustrating that on these issues everyone is like "oh hey, all you have to do it this and bam, it works!" and then you do it and... nope, doesn't work. And then there is no help for that.

Here are the KB articles I looked at, and how they relate to mine:
Q297124
This looks a lot like our problem, but going through the steps, all of our stuff is checked the way they say, so no go.
Tested after checking this - still doesn't work.

Q319065
I thought this might help. I went into see if the servers weren't working right for this. The enterprise setup let me point at our mailserver and pdc, but then the domain one wouldn't let me point to the pdc - but I could point to the bdc - so I did.
Tried it all again - still didn't work. Then it let me change it back to the pdc (which it had been originally set to), so perhaps the domain one just can't be changed to what it currently already is?
In the end, this didn't help either.

Q286356
This doesn't appear to apply to us. We don't get any error messages logged on the mailserver or the PDC/BDC regarding this.

Q287137
We don't have anything hidden - but just in case I went through and made sure that any special permissions on what they talk about were set to Allow for Modify Permissions.
After testing, this didn't change anything for us.

I checked this ( but there was nothing new mentioned in there that helped.

Both Q837444 and this ( which are essentially the same thing since the latter links to the former, refer to installing SP1.
I am hoping at this point it will resolve our issue since there doesn't really seem to be much else out there that I haven't tried yet.
Although that isn't exactly the same problem we are having (it talks about errors logged in the event viewer and we aren't seeing any anywhere).

It is almost as if the service just isn't running anywhere - which would point to perhaps the loss of the DLLs (like what xmsre) said up there. Apparently that is usually due to fax software, and we don't have any of that installed.
That said, the IT consultant did add Norton's anti-virus onto the machine and didn't exclude any directories and I am wondering if that screwed something up while it was running that way.

I am going to investigate the dll issue - but I suspect that the SP1 will possibly resolve that, if nothing more than indirectly, due to replacing those with newer/improved dlls anyway.

I thought maybe after all of those changes or attempts, something might have clicked. I also wondered if the fact that copying users would create some different issue (which is usually how I deal with new users).
So I created a new "testuser" account and... same problem.

Many of the "solutions" say to either login to the account via the client machine and Outlook, or to send them an e-mail.
I have tried this repeatedly, and it doesn't work for us. Using Outlook on the machine just says that the user doesn't exist.
Sending them an e-mail, they don't show up in the GAL, and if you do it straight up through SMTP, it gets sent back saying that such a user doesn't exist.

At this point I am going to look into the DLL issue for a bit, and if that doesn't resolve it - then the service pack.
I really don't want to do this prior to the weekend, but I have a trickle down anger situation where a new employee is getting angry at me for not having an e-mail for her, because higher ups are angry at her for not being able to e-mail out to resolve certain issues.

Fantastic.
 
You're problem is identical to mine, especially where you said:

"Many of the "solutions" say to either login to the account via the client machine and Outlook, or to send them an e-mail.
I have tried this repeatedly, and it doesn't work for us. Using Outlook on the machine just says that the user doesn't exist.
Sending them an e-mail, they don't show up in the GAL, and if you do it straight up through SMTP, it gets sent back saying that such a user doesn't exist."

Thankfully I don't have anyone on my case just yet and my director (who is quite technially savy) agrees that we should hold fire until a weekend. I'm still gonna need to bite the bullet and install this SP1 though.

Happy Days, eh!
 
We have two DCs, the PDC and the BDC. The PDC has recently been rebuilt from 2k up to 2k3. The BDC is still on 2k sp3 (I have seen reports that there are some issues if the DC is not at least sp3, but we have that covered).

I enabled MSExchangeAL logging to the highest level and all I ever see are 8012 and 8011s. 8012 seems to indicate that it either can't find anything, or doesn't see anything new to update (depending on how you want to interpret it).

Doing searches on that turned a series of newsgroup posts which then led me to run some diagnostics on the DCs. On the 2k3 box, it is failing on FRS tests. On the 2k box it won't even run the diagnostic (apparently doesn't have the support tools installed yet).
While that is not bad, I'm not really sure how much that would break RUS (not saying that it wouldn't, just saying that I don't know off the top of my head if they are related).

Then saw a post recommending this ( and I have long since lost track if I had seen that before - but I think it is new to me.
One of the issues that it recommends is that you check DNS issues.

Just yesterday we ran into a problem where we saw that the IT consultant that rebuilt our PDC up to 2k3 put in the wrong gateway for the two DCs during the process.
This caused the DNS records to eventually just bail and it caused a network issue until we finally traced that down.

So now I am going to follow that path.
Doing an nslookup on our PDC resolves a single IP.
Doing an nslookup on our BDC resolves to two IPs!
Looking into that, it is because we have two modem connections into our office off of the BDC and when they come in, they are given an IP and it attaches to that machine.
Whether or not that breaks this? I have no clue.

I am just stepping down through every possible avenue to see if I can fix this thing without SP1 and then putting that on over the weekend instead of during a workday.
 
The FRS issue was resolved, doesn't seem to be related. (they were older event log issues that I wasn't sure if they overlapped/correlated to this issue).

I put in a hosts entry for each DC and their IP on the mailserver.

We have all of the DLLs that are listed as issues with this problem - even though when they are listed it is with a slightly different issue that we have, but at least it is an RUS issue.

Looking back at this ( again, number 3 at the very bottom says to check "msExchPoliciesIncluded" - after checking with LDP.exe on the users that are new, this doesn't exist - but it is there on previously created users (that aren't having problems).

No idea what that means for us, but it is more data for the next person that searches for this sort of thing so that they don't have to also do all of the stupid searching that I am currently trying to do.
 
As an update... I set the user up with another account for now (a pre-existing one, which is a silly thing to have to do) until I can come in over the weekend and really get on this thing.

Another thing that has happened out of nowhere is that our OWA went from needing "DomainName\UserName" when you logged in (even though the domain is filled out in the Exchange node for webmail), and then it stopped requiring that for at least a month, and then... now again requires it as of today. (to be fair it might have started some other time prior to today, but on this last Saturday it definitely did not require it)

Great stuff.

I ran "dcdiag /e /v /c /f:c:\dcdiag.log" on the PDC (and running it that way finds all of the DCs and then writes it out to the logfile).

There are a few issues that show up in there, so I am trying to resolve those to see if those are the reason we are having this problem.

I tried pointing the RUS to other DCs and I also separately I tried creating an entirely new RUS - neither of those worked to solve my issue.

This machine runs OWA, but it is not a front end. I know that were this a front end, it would not run the RUS services.
I am wondering if there is some way that it thinks it is a front end, even though that box isn't checked in the settings for the server.

I have also read that I should try running the Exchange setup /forestprep and then setup /domainprep again to force through the correct permissions and such.
In the same places that I read to do that, I read a lot of comments saying that it rarely helps.
I am still going to try it this weekend.

I have also seen mention that just rebooting the server fixes this issue - again, I will try that this weekend. (seems a bit retarded to have to do that every time I want to add users)
 
rerunning domain prep will reset some permissions. Did you try running policytest to see if you even need to?

 
Hi guys,

I had this problem today... I run RUS and it put an error in the Application Log.

I rebooted the server and run RUS again and everything now works!!



Kind Regards, Paul Benn

**** Never Giveup, keep trying, the answer is out there!!! ****
 
Sure enough, I rebooted the server and checked the user - no emails in her AD panel on the Exchange 2k3 server.

So I opened up the System Manager and went to the RUS.

I should have just hit rebuild and then update now just to see what would happen - but instead I changed it from pointing over to the BDC to the PDC (I had tried this several times prior to the reboot with no positive effect) and then I chose "rebuild" and then after watching the task manager and being satisfied that it wasn't really doing anything - I did "update now" (we have a very small AD tree - about 20 users beyond all built in objects).

I looked in the AD panel for e-mails and sure enough, fully populated.

I was all ready to try any number of things and all it needed was a frickin reboot.

Oh well - at least it went fast over the weekend and now I can use the time here that I had allotted to fix this towards other things.

(I am going to hold off on SP1 for a little while longer - I am always hesitant with those things)
 
Just out of curiosity, are both domain controllers GCs? If all of your domain controllers are not global catalogs, then you can have issues with the placement of the Infrastructure Master FSMO role holder. The infrastructure master should not be on a GC unless all DCs in the forest are GCs.

 
It appears that the PDC is the GC.
I didn't set this up, so I am not particularly familiar with it though.
 
Exchange 2003 SP1 fixed this issue for us.

Prior to installing the SP, Recipient policies (email addresses) were not applied correctly or even at all to new user accounts. No amount of AD/RUS troubleshooting could fix the problem.

Check your (app) event log for error 8331.

For more info see


--David
 
i had the same problem in my test lab with 1 DC, 2 XCH boxes (one front end, one back end) and a live communication box.

when i created a new user account i could not log into the mailbox. after creating a user account i noticed that email properties are empty. so i waited a few minutes for the account settings to populate. when i checked the email address tab in dsa it was still empty. stupid microsnot!

i already had XCH SP1 on both servers and the latest patches on the OS. no errors were being generated in the event logs, everything was clean.

applying the recipient policy did nothing, rebuilding and updating the recipient update service did nothing...yes i tried rebooting<g>.

the only thing i found to resolve my issue was to create a new recipient update service (RUS). now immediately after i create a new user the exchange information is populated and i can access the users mailbox.

i don't know if the default enterprise RUS config is forked or what. if i can get anything further on this i'll post but like i said its my lab config so i may get bored with this problem and play with something else now that everything else _seems_ to be ok.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top