[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 715
  • Last Modified:

Changes to the GAL in Exchange 2010 do not update or display in a timely manner

I have an Exchange 2010 server that is a 2003 conversion. When we delete users, add users, etc. the additions ro deletions do not show up in the GAL when a user tries to create a new email. It may appear after several weeks, but never in a timely fashion. We have tried to update the GAL manually using the command line, but receive errors. A screenshot of the errors is attached. The domain is a 2003 AD domain with a trust to another domain.
GAL-Error.jpg
0
djaabrams
Asked:
djaabrams
  • 12
  • 6
  • 6
1 Solution
 
Exchange_GeekCommented:
run the following global address list cmdlet

Get-GlobalAddressList | Update-GlobalAddress list

When you suggest that you aren't able to see the changes, there are two modes to this -

1) Online mode - OL in online mode OR webmail mode. These two modes access the GAL directly.
2) Offline mode - OL in offline mode, this mode would download the changes once in a day (post 5am local server time). Hence, any change you make in the day - OL in offline mode won't see it - at all. Unless you update Offline address list.

Hence, you need to provide feedback - which mode isn't able to see the changes.

Also, if you are making changes on E2k3 domain that *may not* host E210 mailboxes, possibly that domain might not have been prep'red for E2010 using cmdlet setup /preparedomain

Awaiting feedback.

Regards,
Exchange_Geek
0
 
djaabramsAuthor Commented:
Thanks for the quick response. The changes cannot be seen in either mode, but the users are using online mode. I will check the domain in a bit to see if the domain was not prepped correctly, but I followed  very detailed directions when doing the conversion. That of course doesn't mean that everything went correctly. Are there any clues to look for to see if the domain has issues with hosting the mailboxes?
0
 
Exchange_GeekCommented:
When you are working on adding / deleting etc - check on the Exchange Management Console under Recipients, if Exchange is able to query AD and view the change.

If you can see it under EMC, it should be visible using webmail.

You *might* want to change the filter / scope of querying entire forest in EMC

Regards,
Exchange_Geek
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
djaabramsAuthor Commented:
I received from feedback from the users who logged this complaint, and have to change my story. The ONLINE version of the GAL appears to be accurate. Its the offline that is not syncing. The users are all onsite with desktop computers. I believe that they are setup with Outlook 2010 in cached Exchange mode, so they are likely also using an offline version of the GAL. So now I need to start troubleshooting why the GAL is not syncing...
0
 
Exchange_GeekCommented:
Thank you so much for sharing this feedback, this would help us to get the story corrected.

Now, there are couple of quick points that you could work with

1) Increase logging by running cmdlet in powershell Set-EventLogLevel MSExchangeSA\OAL Generator -Level Expert
2) Go to OAB and right-click on it and select Update
3) Go to Event viewer and check for errors or warnings
4) Next, run the following cmdlet to check if Mailbox Database are linked to correct OAB

Get-MailboxDatabase | FT Name,OAB*

5) Restart MSExchangeSA
6) Lastly, run Exchange Best Practice Analyzer tool from EMC - Toolbox.

Regards,
Exchange_Geek
0
 
djaabramsAuthor Commented:
Will work on this further tonight, have to move on to other more pressing issues. Will take all the advice and see what happens after hours today...
0
 
djaabramsAuthor Commented:
Thanks, I will do that. The client started having unrelated domain issues, so I have left them alone to resolve those issues before continuing.
0
 
Exchange_GeekCommented:
LOL, happens to all the admins, - you got to fix something end up fixing something else :)

All the best and and if you face issues following recommendations given, feel free to ask.

Regards,
Exchange_Geek
0
 
djaabramsAuthor Commented:
I will do that. I'm starting to think that the OAB web sync is setup to use https but not sure that it is using a cert with the required domain name included. I'm going to follow the article and turn off ssl for the oab sync and see what happens. Thanks to all for their suggestions.
0
 
Exchange_GeekCommented:
That is fine, you'll need to have the correct OAB URL, which the client would collect from the OAB Virtual directory.

I'll be concerned to check if the server is actually generating the OAB correctly - that is precisely what I've written in my recommendation.

Regards,
Exchange_Geek
0
 
djaabramsAuthor Commented:
Will be checking that too..will follow you instructions above.
0
 
djaabramsAuthor Commented:
Well, I have been through all of the procedures from both suggestions. The Directories for both OAB locations have been recreated, but are empty. I have run the update both from the EMS shell and the EMC-Org-Distribution-OAB. No errors in the event viewer. Will wait till morning to see if the OAB is reproduced. If I have missed something, I'm all ears.
0
 
Exchange_GeekCommented:
All the best

Regards,
Exchange_Geek
0
 
MegaNuk3Commented:
Either wait 8 hours or restart MSExchangeFDS service on CAS as per my article, then CAS should copy OAB from mbx server
0
 
djaabramsAuthor Commented:
Still no files after waiting overnight and restarting the MSExchangeFD service. Should I repeat the process tonight, or is there something else to look for? BTW, this is a single server Exchange org, however the Exchange 2003 server is still running but not really doing anything...or is it?

I also tried to run this command from Exchange_Geek's recommendation to increase the logging level:

1) Increase logging by running cmdlet in powershell Set-EventLogLevel MSExchangeSA\OAL Generator -Level Expert

It gives me an error. Is the syntax a character off by chance. Exchange Shell is not my expertise yet.
0
 
djaabramsAuthor Commented:
Error from above logging cmdlet:

[PS] C:\Windows\system32>Set-EventLogLevel MSExchangeSA\OAL Generator -Level Expert
A positional parameter cannot be found that accepts argument 'Generator'.
    + CategoryInfo          : InvalidArgument: (:) [Set-EventLogLevel], ParameterBindingException
    + FullyQualifiedErrorId : PositionalParameterNotFound,Set-EventLogLevel
0
 
MegaNuk3Commented:
OALGenerator is one word
0
 
MegaNuk3Commented:
No it isn't, try this:
Set-EventLogLevel "<Server>\msExchangeSA\OAL Generator" -Level Medium
0
 
MegaNuk3Commented:
Note the quotes in the above.
0
 
djaabramsAuthor Commented:
Sorry for the delay guys, still am not getting updates of the offline address list
0
 
MegaNuk3Commented:
Did you increase the event log level?
0
 
djaabramsAuthor Commented:
Client decided to not use OAB as a workaround to this issue. Needed to put resources toward other issues and projects
0
 
djaabramsAuthor Commented:
Client did not wish to put any more effort into solving this issue. Removed Exchange caching from clients and are now using online GAL
0

Featured Post

Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

  • 12
  • 6
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now