Log in


Categories » ‘Microsoft Related’

BES losing connectivity to Exchange 2010 Databases in a DAG

Categories: BlackBerry Enterprise Server Exchange Server Microsoft Related
February 15th, 2012 by

A colleague of mine brought this to my attention yesterday.   It seems that there is an issue where BES will lose its connection to the Exchange Servers in the event where a database should failover to another node in the DAG.

The Exchange setup involves two Hub/CAS and two Mailbox Servers in a DAG.  What would occur is if a database would move to another node in the DAG the BES would simply error out trying to connect to the mailbox.  I don’t have the event ID which totally sucks because it would be helpful but the error on the Windows Server was saying that the BESAdmin account did not have permissions to access the users mailbox.

This is what my colleague got from RIM: “The issue according to RIM is that “sometimes” after any number of DBs fail over to another DAG member, the BES admin account will lose the ability to open ANY mailboxes regardless of which database they are on.  It will behave as if you never set BESadmin permissions in exchange.  If you go through and try to set the permissions again, Exchange will tell you that they are already set.”

I did ask for a log from the BES and this is what it showed in the error log for BES:

(0x8004011d) failed, MailboxDN=/o=ScottFeltmann Corporation/ou=Feltmann/cn=Recipients/cn=scottfeltmann, ServerDN=/o=ScouttFeltmann Corporation/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=CAS.scottfeltmann.com/cn=Microsoft Private MDB 20120213/WC_MAGT_03_20120213_0002.txt:[20400] (02/13 17:52:57.959):{0x189C} {scott@scottfeltmann.com} MAPIMailbox::MAPIMailbox

It will be repeated for every single BES enabled user, over and over again to the point where the EventID Logs will get over ridden, hence the reason I don’t have a log since it happened on Monday and a bunch of other stuff went on as well.

The fix?  Well, restart the BES controller service.  Restarting the whole BES apparently will not fix it.  My Colleague was dealing with Level 1 support for a few hours at RIM, once the issue was escalated the other Tech knew exactly what to do so apparently this is an issue with RIM.

Recommendation?  Move to ActiveSync!

Comments?  Questions?  Please Share!

Tags:
2 Comments »

PST Capture Tool Released!

Categories: Exchange Server Microsoft Related
February 3rd, 2012 by

Over at the Exchange team blog they have released a new tool for performing discovery and importing PSTs into Exchange!  Why is this important?  Well, say for example you have a lot of users in your organization who have PSTs.  There is a problem with this scenario, you cannot manage the PSTs.  You cannot perform any discovery on users PSTs.  You also cannot archive or keep the emails in the PST in a centralized area and under your corporate control.

The PST Capture tool allows you to deploy the PST Capture application on a centralized server or workstation, file PSTCapture.msi.  Once you have your central server setup you will then deploy the PSTCaptureAgent.msi (there is also one for x86 systems) on the computers throughout your organization.  This allows the agent to report back to the server and alert of any PSTs.

How it works:

The display screen here gives you two options, the first is Find a PST and import PST files.  You obviously will want to find the PST files first:

The tool will ask what to search by presenting you with your AD tree.  You will want to select the OUs of the computers you want to search:

Next you will want to select the location of where to search.  For this demonstration I just selected “All” and let the tool go do its thing.

Next it asked me if I wanted to setup a schedule, for this I said No.  But if you have a large environment you may want to consider setting up a schedule to collect the PSTs.  Anyway, once I came back to my screen I hit Scan Now and off it went looking for PSTs.  Keep in mind this is a lab so I’m not going to find too much data but it find the PSTAgents and reported back:

Once completed I selected the files and I did an import now.

I should also point out that you can assign the PSTs to different mailboxes.  This comes in handy if the PST file is not directed to the correct mailbox.

So in the above example I switched the test.pst to my test account “Roy”

What a great tool.  I actually have a few clients that are looking for ways to bring PSTs back into their Exchange Organization.  Before this tool there was no real easy free way of doing it.  Thank you Microsoft for giving the community such a great tool!

To get the download you can go to the Microsoft Exchange PST Capture download site.

Tags:
No Comments »

Exchange 2010 SP2 has been released!

Categories: Exchange Server Microsoft Related
December 5th, 2011 by

The MS Exchange team has released Exchange 2010 SP2!  Yay!

Some of the new features in Exchange 2010 SP2 that I’m looking forward to are:

  • GAL Segmentation!  GAL Segmentation will allow an exchange admin to have multiple GAL that are filtered to users based on a new feature called Address Book Policy (ABP). The ABP allows an administrator to assign to a user which address books, GALs, rooms, and users they can see. I say users because if a person looks at an distribution list that contains users from different GALs and the user doesn’t have permission to see that GAL the ABP will filter out those users.  (more info on GAL Segmentation from The Exchange Team: http://blogs.technet.com/b/exchange/archive/2011/01/27/3411882.aspx )
  • Silent Redirection!  As it stands now when a user hits OWA and logs in to their mailbox, if that user resides in another Internet facing AD Site they will be presented with a link to click to get to their OWA URL. Once they click that link the user will need to enter their username and password again. With Silent Redirection in Exchange 2010 SP2 this will no linger be the case! Users will now automatically be logged in to the redirected site. This gives the users a single sign on experience!
  • Hybrid Configuration Wizard, which will allow organizations to deploy a hybrid deployment where some mailboxes will be on-premises while others can be on Microsoft Office 365.

For some other features of Exchange 2010 SP2 check out my old Blog Article, Exchange 2010 SP2

Looking to download Exchange 2010 SP2?  You can find it here:  http://www.microsoft.com/download/en/details.aspx?id=28190

For a list of the features in Exchange 2010 SP2 you can go here: http://technet.microsoft.com/en-us/library/hh529924.aspx

Enjoy!

Questions, Comments?  Please Share


Tags:
No Comments »

Exchange 2010 Servers lose connectivity with Global Catalog Servers in Domain. Event IDs logged 2102, 2103, and 2114.

Categories: Exchange Server Microsoft Related
November 9th, 2011 by

Ok, I’m sorry, I’ve been extremely busy with work and family.  The following article is one I’ve been working on since September of this year!  So here it is….

Over the past nine months I have been battling an issue in Exchange 2010 that reported “All Global Catalog Servers in forest DC=ScottFeltmann,DC=com are not responding.  I feel that I can finally say the issue has been resolved!

Some background:

This was a large Exchange deployment, two active directory sites, two Hub/CAS and two mailbox Servers in the primary site running DAG.  Secondary site had two Hub/CAS and one Mailbox Server.  The focus of the issue seemed to take place in the primary site.    The issue we were seeing initially is that users would hang, literally hang, both in Outlook or OWA.  It seemed that the Client Access Server (one of the two) was hanging, as if waiting for a response.  Rebooting the server always cleared up the issue but this was by no means a solution.

Now, what made this problem difficult is that it occurred randomly and about every three to four weeks.  There was no way I could recreate the problem and could only trouble shoot the issue when the problem was occurring.  After my initial troubleshooting and seeing the issue occur randomly.  The primary Errors in the Event Log were Event ID: 2102, Event ID: 2103, and Event ID: 2114.

Event 2102 Info:

Log Name:      Application
Source:        MSExchange ADAccess
Date:          3/2/2011 6:03:04 AM
Event ID:      2102
Task Category: Topology
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      CAS1.scottfeltmann.com
Description:
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1364). All Domain Controller Servers in use are not responding:
DCAuth1.scottfeltmann.com
DCMAIN3.scottfeltmann.com
DCMain3008.scottfeltmann.com
DCMain2.scottfeltmann.com
DCSC1.scottfeltmann.com
DCSC2.scottfeltmann.com
DCMain1.scottfeltmann.com

Event 2103 Info:

Log Name:      Application
Source:        MSExchange ADAccess
Date:          3/11/2011 10:46:21 AM
Event ID:      2103
Task Category: Topology
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      CAS1.scottfeltmann.com
Description:
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1524). All Global Catalog Servers in forest DC=ScottFeltmann,DC=com are not responding:

DCSC1.scottfeltmann.com
DCSC2.scottfeltmann.com
DCMain1.scottfeltmann.com
DCMain2.scottfeltmann.com
DCAuth1.scottfeltmann.com
DCMAIN3.scottfeltmann.com
DCMain3008.scottfeltmann.com

Event 2114 Info:

Error:
Log Name:      Application
Source:        MSExchange ADAccess
Date:          4/14/2011 10:48:30 AM
Event ID:      2114
Task Category: Topology
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      CAS2.scottfeltmann.com

Description:

Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1480). Topology discovery failed, error 0×80040952 (LDAP_LOCAL_ERROR (Client-side internal error or bad LDAP message)). Look up the Lightweight Directory Access Protocol (LDAP) error code specified in the event description. To do this, use Microsoft Knowledge Base article 218185, “Microsoft LDAP Error Codes.” Use the information in that article to learn more about the cause and resolution to this error. Use the Ping or PathPing command-line tools to test network connectivity to local domain controllers.


I decided to call Microsoft support as I had never seen this type of behavior in any of my deployments.  To be honest it came down to about 5 calls into MS Support, rare case which happens once every few weeks = difficult to trouble shoot, even with Microsoft.  I spoke to both Exchange support and Active Directory support engineers.  I could go into great detail about the trouble shooting steps I took with MS support but none of these resolved the issue so what’s the point.  To give you an idea we tried to reset the Kerbos ticket, we ran DCDiag, checked Domain controller Replication, checked DNS, nothing.  Long story short after four or five calls with MS Support I finally was able to get escalated to level 3 or 4, either way, Rick (the MS Support Engineer) figured out what the issue was.

What Rick noticed was a Warning in the System Event Log, Event ID 40961 from the source LsaSrv.  This Error was never reviewed with other MS Support people as I’m not sure they thought it wasn’t a bad issue or not.  To be honest, a warning isn’t something I really turn my attention to when a bad situation is occurring (learned my lesson there).  Anyway, here is the event info

Event ID 40961 Info:

Log Name:      System
Source:        LsaSrv
Date:          4/14/2011 10:53:30 AM
Event ID:      40961
Task Category: None
Level:         Warning
Keywords:
User:          SYSTEM
Computer:      CAS2.scottfeltmann.com
Description:

The Security System could not establish a secured connection with the server ldap/ DCMain3008.scottfeltmann.com/scottfeltmann.com@SCOTTFELTMANN.COM. No authentication protocol was available.


Rick mentioned he sees this error when systems are having issues with Remote Desktop.  I couldn’t help to think but how does RDP tie into my problem with Exchange.  The way it ties in is because the secure channel between the source and the target is lost and causes the systems not to be able to authenticate.  Basically the CAS was trying to communicate with the DC while the user was waiting.  The DC and CAS didn’t trust each other and bam, CAS HUNG!

What is the fix?  After about 9 months of issues and calls with MS at random times, there is a hotfix, drum roll….. KB939820!  Which is located here:  http://support.microsoft.com/kb/939820

Once this hotfix was applied the problem stopped occurring, the Event Logs no longer showed a 2102, 2103, or 2114 error and life was good again!

While researching the issue I also found a posting on spiceworks where users were having the same problem.  Here is the URL for that: http://community.spiceworks.com/topic/134941-exchange-2010-ad-topology-failures-all-domain-controllers-unavailable?page=4#entry-847654

Talk about Crazy!   I’m just glad it is over.

Hope this helps out there!

Comments? Questions?  Please Share!

 

 

 

 

Tags:
9 Comments »

Some Voicemail systems may not route SMTP mail to Exchange 2007/2010

Categories: Exchange Server Microsoft Related
September 13th, 2011 by

I recently had a client upgrade to Exchange 2010 for their mail system. As part of this process all applications servers, including voicemail, were configured to route to the Exchange 2010 environment.

The majority of their applications worked however the voice mail system would not work. The voice mail system was using SMTP delivery to send voice mails into the Exchange Organization. The voice mail system was configured to route to the Hub Transport server and the Hub Transport Server was configured to accept connections from the Voice mail systems IP address on a dedicated receive connector.

When looking at the Exchange logs the following information popped out:

,2011,08,01,HubSrv\VoiceMail,TargetIP,SourceIP>,501 5.1.7 Invalid address

Turning to Google I typed in the error,” 501 5.1.7 Invalid address” and came across a KB944302. Here I read that the cause states:

This problem occurs because by default the receive connector in Exchange Server 2007 does not have its default domain value set. This is unlike the behavior in Exchange 2000 or 2003 where it automatically appended the default domain to values that are submitted to MAIL FROM: or RCPT TO: in the message envelope by a sending server if no domain name is provided.

In Exchange Server 2007, the default domain value on the receive connector is not set by default. If no domain name is specified in the MAIL FROM: or RCPT TO: commands, Exchange Server 2007 rejects the message with “501 5.1.7 Invalid Address” response.

This also applies to Exchange 2010. The voice mail system was not able to send mail to the receive connector because the default domain field was blank. I was able to verify that the field was blank by doing a “Get-ReceiveConnector “HubSrv\VoiceMail” | FL Name,Default*” which returned:

Name: VoiceMail
DefaultDomain:

Seeing that my defaultDomain was blank I then ran the following command to set the field:
Set-ReceiveConnector “HubSrv\VoiceMail” –DefaultDomain “scottfeltmann.com”

Scottfeltmann.com is what I used in this example but this should be your SMTP domain name.

When I ran the Get-ReceiveConnector command again my configuration looked like this:

Name: VoiceMail
DefaultDomain: scottfeltmann.com

Once this configuration was completed the voice mail system was able to route voicemails into the Exchange 2010 environment!

Questions? Comments? Please Share.

Tags:
No Comments »

New Exchange 2010 SP1 Help File – Sept Release

Categories: Exchange Server Microsoft Related
September 13th, 2011 by

Microsoft released a new Exchange 2010 SP1 Help File in CHM Format.  If you would like to download it go to Exchange Server 2010 SP1 Help at Microsoft.

And yes, I do read the help file, there is a lot of technical information in here.

Tags:
No Comments »

Do I need a CAS Array?

Categories: Exchange Server Microsoft Related
September 12th, 2011 by

I wouldn’t be surprised if I saw this topic covered at TechEd next year.  I have many clients ask me the following question a lot, “do I need a CAS Array in my organization?”  I imagine that there are many people out there wondering the exact same thing.  So, do you need a CAS Array for your Exchange 2010 organization?

Well, let’s start out by looking at how Exchange 2010 will work without a CAS array.  In the event where you do not have a CAS Array when you create a Database the database will configure the “RpcClientAccessServer” (the RPC Endpoint for Outlook Client Connectivity) based on one of the following:

  • If you have both the Client Access server role and the Mailbox server role on the same physical server, the value of RPCClientAccessServer property for a particular Mailbox server will be the same as the Mailbox server.
  • If you have the Client Access server role on a separate maching the RPCClientAccessServer property for a particular Mailbox server will be set to a random Client Access server within the Active Directory site.

What this means is that the Mailbox Database that you created will either assign the RPCClientAccessServer property based on one of the two options above.   Which brings me to Scenario one.

Scenario one:

Let’s say you have two Exchange Servers deployed within your organization EXCH1 and EXCH2.  Each server is running the Mailbox, Hub Transport, and Client Access role in the same Active Directory Site.  Now say you deploy one databases on each server Database1 on EXCH1 and Database2 on EXCH2.  Each Database will be assigned the RPCClientAccessServer property with the server name the database resides on.  i.e. Database1 will have a RPCClientAccessServer set to EXCH1 and Database2 will have a RPCClientAccessServer set to EXCH2.

Next we deploy a DAG within our two nodes and replicate the two databases between the servers.  Even with a DAG deployed in the event that EXCH2 goes off line all users in Database2 will lose their connection!  This is because their RPCClientAccessServer points to EXCH2 even thought their database is mounted on EXCH1.  The RPCClientAccessServer property does not get updated automatically.

End Scenario one

Now let’s take a look at how Exchange 2010 behaves if the CAS Array is already created.  When you create a Database the database will configure the “RpcClientAccessServer” (the RPC Endpoint for Outlook Client Connectivity) based on one of the following:

  • In the event that you have first created a CAS Array and then second created a mailbox database Exchange will assign the RPCClientAccessServer property with the name of the CAS Array for that Active Directory site.

Which brings me to Scenario two!

Scenario two:

Let’s say you have two Exchange Servers deployed within your organization EXCH1 and EXCH2.  Each server is running the Mailbox, Hub Transport, and Client Access role in the same Active Directory Site.  There is no hardware load balancer in your organization but you decided that before creating any databases in your organization you would create a CAS Array.  (for info on creating a CAS Array see my article: Exchange 2010 Client Access Server Array (CAS Array)

Once the CASArray has been created you go out and create a DNS entry, in this case cas.scottfeltmann.com.  For an IP address for this DNS entry you type in the IP Address of EXCH1 and set the time to live to 5 minutes or less (you could do DNS round robin but in the event of an outage 50% of the users will be off line).

Now that we have our CAS Array created we can move forward and create our two new databases, Database1 and Database2.  Each Database will reside on their respective servers EXCH1 and EXCH2.  Since we have created our CAS Array the RPCClientAccessServer property will be set with the CAS Array name, in this case “cas.scottfeltmann.com”.

As a final step a DAG has been deployed to replicate the mailbox databases between the two servers within our organization.  Since our CAS Array is currently pointing to cas.scottfeltmann.com which points to EXCH1 in the event that we lose the server EXCH1 our users will lose their connection.  Once this occurs a manual process needs to take place to update the DNS entry cas.scottfeltmann.com to point to EXCH2.  Once DNS updates, all users will be back on line and working again!  Much better than the scenario one if you ask me.

End Scenario 2.

Honestly to simply the failover process I always suggest a Hardware Load Balancer like Kemp Technologies (http://www.kemptechnologies.com/us/) which will automatically re-establish the connection.

Also keep in mind that if you created a Mailbox database before the creation of a Client Access array or the installed a Client Access server within the Active Directory site, you’ll need to reconfigure the value of the RPCClientAccessServer property. If no Client Access server exists in the Active Directory site when the Mailbox database is created, the value of the RPCClientAccessServer property will be set to the FQDN of the Mailbox server. To configure the value of the RPCClientAccessServer property, use the following command: Set-MailboxDatabase DBName -RPCClientAccessServer cas.scottfeltmann.com (or whatever your CAS Array name is).  In some rare instances you  may run into a bug where you created the CAS Array after the databases were deployed, and updated the RPCClientAccessServer property on the Database.  For more information on that bug see my article Outlook Profile not updating after creating CAS Array.

So, to answer the question, “Do I need a CAS Array?”  The answer is Yes!  Most certainly!  Absolutely!
Edit — I should point out, even if you have a single Exchange 2010 Server in your entire Organization you should use a CAS Array!

Questions?  Comments?  Please Share!


 

 

 

 

Tags:
3 Comments »

Exchange 2010 SP1 Rollup 4 re-released

Categories: Exchange Server Microsoft Related
July 28th, 2011 by

As many of you know the Exchange team released Exchange 2010 SP1 Rollup 4 back on June 22nd.  Well, on July 13th there was a bug identified with the release and they had to pull the release.

Last night the Exchange team re-release Rollup 4 for Exchange 2010 SP1.  Following the release they also posted a update on what happened with the recall of Rollup 4 and what they are doing to help reduce the likelihood of this happening in the future.

As for me, I may wait a week or two before applying it just to be sure it is working correctly.  Not to say I doubt the Exchange team but if you recall Rollup 3 for Exchange 2010 SP1 went through three revisions before they got it right.

Here is a quick read of the Q&A of the update on Rollup 4:

  • Q: What actually triggered the recall?
  • A: While fixing a bug that prevented deleted public folders from being recovered, we exposed an untested set of conditions with the Outlook client. When moving or copying a folder, Outlook passes a flag on a remote procedure call that instructs the Information Store to open deleted items which haven’t been purged. Our fix inadvertently caused the RPC to skip all content that wasn’t marked for deletion because we were not expecting this flag on the call from Outlook on the copy and move operations.
  • Q: Why didn’t you test this scenario?
  • A: The short answer is we thought we did. We didn’t realize we missed a key interaction between Exchange and Outlook. The Exchange team has well over 100,000 automated tests that we use to validate our product before we ship it. With the richness and number of scenarios and behaviors that Exchange supports, automated testing is the only scalable solution. We execute these tests in varying scenarios and conditions repeatedly before we release the software to our customers. We also supplement these tests with manual validation where necessary. The downside of our tests is that they primarily exercise the interfaces we expose and are designed around our specifications. They do test positive and negative conditions to catch unexpected behavior and we did execute numerous folder copy and move tests against the modified code which all passed. What we did not realize is that our tests were not emulating the procedure call as executed by Outlook.
  • Q: Exchange has been around a while, why did this happen now?
  • A: In Exchange 2010 we introduced a feature called RPC Client Access. This functionality is responsible for serving as the MAPI endpoint for Outlook clients. It allowed us to abstract client connections away from the Information Store (on Mailbox servers) and cause all Outlook clients to connect to the RPC Client Access service.    As part of our investigation, we discovered that there was some specific code added to the Exchange 2003 Information Store to handle the procedure call from Outlook using the extra flag. This code was also carried forward into Exchange 2007. But when the Exchange team added the RPC Client Access service to Exchange 2010, that code was not incorporated into the RPC Client Access service because it was mistakenly believed to be legacy Outlook behavior that was no longer required. That, unfortunately, turned out not to be the case. The fact that we were not allowing a deleted public folder to be recovered was masking this new bug completely.
  • Q: Are there other similar issues lurking in RPC Client Access?
  • A: We do not believe so. The RPC Client Access functionality has been well-tested at scale and proven to be reliable for the millions of mailboxes hosted in on-premises deployment and in our own Office 365 and Live@EDU services.
  • Q: What are you doing to prevent similar things from happening in the future?
  • A: We have conducted a top-to-bottom review of the process we use to triage, develop and validate changes for Rollups and Service Packs and are making several improvements. We have changed the way we evaluate a customer requested fix to ensure that we more accurately identify the risk and usage scenarios that must be validated for a given fix. Recognizing the diversity of clients used to connect to Exchange, we are increasing our client driven test coverage to broaden the usage patterns validated prior to release. Most notably, we are working even closer with our counterparts in Outlook to use their automated test coverage against each of our releases as well. We are also looking to increase coverage for other clients as well.

 

 

 

Tags:
No Comments »

If you’re running Exchange 2010 and have a DAG install one of the following Hotfixes

Categories: Exchange Server Microsoft Related
July 12th, 2011 by

I came across an interesting Tweet yesterday from Scott Schnoll which said “If you have a DAG, install the cluster hotfixes from MSKB 2549472, 2549448 or 2552040. Only need to install one (same files in each hotfix).”

The Hotfixes can be found here:

Why any one of these KBs?  Well each KB has the same files required to repair the issue that Microsoft has discovered with Exchange 2010.  As Scott put it, “These packages contain the same cluster fixes, which address some issues that can affect network connectivity in a cluster.”

Thanks Scott!

Tags:
No Comments »

Exchange 2010 OWA redirection causing a forever loop

Categories: Exchange Server Microsoft Related
June 22nd, 2011 by

I ran into a problem last week where a client wanted to have all http traffic into an exchange 2010 server get redirected to https.  While there are a number of ways of doing this I found a nice article by Brian Desmond  on how to configure doing IIS redirects using IIS 7 instead of creating Custom Code, which is what I used to do.  The article proved to be a great find however there was an error that occurred as a result of configuring the Redirect.

While stepping through the article I did exactly what the article said to do however as part of the process of assigning the redirect to go to /owa for the Exchange, ExchWeb, and Public Folders the OWA virtual directory also inherited the /owa redirect.  This basically caused a loop whenever a user went to https://owa.domain.com/owa.  The URL kept doing a forward which caused the loop.

In my research I was able to find the problem, as I mentioned, the OWA virtual directory inherited the loop.  If I went to the OWA virtual directory and cleared the check box to do the Redirect it would clear the redirect for all the required virtual directories!  When I would re-enabled the redirect for the Exchange virtual directory it would enable the redirect on the OWA virtual directory.

As it turns out when making the modifications to the Exchange Redirects the web.config file also gets a line added to the configuration for redirects.  The first step to resolve this issue is to remove the httpRedirect in the web.config file located in “C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa”.  Once in this directory I oped the web.config file and looked for the redirect reference which appeared like this: <httpRedirect enabled=”false” destination=”/owa” childOnly=”false” />

By removing that above line and saving the Web.Config I was then able to use appcmd to set the config of the /Exchange, /Exchweb, and /Public virtual directories.  To enable the redirection type the following:

C:\Windows\System32\inetsrv>appcmd set config “Default Web Site/Exchange” /section:httpredirect /enabled:true -commit:apphost

C:\Windows\System32\inetsrv>appcmd set config “Default Web Site/Exchweb” /section:httpredirect /enabled:true -commit:apphost

C:\Windows\System32\inetsrv>appcmd set config “Default Web Site/Public” /section:httpredirect /enabled:true -commit:apphost

And then this to disable redirection for /owa:

C:\Windows\System32\inetsrv>appcmd set config “Default Web Site/owa” /section:httpredirect /enabled:false -commit:apphost

And done, the redirects work correctly and the /owa loop is removed!

Tags:
2 Comments »
« Older Entries

  • You are currently browsing the archives for the Microsoft Related category.