| EXCHANGE RANGER

"There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)".

By Gulab Prasad | Sunday, December 30, 2012 | Exchange 2010 1 Comment

My last article of year 2012.
I was installing exchange server 2010 SP2 and ran into this error/issue. The server is updated with windows update and prerequisite is installed.

While Hub Transport installation was going on, it failed with the below error message.

Hub Transport Role
Failed

Error:
The following error was generated when "$error.Clear();
          if (!(get-service MSExchangeADTopology* | where {$_.name -eq "MSExchangeADTopology"}))
          {
            install-ADTopologyService
          }
        " was run: "There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)".

There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
Click here for help... http://technet.microsoft.com/en-US/library/ms.exch.err.default(EXCHG.141).aspx?v=14.2.247.1&e=ms.exch.err.Ex88D115&l=0&cl=cp

Elapsed Time: 00:00:18

Client Access Role
Cancelled

Finalizing Setup
Cancelled

I checked the windows firewall service and found that it was disabled. Set the service to Automatic and started the service. Started the installation again it completed successfully. As exchange server 2010 is getting installed on Windows Server 2008R2, you make sure that Windows Firewall is not disabled. You should never disable the Windows Firewall on Windows Server 2008R2.

I thought of writing it as my last article of year 2012. I will begin New Year 2013 with Exchange Server 2013 and Unified Communication technologies and try to write as many as helpful, knowledgeable articles I can.

Happy and Prosperous New Year To All of You.

Cheers,

Error: An error occurred while trying to validate the specified database copy for possible activation. Error: Database copy 'DB01' has been blocked from activation on server 'SERVER.DOMAIN.com' by an administrative action.

By Gulab Prasad | Sunday, December 23, 2012 | Exchange 2010 2 Comments

I came across with this "weird" issue while upgrading DAG from exchange server 2010 SP1 to SP2. The environment had Windows NLB with 2 servers.
Here is how DAG looks like...

As per the procedure, I upgraded the Network Load Balancer first and then Mailbox Servers. Network Load Balancer upgrade went fine without any issues. Installed Update RollUp 4 as well after upgrading it to SP2. Started upgrading Member server of DAG, you can refer to this Tech Net article to upgrade DAG member servers.

Both the member server MBX02 and MCSHT got upgraded as expected, while upgrading the MBX01 it failed on stopping Microsoft Exchange RPC Client Access Service twice.
Restarted the server and upgrade completed successfully. Installed Update Rollup 4 as well on all the servers. After upgrade now it's time to move the everything back as it was before upgrade. So ran the below command:
Move-ActiveMailboxDatabase "DB01" -ActivateOnServer MBX01 and it failed with below error.

Checked the status of the server by running the command:
Get-MailboxServer MBX01 | fl Name,DatabaseCopyAutoActivationPolicy and it says Unrestricted, hence it's not blocked. Ran the command again and it failed with the same error message. Tried from GUI and as expected, it had to failed.
Friend of mine with whom I was working with, suggested that we should try to Suspend the copy of database residing on MBX01 and resume the DatabaseCopy than try to move.

ActiveMailboxDatabase from GUI

Surprisingly it worked like a charm. It's a BUG and I checked in Update RollUp5 v2 and it hasn't got fixed yet.

Cheers,

Scheduling Assistant in OWA is not showing the GAL in Exchange Server 2013 RTM

By Gulab Prasad | Thursday, November 22, 2012 | Exchange Server 2013 Leave a comment

Scheduling Assistant is not showing the Global Address List (GAL) information when scheduling meeting using OWA (Outlook Web App) in exchange server 2013 RTM version, not like the way it use to work in exchange server 2010. In exchange server 2010 when you click on Scheduling Assistant in OWA it gives the entire Global Address List (GAL) to choose the user from it.

This is how it looks in OWA when you click on Scheduling Assistance in exchange server 2010.

Now I am creating new event using OWA and the mailbox is on exchange server 2013 RTM.

Click on new event

Now when I click on Scheduling Assistant I should see all the mail enabled object in the GAL, in other words, entire GAL. But unfortunately I don't see it, I just see my self and nothing else.

If I want to add the Attendees into the event (Meeting) I will have to do it manually by typing there name in Add Attendees box. Which is weird, as it works fine in exchange 2010 and I get to see the entire Global Address List (GAL).

I don't know why it's behaving like this, which it shouldn't be, or am I missing something!. I will check the same thing in Outlook and will update the article. I am still looking into the issue with OWA and will update the article in few days if I come across with anything.

Till then...

Cheers,

Exchange Server 2013 CAS arrays

By Gulab | Thursday, October 25, 2012 | Exchange Server 2013 18 Comments

Exchange 2013 doesn't need to use CAS arrays any more, finally all those worries of tons of name space is gone away now. Now we can use just One* Name Space, Global Name Space. Look for "Deployment simplicity" section for more details on Global Name Space.

Client Access Server 2013 is a much simpler beast all round, which should make it easier to manage one of the truisms much beloved by those who pontificate about designing for Exchange is the necessity to follow “best practice.” There’s absolutely nothing wrong with this approach as best practice is defined to be a method or technique that has consistently shown better results than other methods. In other words, it’s an approach that works well, probably because others have tried different methods and failed.

But the important thing is not to become clogged in best practice and to understand that best practice evolves constantly in line with human experience and developments in the underlying technology.

Take CAS arrays for instance. Introduced with Exchange 2010, CAS arrays provided a method to group a set of CAS servers together in such a way that they could be addressed as a single entity (and had a single IP address and FQDN). Individual servers could join and leave the array over time and the array would keep functioning as long as a single server was active. All-in-all, it was a nice concept, even if a CAS array didn’t perform any load-balancing of incoming client connections. In this respect, you can ignore the statement in TechNet’s documentation of the New-ClientAccessArray cmdlet that says it creates “a load-balanced array of client access servers within a single Active Directory site.” That’s not true, but the vendors of load balancers were all too happy to fill that gap.

Best practice duly had to be formulated and it was proclaimed that you should always create a CAS array within a site and assign the CAS array object to the RpcClientAccessServer property of mailbox databases. The value of RpcClientAccessServer is given by the AutoDiscover process to Outlook clients to populate their profiles when created and provides a MAPI endpoint for connectivity within the site (remember, a CAS server or an array is limited to a site). CAS arrays do nothing for non-MAPI clients such as Outlook Web App (OWA) or Exchange Web Services (EWS).

Once provided with the FQDN of the CAS array, Outlook clients would attempt to connect to the CAS array rather than to an individual CAS when they attempted to open a mailbox, which solved the problem of providing continual access to the mailbox when an individual CAS was taken offline for some reason, such as applying a roll-up update. This alone is an excellent reason for the suggested best practice to be valid and worth respecting.

Roll forward to today and the advent of Exchange 2013. You now observe that the CAS is a tad different. The Exchange 2013 version of the CAS is a much simpler beast as it is purely an authentication (are you authorized to connect to Exchange?) and proxy/redirect (where do you need to go to find your mailbox?) server. No processing is performed of mailbox data by the CAS; all it does is to send on client requests to connect to the mailbox server that hosts the currently active copy of their mailboxes via HTTPS (no MAPI RPCs).

The RPC Client Access namespace, which was introduced in Exchange 2010 to handle the concept of RpcClientAccessServer described above is no more and Exchange no longer uses FQDNs of CAS servers or arrays to locate user mailboxes. Instead, CAS uses the unique GUID assigned to the mailbox. When an incoming client connection must be processed, CAS looks up Active Directory to find details of the mailbox via its GUID (including the database that hosts the mailbox) and Active Manager will tell CAS what mailbox server currently hosts the active copy of the database. Voila!

In passing, I note that the mailbox GUID can be shown to humans from time to time by Outlook when it configures a new profile. I hope that Microsoft finds some method to translate the GUID to something more user-friendly before Exchange 2013 finally ships as otherwise I think this will cause some extra support calls for help desks. Computers are good at translating GUIDs, humans are not.

There are many reasons why Microsoft has taken this route for Exchange 2013, but perhaps the most basic is to uncouple the functionality of CAS from mailbox servers so that both can function independently of each other in terms of geographic location (a CAS in one datacenter can service requests going to a mailbox server in another) and software versions (you won’t have to update CAS and mailbox servers with the same software in future). Overall, CAS 2013 is much, much simpler (another example is how the load balancing focus shifts from layer 7 to layer 4) and CAS 2013 is much more of a lightweight service than before, one that can be removed from service without causing much disruption to the overall infrastructure or client connections.

As for the RpcClientAccesServer property, and our best practice of deploying CAS arrays for Exchange 2010 – well, they’re pretty much dead and buried by the developments in Exchange 2013. The property still exists in Exchange 2013 but it’s an artefact of the past about which we no longer need to concern ourselves, once the migration to Exchange 2013 is complete.

Cheers,

Upgrade the discovery mailboxes to R5 version, this will fix the RecipientDisplayType property of the discovery mailbox which was wrong in R4.

By Gulab | Saturday, October 6, 2012 | Exchange 2010 6 Comments

Hi All, It's been longtime I wrote any new article, being busy in some other stuffs.

I was doing installation of second Exchange Server 2010 Mailbox Role for my DAG (LAB) today and got this error. This error reminded me my Microsoft Exchange PSS days.

I have seen this error before when exchange server 2010 was RTM.

I thought of writing a small article for this issue. To resolve this issue, first I uninstalled Mailbox Server Role and restarted the server. Ran Setup.com /preparead and tried the installation but it failed again.

Their is one attribute in exchange for all the mailboxes, its homeMDB. I checked the attribute on the user account by going into Adsiedit.msc...Domain Partition...User...Gulab Prasad (my account) and found that it is set on the account.

Now there are two System Mailboxes from which this information is missing. Here is the attribute with homeMDB not set.

Now here is what I did to fix the issue. Go to Adsiedit.msc and Domain Partition and copy the attribute value from any user mailbox and paste it in homeMDB attribute.