The installation files have been verified to work on another system that has Office 2007 installed and on another system that does not have it installed. Are there any other reasons this installation will fail like this? Does Office 2007 affect the MBR or any other part of the hard drive to leave a trail of itself? Are there any suggestions?
Processing data from remote server failed with the following error message: Could not find any available Domain Controller in domain , exchange 2010 powershell error
You may get error when loading Powershell on exchaneg 2010 boxes as like below
“Processing data from remote server failed with the following error message: Could not find any available Domain Controller in domain , exchange 2010 powershell error”
Followed by
“Connecting to remote server failed with the following error message : The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol. For more information, see the about_Remote_Troubleshooting Help topic”
Child domain – Child DC + Exchange 2010 (2 servers)
When I am login with root domain credentials to exchange 2010 box, showing the above error, but when I am login with child domain credentials powershell modules loading correctly.
Resolution
I found the issue is because exchange 2010 server configuration it is not set to query root domain DC hence I am not able to make real-time legacy exchange 2003 queries. I have added root domain Global Catalogue server as additional GC server under – EMC console – Server Configuration. After that when I am login with any domain credential it works perfect.
Use the Get-ADserversettings cmd to find preferred domain controllers
To add Additional domain controllers , run below commands
Exchange Server relies on global catalog servers in a domain to perform user lookups in Active Directory. Normally,...
GCs (as they're commonly abbreviated) are detected automatically by Exchange Server when it first starts up, and then about every 10 hours thereafter.
Exchange Server also attempts to redetect GCs and domain controllers (DCs) if a major topology change is detected -- for instance, if all available domain controllers and global catalog servers go offline.
If a GC goes offline, it's flagged as 'down.' Exchange Server will ping it every five minutes to see if it's back online yet. However, if the detection routine is not working correctly due to changes in the network topology, a GC might be flagged as unreachable when it's not, or vice versa. This can lead to, among other things, an Exchange-specific issue involving one of its message queues.
Exchange Server has a number of queues that are used for message processing, one of them being the pre-categorization queue. Messages held in it are addressed to recipients that haven't yet been looked up in Active Directory.
If you have a DC/GC server being queried by Exchange Server that can't be reached, Exchange will expend one of a limited number of threads available to perform lookups. Under high enough loads, the thread count runs out; processing then stalls until a thread times out of its own accord.
In circumstances like this, you may want (at least provisionally) to turn off Exchange's automatic topology-discovery functions and hardcode the names of the GCs to be used. This will keep Exchange Server from pinging and searching for GCs.
If you use this technique, just remember that you will have to manually update the hardcoded information to match if an old GC goes offline and a new one is brought in.
But keep in mind that, if your global catalog servers seem overloaded, it might be something as simple as needing another GC to satisfy the demand. Large Exchange Server sites (thousands of users or more) typically impose very heavy demands on global catalogs.
As a side note, an easy way to find out if the pre-categorization queue is getting stuck is to look at the SMTP ServerCategorizer Queue Length performance counter. If the queue is consistently nonzero, even during periods of low email activity, messages are probably getting stuck in the queue, and a GC issue could be the culprit.
About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter.
Do you have comments on this tip? Let us know.
Related information from SearchExchange.com:
Tip: Topology discovery errors in Exchange Server
Exchange Admin 101: An introduction to DSAccess
15 tips in 15 minutes: Managing recipients and distribution lists
Administration Guide: Exchange Server performance tuning
Reference Center: Exchange Server and Active Directory tips
Please let others know how useful this tip was via the rating scale below. Do you have a useful Exchange Server or Microsoft Outlook tip, timesaver or workaround to share? Submit it to SearchExchange.com. If we publish it, we'll send you a nifty thank-you gift.