Archive for the ‘Exchange 2010’ Tag

Exchange 2010 Virtualization Bans Have Been Lifted!   Leave a comment


Ok maybe I was a  little dramatic in my title but the Exchange Team recently release the following article which states some big news for companies looking to virtualize as much as possible. Here is a little snip from the article:

“As of today, the following support scenarios are being updated, for Exchange 2010 SP1, and later:

  • The Unified Messaging server role is supported in a virtualized environment.
  • Combining Exchange 2010 high availability solutions (database availability groups (DAGs)) with hypervisor-based clustering, high availability, or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers, is now supported.”

For the full article please go here.

The posts are provided “AS-IS” with no warranties, and confers no rights

Advertisements

Exchange 2010 SP1 Rollup 3 v3 Release   Leave a comment


Below is the article about the re-release of Rollup 3 which fixes issues related to the original release of it.

http://blogs.technet.com/b/exchange/archive/2011/04/06/announcing-the-re-release-of-exchange-2010-service-pack-1-update-rollup-3-v2.aspx

Posted April 9, 2011 by Chris Morgan in Exchange/UC

Tagged with ,

Exchange 2010 SP1 Rollup 3 and BlackBerrys sending duplicate messages   Leave a comment


The below article was provided by the Exchange Team. The article can be found here.

We have received notification of an issue impacting some customers which have RIM BlackBerry devices connecting to an Exchange 2010 SP1 RU3 environment. At this stage we are actively working with RIM to identify the exact scenarios in which customers are reporting this issue in order to narrow down the root cause of the problem and identify a suitable resolution for it.

As a precautionary measure we have deactivated the download page for Exchange 2010 SP1 RU3 until we can identify the appropriate next steps.

If you are a customer seeing duplicate messages being delivered when an email is sent from a BlackBerry device and you have RU3 installed within your Exchange 2010 environment, our recommendation is to contact Microsoft Support for assistance in troubleshooting the issue you’re experiencing.

Our recommendation at this time for all customers is to hold off deploying RU3 until we have identified and resolved these issues. If you have already deployed RU3 and you are not seeing any issues within your environment, our recommendation is to leave RU3 in place at this time.

Once the next steps are confirmed we will post an update here on the EHLO blog.

Thanks
Kevin Allison
GM Exchange Customer Experience

Posted March 16, 2011 by Chris Morgan in Exchange/UC

Tagged with ,

Exchange 2010 – Multiple OWA/ECP Directories Part 1   16 comments


***Edited New-ECPVirtualDirectory cmdlet text – August 12th, 2011***

This document was written to provide step by step instructions for anyone wanting to configure multiple OWA and ECP directories in Exchange 2010. The document will go through a setup and configuration which can provide the baseline for any configuration variation required by an organization needing this type of solution. This document will NOT provide a one stop solution for all scenarios. The solution provided was based on the article by the Exchange Team which can be found here.

Note: The sample configurations shown were done primarily through Exchange Management Shell (EMS). Some of these tasks can be completed through Exchange Management Console (EMC); however, showing them through EMS allows an easily repeatable process through scripting or copy and paste.

Background:

The biggest reason (in my opinion) to have this configuration is in situations where the organization wants to prevent internal Outlook Web App (OWA)/Exchange Control Panel (ECP) traffic in remote sites from coming into the primary site and then back to the remote (via CAS proxy). However, there are 3 common reasons identified by the Exchange Team which calls for this solution, one of which is the reason identified above.

Scenario 1: There is one Active Directory site facing the Internet, and there is a reverse proxy (such as Microsoft Forefront Threat Management Gateway or Unified Access Gateway) in front of Exchange. The reverse proxy is configured to delegate credentials to Exchange, meaning the CAS servers are configured to use Basic or Integrated Windows Authentication (IWA) and not Forms-based Authentication (FBA). The requirement is to provide FBA for all users, internal and external.

Scenario 2: There is a non-Internet facing Active Directory site and your requirement is to provide FBA for all users, internal and external.

In this configuration, in order to provide external users access to OWA or ECP, a CAS in the Internet-facing site must proxy requests to the CAS in the non-Internet-facing site. This requires the CAS in the non-internet-facing site have IWA enabled, thereby disabling FBA.

Scenario 3: There are different users within one organization who require a different OWA experience, such as a different customization of the Form Based login page, or different Public/Private File Access or Segmentation features.

Part 1 of this document will provide the basic setup required for creating multiple sites with different configurations. In part 2 of this document I will show you how to take these basic steps and use them (with some tweaks) to configure a remote site that has two or more CAS servers configured with Windows Network Load Balancing (WNLB).

Prep Work:

In order to get the ground work ready for multiple OWA and ECP virtual directories there are a few things that need to be done.

Step 1: IP Address

Obtain a second IP address and add it to the NIC of your server.

NOTE: If the servers are configured in a Windows NLB cluster please refer to the second part of this document. As there are a few differences that will be required in order for it to work properly.

Above I have shown I have two IP addresses assigned to this NIC. 192.168.50.20 (Primary IP) and .100 for the secondary IP.

Step 2: DNS

Add a DNS entry for that secondary IP address for the name we will want to use in the new FBA OWA web site. I have chosen “testwebmail”. Be sure there is a valid SSL certificate (recommended to have UC or SAN SSL certs) on the server which has the new name “testwebmail” that will be used in the certificate.

NOTE: In order to configure SSL communication during the creation of the new website, a certificate is required. Ensuring it has the correct name, is from a trusted Certificate Authority, and is in the valid date range will avoid certificate errors seen by clients. For more information see this TechNet article.

Step 3: New Web Site

Create a new web site in IIS on the Client Access Server and bind it to the new IP address used in step 1.

To do this open “Internet Information Services” from the Administrative Tools menu. Expand down to “Sites”. You should see the “Default Web Site” listed similar to what’s shown below.

Right click on “Sites” and select “Add Web Site”

Now a box will come up where information will be required to be filled in. I have provided some information for each field that requires input.

 

  1. Site Name – I like to keep mine simple for easy management when in EMS so I named it “FBA”.
  2. Select the physical path where the files will be – I put mine in the inetpub directory under a new folder called FBA.
  3. In the “Type” field, select “https” in the drop down menu.
  4. Enter the IP address that was added from Step 1. This is called the binding.
  5. Select the SSL certificate in the drop down menu.

Once finished you should see this:

Now the ground work is complete and we can move into Exchange and begin our configuration. But wait!…there is someone in my head telling me I should bind the primary IP address to the Default Web Site before moving to Exchange. DON’T LISTEN!!!!! Doing this will actually break powershell. The Exchange Team made a note in their article as well. Good thing I read that article AFTER I already broke it the first few times I tried this. 🙂

Configuring Exchange

Step 4: Adding Exchange Virtual Directories

The web site has been created and bound to the secondary IP address of our server. Also the DNS record that will be used to access the new FBA OWA page was added to DNS. The next step is to go into EMS and begin adding our virtual directories for OWA and ECP.

Login to the Exchange server and open the Exchange Management Shell. Then run Get-OWAVirtualDirectory and Get-ECPVirtualDirectory to see the default OWA and ECP directories.

 

NOTE: Notice the names. In previous steps I mentioned I used a short simple name for the web site I will be adding these new directories to. This is because in EMS the name will always appear as “owa (SiteName)” and “ecp (SiteName)”. With a shorter name it makes it easier to work with in EMS.

Now run the cmdlets to create a new OWA and ECP site.

New-OWAVirtualDirectory –Name FBA –WebSiteName FBA –InternalUrl https://testwebmail.mylab.ad/owa

 

 

New-ECPVirtualDirectory  –WebSiteName FBA –InternalUrl https://testwebmail.mylab.ad/ecp

 

At this point the virtual directories are created with default settings using FBA. Now we have two OWA and two ECP sites both configured to use FBA.

Step 5: Configure the Virtual Directories

To configure the virtual directories we will disable FBA on the Default Web Site OWA and ECP virtual directories.

 

Set-OWAVirtualDirectory –Name “OWA (Default Web Site)” –WindowsAuthentication $true –BasicAuthentication $false –FormsBasedAuthentication $false

 

Set-ECPVirtualDirectory –Name “ECP (Default Web Site)” –WindowsAuthentication $true –BasicAuthentication $false –FormsBasedAuthentication $false

 

NOTE: This sample is configuring the default site with Windows Authentication. This is for scenarios where internal users are not to be prompted or for remote sites that require CAS Proxy functionality to work while allowing local users to access the FBA page locally without going across the WAN. Verify this is needed for the situation and make adjustments to the authentication mechanism as needed.

OPTIONAL:

I like to setup the FBA to not require the domain name as a part of the logon. This prevents less calls to the help desk and end user confusion. Some situations will require the domain name as a part of the logon. For example, in an environment with multiple domains.

To do this simply type the following:

Set-OWAVirtualDirectory –Name “OWA (FBA)” –LogonFormat Username –DefaultDomain mylab.ad

 

Step 6: Verify the Virtual Directory Configuration

Once the virtual directories are configured, verification of the settings can be accomplished with the following cmdlets:

 

Get-OWAVirtualDirectory | FL Name,*Url,*Authentication,LogonFormat,Defaultdomain

 

Get-ECPVirtualDirectory | FL Name,*Url,*Authentication,LogonFormat,Defaultdomain

 

NOTE: “FL” stands for format-list. I don’t want all the output provided by a format-list so I have specified specific parameters I want to see the values of. For more information on how to manipulate the output see this link.

With the above output I can verify that OWA and ECP directories are configured as desired. The directories on the Default Web Site are configured for Windows Authentication and the directories on the FBA web site are configured for FBA with logon format I want.

The final step in the configuration is to run iisreset on the Exchange server to ensure the settings take effect. It is not necessary to open a command prompt. This can be run from EMS.

 

 

NOTE: Because this was a lab environment I did not run iisreset with the /noforce switch. However, if you have active connections to the systems that you do not want to interrupt you should use the /noforce switch.

Conclusion

Now there are two different web sites, each configured with a different authentication mechanism for the OWA and ECP virtual directories. This can allow more flexibility in how clients access OWA/ECP as well as reduce WAN traffic in a remote site scenario where CAS Proxying would normally be used.

The posts are provided “AS-IS” with no warranties, and confers no rights

 

 

Posted February 28, 2011 by Chris Morgan in Exchange/UC

Tagged with , ,

The Exchange Management Troubleshooter   Leave a comment


I have had several customers with Exchange Management tool issues. There are several articles by different sites on how to troubleshoot these problems. However, even though most issues are well documented it can be challenging finding the issue and getting it fixed. The below article was posted by the Exchange Team to help ease the troubleshooting process of Exchange Management tool issues with a tool called EMTshooter. I provided the direct link to the article at the bottom of this post for reference as well.  

As was discussed in the previous (related) blog post “Troubleshooting Exchange 2010 Management Tools startup issues“, in Exchange 2010 the Management tools are dependent on IIS. As was discussed in that blog, we have seen situations where the management tool connection to the target Exchange server can fail, and the error that is returned can be difficult to troubleshoot. This generally (but not always) happens when Exchange 2010 is installed on an IIS server that is already in service, or when changes are made to the IIS server settings post Exchange Install. We have seen that these changes are usually done when the IIS administrator is attempting to “tighten up” IIS security by editing the Default Web Site or PowerShell vdir settings.

The situation is further complicated by the fact that some of the errors presented have similar wording; most seem to originate with WinRM (Windows Remote Management), and in some cases different root problems can produce the exact same error message. In other words, depending on how knowledgeable you are with these errors, troubleshooting them is all around… not much fun.

I was approached by a good friend of mine and he asked what I thought we could do to make these errors a little easier to troubleshoot. I was studying PowerShell and PowerShell programming at the time (I just happened to be reading Windows PowerShell for Exchange Server 2007 SP1), and I thought that this would be a perfect opportunity to try and apply what I was learning.

This is the result.

Introducing the Exchange Management Troubleshooter (or EMTshooter for short).

What it does:

The EMTshooter runs on the local (target) Exchange server and attempts to identify potential problems with management tools connection to it.

The troubleshooter runs in 2 stages. First, it will look at the IIS Default Web Site, the PowerShell vdir, and other critical areas, to identify known causes of connection problems. If it identifies a problem with one of the pre-checks it will make a recommendation for resolving the problem. If the pre-checks pass, the troubleshooter will go ahead and try to connect to the server in the exact same way that the management tools would. If that connection attempt still results in a WinRM-style error, the troubleshooter will attempt to compare that error to a list of stored strings that we have taken from the related support cases that we have seen. If a match is found, the troubleshooter will display the known causes of that error in the CMD window. Here is an example of how this might look like:

When I was designing the troubleshooter, I could have just written a little error lookup tool that handed over the appropriate content for the error you were getting, but I felt that was not as robust of a solution as I was aiming for (and not much of a learning experience for me). So the tool runs active pre-checks before moving on to the error look-up. The amount of pre-checks it can run depends on the flavor of OS you are running on and the options you have installed on it, such as WMI Compatibility.

Basically, I have taken all of the documentation that has been created on these errors to date, and created a tool that will make the information available to you based on the error or problem it detects. Hopefully this will cut down on the amount of time it takes to resolve those problems.

Event reporting:

When you run the EMTshooter it will log events in the event log. All results that are displayed in the CMD window are also logged in the event log for record keeping.

Events are logged to the Microsoft-Exchange-Troubleshooters/Operational event log and are pretty self-explanatory.

Things to remember:

Depending on your current settings, you may need to adjust the execution policy on your computer to run the troubleshooter, using:

Set-ExecutionPolicy RemoteSigned

Or

Set-ExecutionPolicy Unrestricted

Remember to set it back to your normal settings after running the troubleshooter.

This version of the troubleshooter needs to run on the Exchange Server that the management tools are failing to connect to. While our final goal is that the troubleshooter will be able to run anywhere the Exchange Management tools are installed, the tool isn’t quite there yet.

We have seen instances where corruption in the PowerShell vdir or in IIS itself has resulted in errors that seemed to be caused by something else. For instance, we worked on a server that had an error that indicated a problem with the PowerShell vdir network path. But the path was correct. Then we noticed that the PowerShell vdir was missing all its modules, and quite a few other things. Somehow the PowerShell vdir on that Exchange Server had gotten severely… um… modified beyond repair. WinRM was returning the best error it could, and the troubleshooter took that error and listed the causes. None of which solved the problem. So be aware that there are scenarios that even this troubleshooter cannot help at this time.

The troubleshooter is still a bit rough around the edges, and we plan to improve and expand its capabilities in the future. We also hope to be able to dig a little deeper into the PowerShell vdir settings as time goes on. Also note that the troubleshooter will NOT make any modification to your IIS configuration without explicitly asking you first.

Permissions required:

In order to run the troubleshooter, the user will have to have the rights to log on locally to the Exchange server (due to local nature of the troubleshooter at this time) and will need permissions to run Windows PowerShell.

Installing the troubleshooter:

First, you will need to download the troubleshooter ZIP file, which you can find here.

Installing the EMTshooter is pretty easy. Just drop the 4 files from the ZIP file into 1 folder, rename them to .ps1 and run EMTshooter.ps1 from a normal (and local) PowerShell window. I personally just created a shortcut for it on my desktop with the following properties:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command “. ‘C:\EMTshooter\EMTshooter.ps1′”

However, as most users probably won’t run this more than a few times you might not need or want an icon. Just remember that EMTshooter.ps1 is the main script to run.

Providing feedback:

As I mentioned before, the troubleshooter is still a work in progress. If you wish to provide feedback on it, please post a comment to this blog post. I will be monitoring it and replying as time allows, and also making updates to the troubleshooter if needed. If you run into errors that are not covered by the troubleshooter, please run the troubleshooter, reproduce the error through it and send me the transcript.txt file (you will find it in the folder where the 4 scripts have been placed), along with what you did to resolve the error (if the problem has been resolved). My email is sbryant AT Microsoft DOT com.

Errors currently covered:

  • Connecting to remote server failed with the following error message : The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid.
  • Connecting to remote server failed with the following error message: The connection to the specified remote host was refused. Verify that the WS-Management service is running on the remote host and configured to listen for requests on the correct port and HTTP URL.
  • Connecting to remote server failed with the following error message: The WinRM client received an HTTP server error status (500), but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic. It was running the command ‘Discover-ExchangeServer -UseWIA $true -SuppressError $true’.
  • Connecting to remote server failed with the following error message : The WinRM client received an HTTP status code of 403 from the remote WS-Management service.
  • Connecting to the 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.
  • Connecting to remote server failed with the following error message : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service:
  • Connecting to remote server failed with the following error message : The WS-Management service does not support the request.
  • Connecting to remote server failed with the following error message : The WinRM client cannot process the request. The WinRM client tried to use Kerberos authentication mechanism, but the destination computer

Steve Bryant

Reference: http://msexchangeteam.com/archive/2010/12/07/457139.aspx

The posts are provided “AS-IS” with no warranties, and confers no rights

Windows 7 Phones and Exchange Active Sync   Leave a comment


I have had a few clients run into this recently and wanted to make sure you all were careful in what settings you used in your Active Sync policies. Some settings are not supported with Windows 7. This same concept goes for Droid/iPhone phones as well. Make sure you test your client versions (or phone apps) that are used to connect through Active Sync to be sure you get the desired settings. This will ensure you aren’t surprised by certain behaviors that will occur if unsupported settings are used. So below is the bulk of an article provided by the a Microsoft Technet Wiki. I provided the link at the bottom if you want to see the original article.

Supported Exchange ActiveSync Policies

It’s important to note that Windows Phone 7 devices only support a subset of the Exchange ActiveSync (EAS) policies available with Exchange 2003 SP2, Exchange 2007, and Exchange 2010. Currently, Windows Phone 7 supports the following EAS policies:

  • Password Required (this is the only policy available on Exchange 2003 SP2) 
  • Minimum Password Length
  • Idle Timeout Frequency Value
  • Device Wipe Threshold
  • Allow Simple Password
  • Password Expiration
  • Password History

The following policies will always return “TRUE” (see table later on this page):  

  • Disable Removable Storage
  • Disable IrDA
  • Disable Desktop Sync
  • Block Remote Desktop
  • Block Internet Sharing

If you want to use EAS policies not on the above list for other mobile devices in the Exchange organization, you have the following options:

  • Create a dedicated Windows Phone 7 EAS policy and associate it with mailbox users that use Windows Phone 7 devices.
  • Set the AllowNonProvisionableDevices property to true in the default EAS policy already configured.
  • Re-configure the default EAS policy within the Exchange organization, so it only has the policies listed above configured.

Note
When using multiple EAS accounts with policies set, the policies will be merged to a most restrictive resultant set.

For specific error messages received when trying to synchronize a Windows Phone 7 device with an Exchange organization that doesn’t respect one of the above options, see Windows Phone 7 fails to synchronize with error 0x85010013 or 0x8600C2B when connecting to Microsoft Exchange Server.


Supported Mail & Calendar features

Features in Windows Phone 7 RTM:

  • Exchange ActiveSync version 14.0
  • DirectPush
  • Multiple Exchange ActiveSync accounts
  • Multiple Exchange ActiveSync policies
  • Exchange Autodiscover Service
  • Remote Device Wipe (by user or admin)
  • E-mail & calendar features
    • Colored calendars for easy overview of appointments (personal/work/etc.)
    • Pivot All, Unread, urgent or flagged(aka smart filtering)
    • Multi-message actions (delete or move multiple messages to a folder & flag or mark as read/unread)
    • Nickname cache sync (shared with OWA 2010 and Outlook 2010)
    • Tightly integrated e-mail and calendar

Features not in Windows Phone 7 RTM:

  • Conversation view & action
  • In-line replies/comments
  • Access to online archive mailbox
  • Synchronize SMS messages between device and mailbox (via ActiveSync)
  • Enable or edit Out of Office settings (OOF)
  • View free/busy information for other Exchange users
  • Search for e-mail message in mailbox on Exchange server
  • Warning when multiple bad PIN codes has been entered
  • PIN code phrase challenge
  • Support for UM cards (read a preview of a voice mail)
  • Integrated voice mail player
  • IRM support  
  • Synchronize Outlook notes (you can synchronize OneNote Notes though)
  • Different Peak/Off-peak synchronization schedules

Tip
Did you know you can access your mailbox using the OWA Premium version from Internet Explorer on a Windows Phone 7 device? To do so you need to enable “Desktop version” under “Website preference” on the Internet Explorer “Settings” page. The UI experience is actually quite good since you can zoom in on the navigation pane and specific settings in the Exchange Control Panel (ECP). It’s easy to access the archive mailbox and enable or edit OOF settings etc.


Supported Exchange Server Versions

  • Exchange Server 2010
  • Exchange Server 2007
  • Exchange Server 2003 SP2
  • Exchange 2007 Online (BPOS)
  • Exchange 2010 Online (Office 365)

Important
Although Exchange Server 2003 SP2 is supported, there’s currently an issue with searching the GAL from a Windows Phone 7 device against this Exchange version. Read more in the following KB article: You Cannot Search the Global Address List with Windows Phone 7 when connecting to Exchange Server 2003.


Why All These Missing Enterprise Features?

It’s important to note that Windows Phone 7 (WP7) primarily was developed as a consumer device and not an enterprise device. As a result there of many of the enterprise oriented features we had in Windows Mobile 6.x aren’t available in WP7. However, now that WP7 is out, the Windows Phone 7 team can focus on improving WP7 further and they already do. In addition, since it’s now possible to push out updates via the new “Phone Update” feature, it doesn’t mean that you necessarily need to buy a new device or wait for the service provider to release a new build in order to benefit from features added after you got a WP7 device.

For more information and the full article go here.

For an Active Sync comparison chart go here.

The posts are provided “AS-IS” with no warranties, and confers no rights

Posted February 18, 2011 by Chris Morgan in Exchange/UC

Tagged with , , ,

Slow Outlook 2003 Notifications with Exchange 2010?   Leave a comment


Fear not, UDP notifications are coming back with a rollup.

http://msexchangeteam.com/archive/2011/01/28/457845.aspx

The posts are provided “AS-IS” with no warranties, and confers no rights

Posted February 17, 2011 by Chris Morgan in Exchange/UC

Tagged with

%d bloggers like this: