Log Parser Studio 2.0 is now available
Since the initial release of Log Parser Studio (LPS) there have been over 30,000 downloads and thousands of customers use the tool on a daily basis. In Exchange support many of our engineers use the tool to solve real world issues every day and in turn share with our customers, empowering them to solve the same issues themselves moving forward. LPS is still an active work in progress; based on both engineer and customer feedback many improvements have been made with multiple features added during the last year. Below is a short list of new features: Improved import/export functionality For those who create their own queries this is a real time-saver. We can now import from multiple XML files simultaneously only choosing the queries we wish to import from multiple query libraries or XML files. Search Query Results The existing feature allowing searching of queries in the library is now context aware meaning if you have a completed query in the query window, the search option searches that query. If you are in the library it searches the library and so on. This allows drilling down into existing query results without having to run a new query if all you want to do is narrow down existing result sets. Input/Output Format Support All LP 2.2 Input and Output formats contain preliminary support in LPS. Each format has its own property window containing all known LP 2.2 settings which can be modified to your liking. Exchange Extensible Logging Support Custom parser support was added for most all Exchange logs. These are covered by the EEL and EELX log formats included in LPS which cover Exchange logs from Exchange 2003 through Exchange 2013. Query Logging I can't tell you how many times myself or another engineer spent lots of time creating the perfect query for a particular issue we were troubleshooting, forgetting to save the query in the heat of the moment and losing all that work. No longer! We now have the capability to log every query that is executed to a text file (Query.log). What makes this so valuable is if you ran it, you can retrieve it. Queries There are now over 170 queries in the library including new sample queries for Exchange 2013. PowerShell Export You can now export any query as a standalone PowerShell script. The only requirement of course is that Log Parser 2.2 is installed on the machine you run it on but LPS is not required. There are some limitations but you can essentially use LPS as a query editor/test bed for PowerShell scripts that run Log Parser queries for you! Query Cancellation The ability to submit a request to cancel a running query has been added which will allow you to cancel a running query in many cases. Keyboard Shortcuts There are now 23 Keyboard shortcuts. Be sure to check these out as they will save you lots of time. To display the short cuts use CTRL+K or Help > Keyboard Shortcuts. There are literally hundreds of improvements and features; far too many to list here so be sure and check out our blog series with existing and upcoming tutorials, deep dives and more. If you are installing LPS for the first time you'll surely want to review the getting started series: Getting started with Log Parser Studio Getting started with Log Parser Studio, part 2 Getting started with Log Parser Studio, part 3 If you are already familiar with LPS and are installing this latest version, you'll want to check out the upgrade blog post here: Log Parser Studio: upgrading from v1 to v2 Additional LPS articles can be found here: http://blogs.technet.com/b/karywa/ LPS doesn't require an install so just extract to the folder of your choice and run LPS.EXE. If you have the previous version of LPS and you have added your own custom queries to the library, be sure to export those queries as a backup before running the newest version. See the "Upgrading to LPS V2" blog post above when upgrading. Kary WallIntroducing: Log Parser Studio
To download the Log Parser Studio, please see the attachment on this blog post. Anyone who regularly uses Log Parser 2.2 knows just how useful and powerful it can be for obtaining valuable information from IIS (Internet Information Server) and other logs. In addition, adding the power of SQL allows explicit searching of gigabytes of logs returning only the data that is needed while filtering out the noise. The only thing missing is a great graphical user interface (GUI) to function as a front-end to Log Parser and a ‘Query Library’ in order to manage all those great queries and scripts that one builds up over time. Log Parser Studio was created to fulfill this need; by allowing those who use Log Parser 2.2 (and even those who don’t due to lack of an interface) to work faster and more efficiently to get to the data they need with less “fiddling” with scripts and folders full of queries. With Log Parser Studio (LPS for short) we can house all of our queries in a central location. We can edit and create new queries in the ‘Query Editor’ and save them for later. We can search for queries using free text search as well as export and import both libraries and queries in different formats allowing for easy collaboration as well as storing multiple types of separate libraries for different protocols. Processing Logs for Exchange Protocols We all know this very well: processing logs for different Exchange protocols is a time consuming task. In the absence of special purpose tools, it becomes a tedious task for an Exchange Administrator to sift thru those logs and process them using Log Parser (or some other tool), if output format is important. You also need expertise in writing those SQL queries. You can also use special purpose scripts that one can find on the web and then analyze the output to make some sense of out of those lengthy logs. Log Parser Studio is mainly designed for quick and easy processing of different logs for Exchange protocols. Once you launch it, you’ll notice tabs for different Exchange protocols, i.e. Microsoft Exchange ActiveSync (MAS), Exchange Web Services (EWS), Outlook Web App (OWA/HTTP) and others. Under those tabs there are tens of SQL queries written for specific purposes (description and other particulars of a query are also available in the main UI), which can be run by just one click! Let’s get into the specifics of some of the cool features of Log Parser Studio … Query Library and Management Upon launching LPS, the first thing you will see is the Query Library preloaded with queries. This is where we manage all of our queries. The library is always available by clicking on the Library tab. You can load a query for review or execution using several methods. The easiest method is to simply select the query in the list and double-click it. Upon doing so the query will auto-open in its own Query tab. The Query Library is home base for queries. All queries maintained by LPS are stored in this library. There are easy controls to quickly locate desired queries & mark them as favorites for quick access later. Library Recovery The initial library that ships with LPS is embedded in the application and created upon install. If you ever delete, corrupt or lose the library you can easily reset back to the original by using the recover library feature (Options | Recover Library). When recovering the library all existing queries will be deleted. If you have custom/modified queries that you do not want to lose, you should export those first, then after recovering the default set of queries, you can merge them back into LPS. Import/Export Depending on your need, the entire library or subsets of the library can be imported and exported either as the default LPS XML format or as SQL queries. For example, if you have a folder full of Log Parser SQL queries, you can import some or all of them into LPS’s library. Usually, the only thing you will need to do after the import is make a few adjustments. All LPS needs is the base SQL query and to swap out the filename references with ‘[LOGFILEPATH]’ and/or ‘[OUTFILEPATH]’ as discussed in detail in the PDF manual included with the tool (you can access it via LPS | Help | Documentation). Queries Remember that a well-written structured query makes all the difference between a successful query that returns the concise information you need vs. a subpar query which taxes your system, returns much more information than you actually need and in some cases crashes the application. The art of creating great SQL/Log Parser queries is outside the scope of this post, however all of the queries included with LPS have been written to achieve the most concise results while returning the fewest records. Knowing what you want and how to get it with the least number of rows returned is the key! Batch Jobs and Multithreading You’ll find that LPS in combination with Log Parser 2.2 is a very powerful tool. However, if all you could do was run a single query at a time and wait for the results, you probably wouldn’t be making near as much progress as you could be. In lieu of this LPS contains both batch jobs and multithreaded queries. A batch job is simply a collection of predefined queries that can all be executed with the press of a single button. From within the Batch Manager you can remove any single or all queries as well as execute them. You can also execute them by clicking the Run Multiple Queries button or the Execute button in the Batch Manager. Upon execution, LPS will prepare and execute each query in the batch. By default LPS will send ALL queries to Log Parser 2.2 as soon as each is prepared. This is where multithreading works in our favor. For example, if we have 50 queries setup as a batch job and execute the job, we’ll have 50 threads in the background all working with Log Parser simultaneously leaving the user free to work with other queries. As each job finishes the results are passed back to the grid or the CSV output based on the query type. Even in this scenario you can continue to work with other queries, search, modify and execute. As each query completes its thread is retired and its resources freed. These threads are managed very efficiently in the background so there should be no issue running multiple queries at once. Now what if we did want the queries in the batch to run concurrently for performance or other reasons? This functionality is already built-into LPS’s options. Just make the change in LPS | Options | Preferences by checking the ‘Process Batch Queries in Sequence’ checkbox. When checked, the first query in the batch is executed and the next query will not begin until the first one is complete. This process will continue until the last query in the batch has been executed. Automation In conjunction with batch jobs, automation allows unattended scheduled automation of batch jobs. For example we can create a scheduled task that will automatically run a chosen batch job which also operates on a separate set of custom folders. This process requires two components, a folder list file (.FLD) and a batch list file (.XML). We create these ahead of time from within LPS. For more details on how to do that, please refer to the manual. Charts Many queries that return data to the Result Grid can be charted using the built-in charting feature. The basic requirements for charts are the same as Log Parser 2.2, i.e. The first column in the grid may be any data type (string, number etc.) The second column must be some type of number (Integer, Double, Decimal), Strings are not allowed Keep the above requirements in mind when creating your own queries so that you will consciously write the query to include a number for column two. To generate a chart click the chart button after a query has completed. For #2 above, even if you forgot to do so, you can drag any numbered column and drop it in the second column after the fact. This way if you have multiple numbered columns, you can simply drag the one that you’re interested in, into second column and generate different charts from the same data. Again, for more details on charting feature, please refer to the manual. Keyboard Shortcuts/Commands There are multiple keyboard shortcuts built-in to LPS. You can view the list anytime while using LPS by clicking LPS | Help | Keyboard Shortcuts. The currently included shortcuts are as follows: Shortcut What it does CTRL+N Start a new query. CTRL+S Save active query in library or query tab depending on which has focus. CTRL+Q Open library window. CTRL+B Add selected query in library to batch. ALT+B Open Batch Manager. CTRL+B Add the selected queries to batch. CTRL+D Duplicates the current active query to a new tab. CTRL+ALT+E Open the error log if one exists. CTRL+E Export current selected query results to CSV. ALT+F Add selected query in library to the favorites list. CTRL+ALT+L Open the raw Library in the first available text editor. CTRL+F5 Reload the Library from disk. F5 Execute active query. F2 Edit name/description of currently selected query in the Library. F3 Display the list of IIS fields. Supported Input and Output types Log Parser 2.2 has the ability to query multiple types of logs. Since LPS is a work in progress, only the most used types are currently available. Additional input and output types will be added when possible in upcoming versions or updates. Supported Input Types Full support for W3SVC/IIS, CSV, HTTP Error and basic support for all built-in Log Parser 2.2 input formats. In addition, some custom written LPS formats such as Microsoft Exchange specific formats that are not available with the default Log Parser 2.2 install. Supported Output Types CSV and TXT are the currently supported output file types. Log Parser Studio - Quick Start Guide Want to skip all the details & just run some queries right now? Start here … The very first thing Log Parser Studio needs to know is where the log files are, and the default location that you would like any queries that export their results as CSV files to be saved. 1. Setup your default CSV output path: a. Go to LPS | Options | Preferences | Default Output Path. b. Browse to and select the folder you would like to use for exported results. c. Click Apply. d. Any queries that export CSV files will now be saved in this folder. NOTE: If you forget to set this path before you start the CSV files will be saved in %AppData%\Microsoft\Log Parser Studio by default but it is recommended that y ou move this to another location. 2. Tell LPS where the log files are by opening the Log File Manager. If you try to run a query before completing this step LPS will prompt and ask you to set the log path. Upon clicking OK on that prompt, you are presented with the Log File Manager. Click Add Folder to add a folder or Add File to add a single or multiple files. When adding a folder you still must select at least one file so LPS will know which type of log we are working with. When doing so, LPS will automatically turn this into a wildcard (*.xxx) Indicating that all matching logs in the folder will be searched. You can easily tell which folder or files are currently being searched by examining the status bar at the bottom-right of Log Parser Studio. To see the full path, roll your mouse over the status bar. NOTE: LPS and Log Parser handle multiple types of logs and objects that can be queried. It is important to remember that the type of log you are querying must match the query you are performing. In other words, when running a query that expects IIS logs, only IIS logs should be selected in the File Manager. Failure to do this (it’s easy to forget) will result errors or unexpected behavior will be returned when running the query. 3. Choose a query from the library and run it: a. Click the Library tab if it isn’t already selected. b. Choose a query in the list and double-click it. This will open the query in its own tab. c. Click the Run Single Query button to execute the query The query execution will begin in the background. Once the query has completed there are two possible outputs targets; the result grid in the top half of the query tab or a CSV file. Some queries return to the grid while other more memory intensive queries are saved to CSV. As a general rule queries that may return very large result sets are probably best served going to a CSV file for further processing in Excel. Once you have the results there are many features for working with those results. For more details, please refer to the manual. Have fun with Log Parser Studio! & always remember – There’s a query for that! Kary Wall Escalation Engineer Microsoft Exchange SupportPermanently Clear Previous Mailbox Info
We are introducing a new parameter that can be called by using the Set-User cmdlet in Exchange Online PowerShell. The feature is focused for customers doing migration of on-premises mailboxes to the cloud and you will be able to use it within three weeks or so (Edit 1/19: we updated this due to slower than expected rollout): Customers who have Hybrid or on-premises environments with AAD Connect / Dir Sync may have faced the following scenario: User Jon@contoso.com has a mailbox on-premises. Jon is represented as a Mail User in the cloud. You are synchronizing the on-premises directory to the cloud in preparation to migrate to Exchange Online. Due to issues with the on-premises sync or due to a configuration problem, the user Jon@contoso.com does not get the ExchangeGUID synchronized from on-premises to the cloud. If the Exchange GUID is missing from the object in the cloud, assigning an Exchange license to Jon@contoso.com will cause Exchange Online to give the user a mailbox, converting the object from a Mail User to a User Mailbox. (Adding the license is a step required for the migration of the mailbox from on-premises to the cloud.) The end result is the user that has 2 mailboxes: one on-premises and one in the cloud. This is not good. Mail flow issues will follow. Those doing these types of migrations will know that the ExchangeGUID value is very important as it helps Exchange Online identify that the user has a mailbox on-premises, and if an Exchange license is assigned in the cloud, a new mailbox should not be created. The immediate fix for this situation is to remove the Exchange License from Jon@contoso.com. This will convert the cloud object for Jon back to a Mail User. Mail flow should be restored at this point. The problem now is that you have an “unclean” cloud object for Jon. This is because Exchange online keeps pointers that indicate that there used to be a mailbox in the cloud for this user: PS C:\WINDOWS\system32> Get-User Jon@contoso.com | Select name,*Recipient* Name PreviousRecipientTypeDetails RecipientType RecipientTypeDetails ---- ---------------------------- ------------- -------------------- Jon UserMailbox MailUser MailUser Re-assigning the license after that will always err on the side of caution and Exchange Online will try to re-connect the (duplicate, temporary) mailbox in the cloud (and mailboxes can be reconnected for 30 days). Therefore Jon’s account in the cloud can’t be licensed in preparation for migration. Up to now, one of the few options to fix this problem was to delete *only in the cloud* Jon’s object and re-sync it from on-premises. This would delete jon@contoso.com from the cloud – but from all workloads, not only Exchange. This is problematic because Jon could have his OneDrive or SharePoint data in the cloud only and deleting his account means that this will be deleted too. If the account is then re-created, Jon and the tenant admin would have to work to recover to his new account all the data he used to have in OneDrive or SharePoint just because Exchange data needed to be “cleaned up”. The new parameter in the user cmdlet will allow tenant admin to clean up Exchange Online Jon’s object without having to delete it. To clean the object, you can run the following command: PS C:\> Set-User Jon@contoso.com -PermanentlyClearPreviousMailboxInfo Confirm Are you sure you want to perform this action? Delete all existing information about user “Jon@contoso.com"?. This operation will clear existing values from Previous home MDB and Previous Mailbox GUID of the user. After deletion, reconnecting to the previous mailbox that existed in the cloud will not be possible and any content it had will be unrecoverable PERMANENTLY. Do you want to continue? Yes Yes to All No No to All [?] Help (default is "Y"): Y Executing this leaves you with a clean object that can be re-licensed without causing the 2-mailbox problem. Now you can on-board Jon’s on-premises mailbox following the usual steps. An alternative – a call to support to do the clean-up for you - is also not needed. Remember, cleaning up the user means that the older associated disconnected (duplicate) cloud mailbox is not recoverable. If you want to keep it or be able to check it’s content, we recommend using Soft Deletion or Inactive Mailboxes to keep the mailbox. Note: This command is expected to be executed when you have an on-premises mailbox and a mailbox in the cloud for the same object due to bad AAD Connect configuration, to clean the object that can be re-licensed. The procedure allows you get out of the dual mailbox state and enable you to re-try on-boarding the mailbox immediately. If you execute this for a user whose mailbox is cloud only after delicensing the user (and intend to later re-license the same user and expect to have a new clean mailbox for the user) - then this will not happen immediately. To avoid potential loss of mailbox data due to unintended/mistaken execution of the command, we retain the mailbox data for 30 days so that you may recover it. If your intention is to clean-up cloud only mailbox then you may hard delete the user account to re-create a clean mailbox. Mario Trigueros SolorioResolving WinRM errors and Exchange 2010 Management tools startup failures
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 attached to this post. 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 BryantDemystifying Hybrid Free/Busy: what are the moving parts?
Hybrid Free/Busy is one of those things that many people do not fully understand. If everything works well, the complexity is hidden from view and people working in various parts of organization can seamlessly work together. But if things go wrong… you will appreciate deeper understanding of what makes it work. This is why we wanted to create the blog post series on the subject. In this article, we will discuss how Free/Busy works in an Exchange Hybrid configuration. In next blog post, you will learn what we (Microsoft Support) see as the most common problems along with how we go about diagnosing those (often) complex issues. Hope you like reading, because there is a lot to cover! So, what is Free/Busy? Free/Busy is a feature that allows you to see when others are free (their calendar shows availability), busy (their calendar shows them as busy), or even Out of Office, or Something Else (tentative or working away) so that you can find an appropriate time for your meetings. Calling it all “Free/Busy/OOF/Something-Else” didn’t sound so cool to marketing hence “Free/Busy”. In a Hybrid deployment, we usually have some mailboxes in Exchange On-Premises and some mailboxes in Exchange Online (users are in different premises) and this has to work there too. One of the most important parts in Hybrid Configurations is the Federation Trust and many features, including Free/Busy can rely upon this. A quick overview of a hybrid deployment with a focus on Federation Trust components In Contoso – On-Premises side we have on-premises Exchange Servers and mailboxes. We also have a federation trust with the Microsoft Federated Gateway (MFG) - now called Azure Authentication System. A Federation trust is not set by default for Exchange On-Premises organizations and we can either create it manually or run the Hybrid Configuration Wizard (HCW) which will do this for us. If you don’t have already a federation trust established on-premises (usually for purposes to share F/B with another on-premises organization) and you plan for a Hybrid deployment, then we strongly recommend you run HCW to automatically create the Federation Trust. In Contoso – Cloud Side there are Office 365 Exchange Online servers, your Office 365 tenant and mailboxes migrated from on-premises. A Federation trust with the MFG is automatically created for cloud-only-based Exchange organizations whom do not have a Hybrid relationship to an on-premises organization. If you run Get-FederationTrust cmdlet in Exchange Online PowerShell (see here how to connect to Exchange Online PowerShell) you would see two trusts: “WindowsLiveId” (Consumer Instance of Microsoft Federation Gateway) and “MicrosoftOnline” (Business Instance of Microsoft Federation Gateway) . Note: As a troubleshooting tip, you might want to make sure the Application Identifier is “260563” and the Application Uri is “outlook.com” for both; in case you have a different App ID (292841) and a different App URI (outlook.live.com) for a Cloud trust, this means your tenant has an old reference pointing to MFG and most probably Free/Busy from on-premises to cloud would fail with a quite generic 401 Unauthorized error. If you were to find yourself in a such situation, please open a support case with Microsoft to get it resolved. About Free/Busy lookup directionality To guide you to the correct troubleshooting steps we first need to determine what direction Free/Busy queries are failing in. Understanding how Free/Busy works in general and the direction that lookups are failing can greatly simplify the troubleshooting steps. Simply said, there are 2 possible Free/Busy directions (referring to our example above): When Joe looks up Jane’s Free/Busy, the Free/Busy direction is On-premises to Cloud. When Jane looks up Joe’s Free/Busy, the Free/Busy direction is Cloud to On-Premises Now that you are familiar with the Free/Busy directions, we should take a moment to discuss how it all works. Let me set the stage for the below diagram: joe@contoso.com has his mailbox in Exchange on-premises and jane@contoso.com has been moved to Exchange Online. In Exchange on-premises, joe@contoso.com is a Mailbox User. Because Directory Synchronization is a requirement for Hybrid Deployments, joe@contoso.com (mailbox) is synced to the cloud and represented as a Mail Enabled User (MEU) object in Cloud with Target Address (TA) of joe@contoso.com. jane@contoso.com was once a Mailbox User in Exchange on-premises. Her mailbox was then migrated to Exchange Online. Jane now has a Mailbox User in Exchange Online and is represented as a Remote Mailbox (RM) object in Exchange On-Premises. Jane has a Primary SMTP address (SMTP: jane@contoso.com) and a secondary smtp address (smtp: jane@contoso.mail.onmicrosoft.com). Notice how we refer to a primary email address (SMTP) and to a secondary email address (smtp). According to TechNet, the difference between primary and secondary addresses is that the primary address serves as the return e-mail address. When mail is received from a recipient, the primary address determines which address the mail appears to have come from. Recipients can receive mail sent to any of the addresses associated with them (primary or secondary). The Target Address (TA) of the on-premises Remote Mailbox object is represented as jane@tenant.mail.onmicrosoft.com (secondary smtp) and this is crucial for Autodiscover and email routing from on-premises to cloud. A successful Autodiscover query is important in the Free/Busy process as it provides us with the Availability Service URL of the user which is the External EWS URL of an Exchange Organization. This TechNet article gives us more information on this <domain>.mail.onmicrosoft.com secondary email address: The wizard (HCW) adds an accepted domain to the on-premises organization for hybrid mail flow and Autodiscover requests for the cloud organization. This domain, referred to as the coexistence domain, is added as a secondary proxy domain (contoso.mail.onmicrosoft.com) to any email address policies which have PrimarySmtpAddress templates for domains selected in the Hybrid Configuration wizard(contoso.com). By default, this domain is <domain>.mail.onmicrosoft.com. Table below illustrates the hybrid user objects discussed above as well as how to look them up. On-premises commands = Exchange Management Shell Cloud commands = Exchange Online PowerShell Typical Hybrid user objects configuration On-premises commands On-premises objects Corresponding cloud objects Cloud commands ON-PREM MAILBOX USER MAIL ENABLED USER IN CLOUD Get-mailbox Joe@contoso.com | FT PrimarySMTPaddress On-premises mailbox user with SMTP: Joe@contoso.com Cloud mail enabled user with SMTP: Joe@contoso.com Get-MailUser Joe@contoso.com | FT PrimarySMTPAddress (Get-mailbox Joe@contoso.com). EmailAddresses On-premises mailbox user has a secondary smtp address of @contoso.mail. onmicrosoft.com configured by HCW (Email Address Policies) Cloud mail enabled user has this secondary smtp Joe@contoso.mail. onmicrosoft.com (Get-mailuser Joe@contoso.com). EmailAddresses (Get-mailbox Joe@contoso.com). EmailAddresses On-premises mailbox user has a secondary smtp Joe@contoso.mail. onmicrosoft.com Cloud mail enabled user has an ExternalEmailAddress Joe@contoso.com Get-MailUser Joe@contoso.com |FT ExternalEmailAddress REMOTE MAILBOX ON-PREM MAILBOX USER IN CLOUD Get-RemoteMailbox Jane@contoso.com |FT primarySMTPaddress Remote mailbox SMTP: Jane@contoso.com Mailbox User SMTP: Jane@contoso.com Get-Mailbox Jane@contoso.com |FT PrimarySMTPAddress Get-RemoteMailbox Jane@contoso.com | FT RemoteRoutingAddress Remote mailbox TargetAddress: Jane@contoso.mail. onmicrosoft.com Mailbox User smtp: Jane@contoso.mail. onmicrosoft.com (Get-Mailbox Jane@contoso.com). EmailAddresses Now that we understand user objects and their relevant properties, we should come back to Free/Busy directions. Between the on-premises organization and cloud organization there are bidirectional Organization Relationships and/or bidirectional Intra Organization Connectors (for Exchange 2013 or later) that are created during Hybrid Configuration. The source of these Relationships / Connectors plays an important role in the F/B directionality. The Free/Busy directions are: Direction On-premises to Cloud You are logged in to Outlook on the Web or Outlook on Windows as an on-premises user (joe@contoso.com), you’re your mailbox hosted on your on-premises Exchange server. As an on-premises user you wish to have a meeting with the cloud user (jane@contoso.com) but will first have to check their availability for the meeting. Let’s walk through the process: 1. Joe creates a meeting request and adds Jane as an attendee. 2. The on-premises Exchange server in Contoso determines (usually based on Target Address of the mail-enabled user) that Jane is not a local mailbox and has a different domain name of contoso.mail.onmicrosoft.com set as the Target Address. 3. The Availability Service on the on-premises Exchange server (Client Access Server if Ex2010 or Mailbox Server if 2013/2016) in Contoso then checks to see if there is a path to query Jane’s Free/Busy information for Contoso’s cloud side. First, we check if we have an Intra-Organization Connector (1) with the domain name of contoso.mail.onmicrosoft.com (assuming the Exchange server is version 2013 or later). If an IOC does not exist, then we look to see if an Organization Relationship (2) is configured by looking for the domain name of contoso.mail.onmicrosoft.com in the list of any existing Organization Relationships. If neither an IOC nor an Organization Relationship for the domain contoso.mail.onmicrosoft.com exists, then we look for the domain name contoso.mail.onmicrosoft.com as an Availability Address Space (3). 4. Assuming we would have an Exchange 2010-only environment in the on-premises and we’ve ran HCW successfully, we should expect to see both an Organization Relationship as well as a Federation Trust which combined is the second option from step #3. The Target ApplicationURI in the Contoso on-premises Organization Relationship is set to outlook.com, which is an identifier for the Contoso Cloud organization trust in the Azure Authentication System. A request is then made to the Azure Authentication System for a delegation token that will be accepted by Contoso Cloud Organization. 5. Once the delegation token is received back from the Azure Authentication System, the Exchange server in Contoso on-premises sends an Autodiscover request to Exchange Online, and upon a successful Autodiscover response will send an EWS request to Exchange Online for Jane’s availability information. 6. The Exchange Online server validates the token provided by the Azure Authentication System and once confirmed, returns the requested Free/Busy data for Jane’s mailbox. Here is a flowchart which illustrates the Free/Busy lookup process: Direction Cloud to on-premises You are logged in to Outlook on the Web or Outlook on Windows as a cloud user (jane@contoso.com), whose mailbox is in Exchange Online. Jane wants to have a meeting with an on-premises user (joe@contoso.com), but must first check their availability for the meeting. 1. Jane creates a meeting request and adds Joe as an attendee 2. The Exchange Online servers in Contoso-cloud side organization determine (usually based on target address of a mail-enabled user) that Joe is not a local mailbox and has a domain name of contoso.com set as the target address. 3. The Availability Service on Exchange Online servers checks to see if there is a path for it to find the Free/Busy information for Contoso on-premises side organization. First, we check if we have an Intra-Organization Connector (1) with the domain name of contoso.com (assuming the Exchange server is 2013 or later on-premises). If an IOC does not exist, then we look to see if an Organization Relationship (2) is configured by looking for the domain name of contoso.com in the list of any existing Organization Relationships. If neither an IOC nor an Organization Relationship for the domain contoso.com exists, then we then look for the domain name contoso.com as an Availability Address Space (3). 4. Assuming we would have an Exchange 2010-only environment in the on-premises and we’ve ran HCW successfully, we should expect to see both an Organization Relationship as well as a Federation Trust which combined is the second option from step #3. The Target ApplicationURI in the Contoso Cloud Organization Relationship is set to FYDIBOHF25SPDLT.contoso.com, which is an identifier for the Contoso on-premises organization trust in the Azure Authentication System. A request is then made to the Azure Authentication System for a delegation token which will be accepted by Contoso on-premises organization. 5. Once the delegation token is received back from the Azure Authentication System, the Exchange Online server in Contoso cloud sends an Autodiscover request to the on-premises Exchange Servers and upon receipt of a successful Autodiscover response it will then send an EWS request for Joe’s availability. 6. The Contoso on-premises Exchange server validates the token provided by the Azure Authentication System and once confirmed, returns the requested Free/Busy data for Joe’s mailbox. Hybrid Free/Busy lookup order To summarize, the following order would be used when processing for Free/Busy lookups from cloud to on-premises: Look for IntraOrganizationConnector (OAUTH) If there is no IntraOrganizationConnector or if it is disabled, then look for Organization Relationship (DAUTH) If neither of these are found or they’re disabled, then look for Availability Address Space. Availability Address Space is normally only used for Lotus Notes organizations. If Free/Busy lookup is getting all the way down to using the final Availability Address Space option for cloud to on-premises lookups in a hybrid deployment, then this would suggest there are configuration issues which must be repaired. The order for Free/Busy lookups from on-premises to cloud is almost the same with some exceptions: If we have Exchange 2007 servers in coexistence with Exchange 2010/2013, we use Availability Address Space from Exchange 2007 to Exchange 2010/2013 and then Exchange 2010/2013 will use Org Relationship (Ex2010) or IntraOrganization Connector (Ex2013) to Cloud. If we have Exchange 2010 with Exchange 2013/2016 and OAuth is enabled, Exchange 2010 will use Availability Address Space to Exchange 2013/2016 and then 2013/2016 will use the IntraOrganization Connector to Cloud. If we have Exchange 2010 with Exchange 2013/2016 and OAuth is not enabled, Exchange 2010 will not send the request to the Exchange 2013/2016. Instead Exchange 2010 will use Organization Relationship to Cloud for Free/Busy. Exchange 2013 Cu5+ and Exchange 2016 organizations without coexisting with legacy Exchange servers will use by default IntraOrganization Connectors from On-Premises to Cloud (normal process) This table summarizes which components (Get-IntraorganizationConnector / Get-OrganizationRelationship / Get-AvailabilityAddressSpace) are present (YES) or not (NO) in the Exchange Organization depending on the Exchange Server versions on-premises in a Hybrid deployment. Free/Busy component matrix Exchange Hybrid Environment Intra Organization Connector (IOC) Organization Relationship Availability Address Space Pure Exchange 2016 Hybrid YES (created automatically by HCW) YES YES Pure Exchange 2013 (CU5+) Hybrid YES (created automatically by HCW) YES YES Pure Exchange 2010 Hybrid NO YES YES Mixed Exchange 2007 + Exchange 2010 Hybrid NO - Ex2010 NO - Ex2007 YES - Ex2010 NO - Ex2007 YES - Ex2010 YES - Ex2007 Mixed Exchange 2007 + Exchange 2013 Hybrid YES - Ex2013 (if created manually) NO - Ex2007 YES - Ex2013 NO - Ex2007 YES - Ex2013 YES - Ex2007 Mixed Exchange 2010 + Exchange 2013 Hybrid YES - Ex2013 (if created manually) NO - Ex2010 YES - Ex2013 YES - Ex2010 YES - Ex2013 YES - Ex2010 Mixed Exchange 2010 + Exchange 2016 Hybrid YES - Ex2016 (if created manually) NO - Ex2010 YES - Ex2016 YES - Ex2010 YES - Ex2016 YES - Ex2010 Mixed Exchange 2013 + Exchange 2016 Hybrid YES - Ex2016 (created automatically by HCW) YES - Ex2013 YES - Ex2016 YES - Ex2013 YES - Ex2016 YES - Ex2013 Note: OAuth is by default configured by HCW in Exchange 2013 CU5 and above (including Exchange 2016) organizations. If Exchange 2013 / Exchange 2016 servers coexist with Exchange 2010 or older then OAUTH is not configured by default by the HCW but can be manually configured. Note: Exchange 2013 CU5 is considered old and unlike wine, the finest CU is always the most recent one. You probably have heard about our n and n-1 supported version statement in Hybrid Deployments and can read more about it here and here. Which Free/Busy lookup method are you using? I won't go into all the details about the two types of authentication (OAUTH vs DAUTH) in this post, but I recommend reading this blog post at bedtime: Deep Dive: How Hybrid Authentication Really Works. As explained there, OAuth is an open-standards based model which is more preferred to a customized model. You can quickly determine if you are using OAuth or not by running: Get-IntraOrganizationConnector cmdlet in Exchange Management Shell (for F/B direction On-Premises to Cloud) and in Exchange Online PowerShell (for F/B direction Cloud to On-Premises). If you see Enabled = True, then you are using OAuth or the system should at least be trying to. Note: We also need to make sure that the Target Domain is present on the Intra Organization Connector or Organization Relationship when deciding if using OAUTH or DAUTH. I have created two flowcharts to show you the logic of using OAUTH vs DAUTH in a F/B lookup process for each F/B direction. The user’s setup remains still the same as shown in previous examples and I am reposting the diagram here so that you don’t need to scroll up. 1. Joe’s Exchange server deciding whether to use Oauth or Dauth : 2. Jane’s Exchange Online server deciding whether to use Oauth or Dauth Now that you know which method is being used (or at least which should be attempted) and we know the direction Free/Busy is failing, we can see if you have everything configured correctly. In most cases these configurations are handled by the HCW and should be accurate and you can re-run the HCW to get things back to a good configuration. If Exchange On-Premises > Exchange Online Free/Busy is failing for all users, you would first check Intra Organization Connector or the Organization Relationship from on-premises. If Exchange Online > Exchange On-Premises Free/Busy is failing for all users, you would first check Intra Organization Connector or the Organization Relationship from Exchange Online. Below, you will see a sample of the expected configuration for Intra Organization Connectors and Org Relationships from both sides (on-premises and cloud). This Baseline configuration was documented by my co-worker Ray Fong (Support Escalation Engineer) and I am very happy to have it when I troubleshoot Free/Busy issues. Exchange Online side Use this article to connect to Exchange Online PowerShell. INTRA ORGANIZATION CONNECTOR IN CLOUD Get-IntraOrganizationConnector | fl TargetAddressDomains,DiscoveryEndpoint,Enabled TargetAddressDomains : {contoso.com} DiscoveryEndpoint : https://autodiscover.contoso.com/autodiscover/autodiscover.svc * Enabled : True Note: In practice, the On-Premises Discovery Endpoint (Autodiscover) is more likely to be found in the format https://mail.contoso.com/autodiscover/autodiscover.svc because of the EWS External URL, so pay attention to this Autodiscover URL and replace it if needed with the autodiscover.yourdomain.tld on the IOC present in the Cloud Side (Reference Set-IntraOrganizationConnector) Get-IntraOrganizationConfiguration | fl OnPremiseTargetAddresses OnPremiseTargetAddresses : {contoso.com} TargetAddressDomains - This should be your federated domains. Example: contoso.com You can find the domains name by cross-checking Exchange Online's (Get-IntraOrganizationConfiguration).OnPremiseTargetAddresses TargetDiscoveryEndpoint - This should be the address of the On-Premises Autodiscover Endpoint. Example: https://autodiscover.contoso.com/autodiscover/autodiscover.svc/.If you paste the URL in IE, you should receive a regular windows authentication security prompt Enabled - This must be True. Exchange On-Premises side (use Exchange Management Shell) INTRA ORGANIZATION CONNECTOR IN ON-PREM Get-IntraOrganizationConnector | fl Name,TargetAddressDomains,DiscoveryEndpoint,Enabled Name : ExchangeHybridOnPremisesToOnline TargetAddressDomains : {contoso.mail.onmicrosoft.com} DiscoveryEndpoint : https://outlook.office365.com/autodiscover/autodiscover.svc Enabled : True TargetAddressDomains - This should be your tenant.mail.onmicroosft.com name. Example: 'contoso.mail.onmicrosoft.com' TargetDiscoveryEndpoint - This should be the address of EXO Autodiscover endpoint. Example: https://outlook.office365.com/autodiscover/autodiscover.svc Enabled - This must be True. Exchange Online side Use this article to connect to Exchange Online PowerShell. ORGANIZATION RELATIONSHIP IN CLOUD Get-OrganizationRelationship "Exchange Online to on premises Organization Relationship" | fl DomainNames,FreeBusy*,Target*,Enabled DomainNames : {contoso.com} FreeBusyAccessEnabled : True FreeBusyAccessLevel : LimitedDetails FreeBusyAccessScope : TargetApplicationUri : FYDIBOHF25SPDLT.contoso.com TargetSharingEpr : TargetOwaURL : TargetAutodiscoverEpr : https://autodiscover.contoso.com/autodiscover/autodiscover.svc/WSSecurity Enabled : True DomainNames - This should be your federated domains. Example: contoso.com You can find the domains name by cross-checking On-Premises' (Get-FederatedOrganizationIdentifier).Domains TargetAutodiscoverEPR - This should be the address of the On-Premises Autodiscover Endpoint. Example: https://autodiscover.contoso.com/autodiscover/autodiscover.svc/WSSecurity. If you paste the URL in IE, you should receive a regular windows authentication security prompt TargetSharingEPR - Ideally this is blank. If it is set, it should be the On-Premises Exchange servers EWS ExternalUrl endpoint. Example: https://server.contoso.com/EWS/Exchange.asmx You can find the URL by cross-checking On-Prem's Get-WebServicesVirtualDirectory ExternaUrl. If you paste the URL in IE with /WSSecurity at the end (https://server.contoso.com/EWS/Exchange.asmx/WSSecurity), you should receive a regular windows authentication security prompt TargetApplicationURI - This must match the ApplicationUrI from On-Prem. Example: FYDIBOHF25SPDLT.contoso.com You can find the value by cross-checking On-Prem's (Get-FederationTrust).ApplicationUri FreeBusyAccessEnabled - This must be True. FreeBusyAccessLevel - This should be either AvailabilityOnly or LimitedDetails. AvailabilityOnly: Free/Busy access with time only LimitedDetails: Free/Busy access with time, subject, and location FreeBusyAccessScope - This is typically blank. The FreeBusyAccessScope parameter specifies a security distribution group in the internal organization that contains users that can have their Free/Busy information accessed by an external organization. Enabled - This must be True. Exchange On-Premises side (use Exchange Management Shell) ORGANIZATION RELATIONSHIP IN ON-PREM Get-OrganizationRelationship "On Premises to Exchange Online Organization Relationship" | fl DomainNames,FreeBusy*,Target*,Enabled DomainNames : {contoso.mail.onmicrosoft.com} FreeBusyAccessEnabled : True FreeBusyAccessLevel : LimitedDetails FreeBusyAccessScope : TargetApplicationUri : Outlook.com TargetSharingEpr : TargetOwaURL : https://outlook.com/owa/contoso.onmicrosoft.com TargetAutodiscoverEpr : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity Enabled : True DomainNames - This should be your tenant.mail.onmicrosoft.com name. Example: contoso.mail.onmicrosoft.com TargetAutodiscoverEpr - This should be a valid Exchange Online Autodiscover endpoint. Example: https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity or https://pod51038.outlook.com/autodiscover/autodiscover.svc/WSSecurity [<-- A pod address] You can find the value from TargetAutodiscoverEpr of Get-FederationInformaiton -DomainName tenantname.mail.onmicrosoft.com -BypassAdditionalDomainValidation | fl TargetSharingEPR - Ideally this is blank. If it is set, it should be Office 365 EWS endpoint. Example: https://outlook.office365.com/EWS/Exchange.asmx TargetApplicationURI - This must be outlook.com if this is for organization relationship of the cloud tenant. For non-cloud organization relationship, this must match (Get-FederationTrust).ApplicationUri of the On-Prem trust of the other organization. FreeBusyAccessEnabled - This must be True. FreeBusyAccessLevel - This should be either AvailabilityOnly or LimitedDetails. AvailabilityOnly: Free/Busy access with time only LimitedDetails: Free/Busy access with time, subject, and location FreeBusyAccessScope - This is typically blank. The FreeBusyAccessScope parameter specifies a security distribution group in the internal organization that contains users that can have their Free/Busy information accessed by an external organization. Enabled - This must be True. Both Autodiscover and EWS virtual directories must be enabled for WSSecurity authentication and/or OAuth. For example, if using OAuth, you should have OAuth listed as Authentication Methods, whereas if using only DAuth (Exchange 2010 for example), you would see only WSSecurity. Example of virtual directories authentication methods for an Exchange 2013 Hybrid Organization: Get-AutodiscoverVirtualDirectory -Server SERVER01 | fl Name,AdminDisplayVersion,*authentication* Name : Autodiscover (Default Web Site) AdminDisplayVersion : Version 15.0 (Build 1044.25) InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth} ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth} Get-WebServicesVirtualDirectory -Server server01| fl Name,AdminDisplayVersion,*Authentication* Name : EWS (Default Web Site) AdminDisplayVersion : Version 15.0 (Build 1044.25) InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth} ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth} As explained earlier, there are some situations where Free/Busy from on-premises to cloud is going via Availability Address Space. This would be the expected configuration for Availability Address Space in Exchange on-premises (Exchange Management Shell): Get-AvailabilityAddressSpace contoso.mail.onmicrosoft.com | fl ForestName, UserName, UseServiceAccount, AccessMethod, ProxyUrl, Name ForestName : contoso.mail.onmicrosoft.com UserName : UseServiceAccount : True AccessMethod : InternalProxy ProxyUrl : https://server01.contoso.com/EWS/Exchange.asmx Name : contoso.mail.onmicrosoft.com ForestName - The should be the tenant.mail.onmicrosoft.com domain name. This should also match the domain name of RemoteRoutingAddress of remote mailboxes. Example: contoso.mail.onmicrosoft.com UserName - This should be blank. UserServiceAccount - This must be True. AccessMethod - This should be InternalProxy. ProxyUrl - This should be the Exchange 2013/2016 Exchange Web Services Virtual Directory URL. The address could be the internal FQDN or load balancing EWS URL. Example: https://server01.contoso.com/EWS/Exchange.asmx We recommend you check the following requirements for inbound/outbound connectivity to and from Exchange servers in a Hybrid Deployment: Understanding Federated Delegation Office 365 URLs and IP address ranges If you have read this far – thank you! This concludes the Part 1 of this blog series. Onto troubleshooting next! Huge thanks to all that contributed to this blog post: Ray Fong, Nino Bilic, Tim Heeney, Greg Taylor and Brian Day. Mirela BuruianaHow to Manage Groups that I already own in Exchange 2010?
This one can be a bit counter intuitive for folks coming from any legacy version of Exchange... Issue You got your shiny new Exchange 2010 download and excitedly installed it on your 2010 hardware. You have setup all your CAS server settings, your DAG is up and running. Your pilot users have been moved over and everything went well. Now you move over the executives and not two days later they are in your office complaining that they can't manage the distribution groups that they own. They were able to do it previously but now it isn't working. A little bit of testing later and you see that they are right. You are hitting an error message in Outlook 2007 when trying to manage groups: So what does the "Changes to the distribution list membership cannot be saved. You do not have sufficient permission to perform this operation on this object." error mean, when you are connecting to an Exchange 2010 server? It means Exchange 2010 is doing its job - as designed... Why is it doing this? Exchange 2010 has quite a few features built in to allow your users to manage their own accounts and information. One of these features is the ability to manage distribution groups in a much richer format than Outlook 2007 provides. This allows your users to join existing group, manage some of the properties of groups they own, membership in groups they own, and even create and remove groups. It is that last piece that got our beta customers a bit concerned. The ability to manage your own groups is good... the ability to create and remove groups - not so good. Also this feature was turned on by default. So by default you would install Exchange 2010 Beta and any users you put on it could create and remove Distribution Groups. With that in mind the Product group decided to turn this feature off by default going forward and in RTM. Turning it off is very easy... so is turning it on. All you have to do is assign the MyDistributionGroups RBAC role to the Default Role Assignment Policy. We even have the ability to do that in the ECP. Since all of the built in RBAC roles have to function as parents to any roles that you create the product group had to leave the ability to create and remove distribution groups on this role to ensure that any customers that wanted their users to have that functionality would be able to assign it. So how do I fix it? "Fix" isn't really the right word. We need to modify the default solution to meet this specific need. For a number of customers the needs are going to be the following: I want my users to be able to manage distribution groups they own. I don't want them to be able to create distribution groups. I don't want them to be able to remove distribution groups even if they do own them. To help customers fill these needs we have created a short little script. This script will allow you to make any combination of the above work in your environment. The Manage-GroupManagementRole.ps1 script is now available as an attachment to this blog post. How do I run this thing? To run the script you need to copy the contents of the script to a text file on the machine you are going to run it on. Then save the file as a .ps1... I recommend Manage-GroupManagementRole.ps1 . To fill all of the above requirements with minimal effort run the following from an Exchange Powershell Prompt: Manage-Groupmanagmeentrole.ps1 -creategroup -removegroup This will create everything you need with the correct settings using the default names in the script. If you would like help on the script you can either look in the contents of the file or run it with no switches. What does the script do? What the script does is actually rather simple: Creates a new RBAC role that is a child of the MyDistributionGroups Role Removes the cmdlets remove-distributiongroup and new-distributiongroup from the new role that was just created. Assigns the new role to the Default Role Assignment Policy When complete your users will be able to manage distribution groups but not create or remove them. Each step the script takes is documented in the script and you are welcome to extract just what you need from it. It is designed to handle more than just the basic scenario to give it a bit more flexibility. What do I end up with if I take the defaults? When finished you end up with a new role and a new role assignment. If we look at these in PowerShell we see: Here is the Role that is created by the script. By default it is named MyDistributionGroupsManagement and is a child of the MyDistributionGroups role. Here we can see all of the cmdlet that the role authorizes users to use. You can see that remove-distributiongroup and new-distributiongroup are not listed. This is the piece that glues everything together. The role assignment is created using the name of the role and the name of the policy we are assigning the role too. The Default Role Assignment Policy applies to all users in the org by default. So everyone on Exchange 2010 will now have the ability to manage their own distribution groups. Conclusion Hopefully this post and the attached script will help you in getting your 2010 environment up and running where you want it. If you have any questions about the script or this process please feel free to post them here and I will do my best to address them. - Matt ByrdTroubleshooting Exchange 2010 Management Tools startup issues
EDIT 12/7/2010: For additional help resolving those issues, please see our newer blog post Resolving WinRM errors and Exchange 2010 Management tools startup failures. In this blog post, we will be highlighting some of the most common errors that may be seen when attempting to open the Exchange Management tools (Exchange Management Console and Exchange Management Shell). To start off, you first need to be aware that in Exchange 2010, all management is done via Remote PowerShell, even when opening the Management Tools on an Exchange server. Where this differs from Exchange 2007 is that there is now a much larger dependency on IIS, as Remote PowerShell requests are sent via the HTTP protocol and use IIS as the mechanism for connections. IIS works with the WinRM (Windows Remote Management) service, and the WSMan (Web Services for Management) protocol to initiate the connection. When you click on the Exchange Management Shell shortcut, a Remote PowerShell session is opened. Instead of simply loading the Exchange snap-in (as we did with Exchange 2007), PowerShell connects using IIS to the closest Exchange 2010 server via WinRM. WinRM then performs authentication checks, creates the remote session and presents to you the cmdlets that you have access to via RBAC (Role Based Access Control). Since all Remote PowerShell connections go through IIS, we have identified some of the most common errors that may be exhibited when attempting to open the Exchange Management tools along with the most common causes of those errors and how to address these issues. We have attempted to list these in order of frequency. Issue: 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. For more information, see the about_Remote_Troubleshooting Help topic. Possible causes: 1. Remote PowerShell uses Kerberos to authenticate the user connecting. IIS implements this Kerberos authentication method via a native module. In IIS Manager, if you go to the PowerShell Virtual Directory and then look at the Modules, you should see Kerbauth listed as a Native Module, with the dll location pointing to C:\Program Files\Microsoft\Exchange Server\v14\Bin\kerbauth.dll. If the Kerbauth module shows up as a Managed module instead of Native, or if the Kerbauth module has been loaded on the Default Web Site level (instead of, or in addition to, the PowerShell virtual directory), you can experience this issue. To correct this, make sure that the Kerbauth module is not enabled on the Default Web Site, but is only enabled on the PowerShell virtual directory. The entry type of "Local" indicates that the Kerbauth module was enabled directly on this level, and not inherited from a parent. 2. If the WSMan module entry is missing from the global modules section of the C:\Windows\System32\Inetsrv\config\ApplicationHost.config file, as follows: <globalModules> <add name="WSMan" image="C:\Windows\system32\wsmsvc.dll" /> This will result in the WSMan module displaying as a Managed module on the PowerShell virtual directory. To correct this, make sure that the WSMan module has been registered (but not enabled) at the Server level, and has been enabled on the PowerShell virtual directory. 3. If the user that is attempting to connect is not Remote PowerShell enabled. To check if a user is enabled for Remote PowerShell, you need to open the Exchange Management Shell with an account that has been enabled, and run the following query. (Get-User <username>).RemotePowershellEnabled This will return a True or False. If the output shows False, the user is not enabled for Remote PowerShell. To enable the user, run the following command. Set-User <username> -RemotePowerShellEnabled $True Issue: 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. For more information, see the about_Remote_Troubleshooting Help topic. Possible Causes: 1. The http binding has been removed from the Default Web Site. A common scenario for this is if you are running multiple web sites, and attempting to set up a redirect to https://mail.company.com/owa by requiring SSL on the Default Web Site, and creating another web site to do the redirect back to the SSL-enabled website. Remote PowerShell requires port 80 to be available on the Default Web Site. If you want to set up an automatic redirect to /owa and redirect http requests to https, you should follow the instructions located at http://technet.microsoft.com/en-us/library/aa998359(EXCHG.80).aspx and follow the directions under the section "For a Configuration in Which SSL is Required on the Default Web Site or on the OWA Virtual Directory in IIS 7.0". 2. The http binding on the Default Web Site has been modified, and the Hostname field configured. To correct this issue, you need to clear out the Hostname field under the port 80 bindings on the Default Web Site. Issue: 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'. In addition, you may see the following warning event in the System log: Source: Microsoft-Windows-WinRM EventID: 10113 Level: Warning Description: Request processing failed because the WinRM service cannot load data or event source: DLL="%ExchangeInstallPath%Bin\Microsoft.Exchange.AuthorizationPlugin.dll" Possible Causes 1. The ExchangeInstallPath variable may be missing. To check this, go to the System Properties, Environment variables, and look under the System variables. You should see a variable of ExchangeInstallPath with a value pointing to C:\Program Files\Microsoft\Exchange Server\V14\. 2. The Path of the Powershell virtual directory has been modified. The PowerShell virtual directory must point to th e \Program Files\Microsoft\Exchange Server\v14\ClientAccess\PowerShell directory or you will encounter problems. Issue: 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. For more information, see the about_Remote_Troubleshooting Help topic. Possible Causes: 1. Make sure the MSExchangePowerShellAppPool is running. If it is, try recycling the Application Pool and check for errors or warnings in the Event logs. 2. Make sure that the user that is trying to connect is Remote PowerShell Enabled (see the first error for details on how to check this). 3. Make sure WinRM is properly configured on the server. a. Run WinRM Quick Config on the server and ensure that both tests pass and no actions are required. If any actions are required, answer Yes to the prompt to allow the WinRM configuration changes to be made. b. Run WinRM enumerate winrm/config/listener and ensure that a listener is present for the HTTP protocol on port 5985 listening on all addresses. Issue: 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. Possible Causes: 1. The "Require SSL" option has been enabled on the PowerShell Virtual Directory. To resolve this, remove the "Require SSL" option from this Virtual Directory. The Exchange Management Tools connect over port 80, not 443, so if Require SSL is set, when a connection is attempted on port 80, IIS will return a 403 error indicating SSL is required. - Ben Winzenz, Solange Trombini
