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 SupportControlling Exchange ActiveSync device access using the Allow/Block/Quarantine list
What is the Allow/Block/Quarantine list? In Exchange 2010 we added a feature called the Allow/Block/Quarantine list (or ABQ for short). This feature was designed to help IT organizations control which of the growing number of Exchange ActiveSync-enabled devices are allowed to connect to their Exchange Servers. With this feature, organizations can choose which devices (or families of devices) can connect using Exchange ActiveSync (and conversely, which are blocked or quarantined). Some of you may remember my previous post on this topic dealing with organizations that do not have Exchange 2010 and thus I wanted to show you the far better way you can do this in Exchange 2010 (which is also what you will see in Office 365 and Exchange Online if you are looking at our cloud-based offerings). It is important to understand that the ABQ list is not meant to displace policy controls implemented using Exchange ActiveSync policies. Policy controls allow you to control and manage device features (such as remote wipe, PIN passwords, encryption, camera blocking, etc.) whereas the ABQ list is about controlling which devices are allowed to connect (for example, there may be a lot of devices that support EAS PIN policies, but some IT departments only want to allow certain devices to connect to limit support or testing costs). The easy takeaway is that Exchange ActiveSync policies allow you to limit device access by capabilities while the Allow/Block/Quarantine list allows you to control device access by device type. If you're curious as to what devices OS support which policies, the Wikipedia article we blogged about is a good place to look. Different device access models for different folks When we designed the ABQ list, we talked to a lot of organizations to find out how all of you use (or wanted to use) this kind of technology. What we realized is that there is a continuum of organizations; from permissive organizations that let employees connect whatever device they have to their Exchange Server, all the way to restrictive organizations that only support specific devices. Since we always want to make our software as flexible for IT as possible (as we know there are a lot of you folks that are using our software in a lot of different ways) we created this feature so that no matter which type of organization you are (or even if you are one that is in between these two extremes) we could help meet your needs. Below are some descriptions and "how-to"s for using the ABQ list in these different ways. The restrictive organization Restrictive organizations follow a more traditional design where only a set of supported devices is allowed to connect to the Exchange server. In this case, the IT department will only choose to allow the particular devices they support and all other devices are blocked. It's important to note that a restrictive organization is created by specifying a set of allowed devices and blocking the unknown. The permissive organization: Permissive organizations allow all (or most) to connect to their Exchange Server. In these cases, the ABQ list can help organizations block a particular device or set of devices from connecting. This is useful if there's a security vulnerability or if the device is putting a particularly heavy load on the Exchange server. In these cases, the IT department can identify the misbehaving device and block that device until a fix or update for that device brings it into compliance. All other devices, including the unknown devices, are given access. The one off case: Of course, if you are limiting the devices that connect to your organization, there's almost always a need for an exception. Whether it's testing a new device before rolling it out to the organization as a supported device, or an exception made for an executive, we wanted to give you the ability to make an exception without allowing all users with that device to access your organization's email and PIM data. When to quarantine: Quarantining devices is useful when an IT department wants to monitor new devices connecting to their organization. Both permissive and restrictive organizations may choose to employ this mechanism. In a permissive organization, quarantine can be used so that IT administrators know what devices, and which users, are making new connections. In restrictive organizations, this can be used to see who is trying to work around policy and also gauge demand from "Bring Your Own Device" (BYOD) users. Now that we've gone through the theory, let's talk about how we would do this in practice. Accessing the ABQ settings: Log in to the Exchange Control Panel (ECP) (you can also access the ECP from Outlook Web App (OWA) by selecting Options > See all options) In the ECP , make sure you are managing My Organization (#1 in the screenshot below). Be aware that most users won't see the "My Organization" option — it's only visible to users with Exchange Administrator access. Select Phone & Voice (#2 in the screenshot below) > ActiveSync Access tab (#3 in the screenshot below). This is the Allow/Block/Quarantine configuration screen. Note for all you Exchange Management Shell (EMS) gurus, you can also configure device access using PowerShell cmdlets if you prefer. Creating a device (or a family of devices) rule: To create a new rule, select New from the Device Access Rules section of the ABQ page (#5 in the screenshot above). When setting up a rule for a device, it is important to understand the difference between the "family" of the device and the specific device. This information is communicated as part of the EAS protocol and is reported by the device itself. In general, you can think of the deivce rule as applying only to the particular device type (like an HTC-ST7377 as shown in the image below) whereas a device family might be something more broad like "Pocket PC". This distinction between the specific (device type) and the general (device family) is important since many device manufacturers actually release the same device with different names on different carriers. To make it so that you don't have to make a separate rule for each device. For instance, the HTC Touch Pro was available on all four majour US carriers as well as some of the regional ones, and that's just the USA, not to mention the other versions around the world. As you can see, making a rule for each of those different devices (which are all in the same family and effectively the same device) could mean a lot of extra work for IT, so we added the family grouping to help you make good decisions about devices in bulk. It's important to note that when making a new rule you select the device family or the model but not both. Once you've selected the device or a device family, you can then choose what Exchange will do with that device (in this example, I'm just going to do a specific device). This brings you to the New Device Access Rule page. The easiest way to set the rule is to select Browse, which will show you a list of all the devices or device families that have recently connected to your Exchange Server. Once you've selected the device or family, you can choose the action to take. This is where you can choose to block the device if you are a permissive organization looking to limit a specific device for a specific reason or where you can set access rules if you are a restrictive organization (in such a case you would just create an allow rule for each supported device and then set the state for all unknown devices to block (we'll talk about how to set the action for unknown devices in the next section)). Once you select the action (Allow access, Block access, or Quarantine), click Save and you're done! You can repeat this process for each rule you want to create. You can also have both block and allow rules simultaneously. Setting up a rule for unknown devices: To access the rule for unknown devices, select Edit (#4 in Figure 5 above). On the Exchange ActiveSync Settings page, you can configure the action to take when Exchange sees a user trying to connect with a device that it does not recognize. By default, Exchange allows connections from all devices for users that are enabled for EAS . This example configures the Exchange organization to quarantine all unknown devices. This means that if there's no rule for the device (or device family) or if there's no exception for the particular user, then an unknown device will follow this behavior. Quarantine notifications We have the ability to specify who gets an email alert when a device is placed in quarantine. You can add one or more administrators (or users) or even a distribution group to this list of notified individuals. Anyone on this list will receive an email like the one shown in the screenshot below. The notification provides you information about who tried to connect the device, the device details and when the attempt was made. Custom quarantine message You can also set a custom message that will be delivered to the user in their Inbox and on their device. Although the device is in quarantine, we send this one message to the device so the user doesn't automatically call help desk because their device isn't syncing. The custom message is added to the notification email to the user that their device is in quarantine. The user and device will also now appear on the Quarantined Devices list on the ABQ configuration page. Managing Quarantined Devices The device will stay in quarantine until an administrator decides to allow or block the device in quarantine. This can be done by selecting the device and then clicking on the Allow or Block buttons in Quarantined Devices. This creates a personal exemption (the "one off case" mentioned earlier). If you wish to create an access rule that is to apply to all devices of the same family or model, you can select Create a rule for similar devices to open a new, prepopulated, rule. Making changes: Of course we realize that many organizations are dynamic and have changing requirements and policies. Any of the rules that have been set up can be changed dynamically by accessing the ABQ page in the ECP and editing, deleting, or adding the desired rule. Adam Glick (@MobileGlick) Sr. Technical Product Manager P.S. To read about Microsoft's licensing of Exchange ActiveSync, check out this article on Microsoft NewsCenter. Julia White also put up a more business focused blog in the UC Blog about the importance of EAS to Exchange 2010 customers.Improving Security - Together
For many years, client apps have used Basic Authentication to connect to servers, services and endpoints. It is enabled by default on most servers and services and it’s super simple to set up. Simplicity isn’t at all bad in itself, but Basic Authentication makes it easier for attackers to capture user’s credentials and so we’re taking steps to improve data security in Exchange Online.Supporting Windows 8 Mail in your organization
Windows 8 and Windows RT include a built-in email app named Mail (also referred to as Windows 8 Mail or the Windows 8 Mail app). The Windows 8 Mail app includes support for IMAP and Exchange ActiveSync (EAS) accounts. This article includes some key technical details of the Windows 8 Mail app. Use the information to help you support the use of Windows 8 Mail app in your organization. Read this article start to finish, or jump to the topic that interests you. Use the reference links throughout the article for more information. NOTE Mail, Calendar, People, and Messaging are apps that are built in to Windows 8 and Windows RT. Although this article discusses the Windows 8 Mail app, please note that much of the information in this article also applies to the Calendar, People, and Messaging apps. This is because, when connected to a server that supports Exchange ActiveSync, the Calendar, and People apps may also display data that was downloaded over the Exchange ActiveSync connection. Protocol Support The Windows 8 Mail app lets users connect to any service provider that supports either of the following two protocols: Exchange ActiveSync IMAP/SMTP POP is not currently supported. Exchange ActiveSync Exchange ActiveSync can be used to sync data for email, contacts, and calendar. The Windows 8 Mail app supports EAS versions 2.5, 12.0, 12.1, and 14.0. For detailed protocol documentation, see Exchange Sever Protocol Documents on MSDN. NOTE All Windows Communications apps (Mail, Calendar, and People) can use the data that is synchronized with Exchange ActiveSync. After a user connects to their account in the Windows 8 Mail app, their contacts and calendar data are available in the other Windows Communications Apps and vice versa. The Mail app does not support certificate-based authentication of clients for Exchange ActiveSync. IMAP/SMTP The Windows 8 Mail app supports the following IMAP and SMTP standards: IMAP4 rev1 RFC 3501 SMTP RFC 5321 IMAP4 IDLE command (push email) RFC 2177 IMAP LIST Extension for Special Folders RFC 6154 XLIST extension of the LIST command (identifies special folders). See Extension of the LIST command: XLIST in Google Apps Platform documentation. IMAP/SMTP can be used to send and receive email only. Contacts data and calendar data is not synchronized when IMAP/SMTP is used. Microsoft Exchange does not support Public Folders via IMAP. For more details about IMAP support in Exchange, see POP3 and IMAP4 (for Exchange 2010, see Understanding POP3 and IMAP4). Sync Configuration The Windows 8 Mail app can be configured to synchronize data at different times as follows: Push email (default) Polling at fixed intervals Manually If a push email connection can’t be established, it will automatically switch to poll at fixed intervals. Push Email Push email requires that accounts are either Exchange ActiveSync (which all support Push) or IMAP with the IDLE extension. Not all IMAP servers support IDLE, and it is supported only for the Inbox folder. When a push connection can’t be established, Mail will change to polling on 30 minute intervals. Push email on Exchange ActiveSync requires that HTTP connections must be maintained for up to 60 minutes, and IMAP IDLE requires TCP connections to be maintained for up to 30 minutes. Account Setup Features Windows 8 and Windows RT users can add email accounts to the Windows 8 Mail app using the Settings charm. The Settings charm is always available on the right side of the Windows 8 and Windows RT screen. (For more visual details about Charms & the Windows 8 user interface, see Search, share & more.) NOTE This section provides an overview of Windows 8 Mail app account setup. For step-by-step procedures for setting up an account in the Windows 8 Mail app, see What else do I need to know? at the end of this guide. To make it as easy as possible to add accounts, account setup only prompts the user to enter the email address and password for the account they want to set up. From that data, Mail attempts to automatically configure the account as follows: The domain portion of the email address is matched against a database of well-known service providers. If it’s a match, its settings are automatically configured. The domain portion of the email address is used to execute Exchange ActiveSync Autodiscover processes. For detailed information, see Autodiscover HTTP Service Protocol Specification on MSDN. If still not configured, the user is prompted to provide detailed settings for their server. Exchange ActiveSync Figure 1: Exchange ActiveSync (EAS) configuration in Windows Mail Full details needed to connect to an Exchange server – needed only if Autodiscover failed The information required to connect to a server via Exchange ActiveSync is: Email address Server address Domain Username Password IMAP/SMTP Figure 2: IMAP/SMTP configuration in Windows Mail The information required to connect to a server via IMAP/SMTP is: Email address Username Password IMAP email server IMAP SSL (if your IMAP server requires SSL encryption) IMAP port SMTP email server SMTP SSL (if your SMTP server requires SSL encryption) SMTP port Whether SMTP server requires authentication Whether SMTP uses the same credentials as IMAP (If not, user must also provide SMTP credentials) Security Features Mail provides administrators with some level of security through Exchange ActiveSync policies. It doesn’t support any means of managing or securing PCs that are connected via IMAP. Policy Support Exchange ActiveSync devices can be managed using Exchange ActiveSync policies. Windows 8 Mail supports the following EAS policies. : Password required Allow simple password Minimum password length (to a maximum of 8 characters) Number of complex characters in password (to a maximum of 2 characters) Password history Password expiration Device encryption required (on Windows RT and editions of Windows that support BitLocker. See What's New in BitLocker for details about BitLocker improvements in Windows 8.) Maximum number of failed attempts to unlock device Maximum time of inactivity before locking Note that if AllowNonProvisionableDevices is set to false in an EAS policy and the policy contains settings are not part of this list, the device won’t be able to connect to the Exchange server. Getting into Compliance Most of the policies listed above can be automatically enabled by Mail, but there are certain cases where the user has to take action first. These are: Server requires device encryption: User has a device that supports BitLocker but BitLocker isn’t enabled. User must manually enable BitLocker. User has a Windows RT device that supports device encryption but it is suspended. User must reboot. User has a Windows RT device that supports device encryption, but it isn’t enabled. User must sign into Windows with a Microsoft account. An admin on this PC doesn’t have a strong password: All admin accounts must have a strong password before continuing. The user’s account doesn’t have a strong password: User must set a strong password before continuing. ActiveSync Policy v/s Group Policy on domain-joined Windows 8 devices If a Windows 8 PC is joined to an Active Directory domain and controlled by Group Policy, there may be conflicting policy settings between Group Policy and an Exchange ActiveSync policy. In the event of any conflict, the strictest rule in either policy takes precedence. The only exception is password complexity rules for domain accounts. Group policy rules for password complexity (length, expiry, history, number of complex characters) take precedence over Exchange ActiveSync policies – even if group policy rules for password complexity are less strict than Exchange ActiveSync rules, the domain account will be deemed in compliance with Exchange ActiveSync policy. Remote Wipe Mail supports the Exchange ActiveSync remote wipe directive, but unlike Windows Phones, the data deleted by this directive is scoped to the specified Exchange ActiveSync account. The user's personal data is not deleted. For example, if a user has an Outlook.com account for personal use and a Contoso.com account for work use, a remote wipe directive from the Contoso.com server would impact Windows 8 and Windows Phone 7 as follows: Data Windows Phone 7 Windows 8 Mail Contoso.com email Deleted Deleted Contoso.com contacts Deleted Deleted Contoso.com calendars Deleted Deleted Outlook.com email Deleted Not deleted Outlook.com contacts Deleted Not deleted Outlook.com calendars Deleted Not deleted Other documents, files, pictures, etc. Deleted Not deleted Account Roaming To make it as easy as possible for users to have all of their accounts set up on all of their devices, Windows 8 uploads vital account information to the user’s Microsoft account. This information includes email address, server, server settings, and password. When a user signs into a new PC with their Microsoft account, their email accounts are automatically set up for them. Passwords are not uploaded from a PC for any accounts which are controlled by any Exchange ActiveSync policies. Users will have to enter their password to begin syncing a policy-controlled account on a new PC. Microsoft Accounts Users are required to have a Microsoft Account, formerly known as Windows Live ID, to use the Windows Communications apps. This will usually be the Microsoft account that the user is signed into Windows with, but if they have not done so, they will be prompted to provide one before proceeding. Microsoft accounts will automatically sync to Microsoft services using Exchange ActiveSync 14.0 when Mail starts. This will synchronize: Email, if the user’s Microsoft account is also their Hotmail or Outlook.com account Contacts from Windows Live Calendar events If the user’s Microsoft account is not a Outlook.com or Hotmail account (for example, dave@contoso.com), Mail will prompt the user to provide the password for their email account, which will be added automatically. Data Consumption By default, Mail only downloads the last two weeks of email. This is user configurable and can potentially download the user’s entire mailbox. For Exchange ActiveSync accounts, all contacts are downloaded and calendar events are downloaded only for three months behind the current date and 18 months ahead. Additionally, messages are only partially downloaded to reduce bandwidth use as follows: Message bodies are truncated to the first 100KB (20KB on metered networks). For more details see Engineering Windows 8 for mobile networks. Attachments are not downloaded automatically. Embedded images in email messages are downloaded on-demand as the user reads them, and attachments are downloaded on-demand as the user attempts to open them. By default, Mail only downloads the user’s Inbox and Sent folders. Other folders are downloaded once the user accesses them for the first time. Mail does not enforce any limits on how many or large of attachments users can send. Limitations The following features are currently not supported by Mail: Mailbox connections using POP : IMAP and EAS are supported. (Note, this does not mean that Windows 8 does not support POP3. This post is about the Windows 8 Mail app. ) Servers that require self-signed certificates: Users can work around the self-signed certificate limitation by manually installing the certificate on their Windows 8 or Windows RT device. For additional information about the self-signed certificates, see Self-Signed Certificates section below. Opaque-Signed and Encrypted S/MIME messages: When S/MIME messages are received in Windows 8 Mail, it displays an email item with a message body that begins with “This encrypted message can’t be displayed.” To view email items in the S/MIME format, users must open the message using Outlook Web App, Microsoft Outlook, or another email program that supports S/MIME messages. For more information, see Opaque-Signed and Encrypted S/MIME Message on MSDN. Self-Signed Certificates Users may experience connectivity errors when trying to connect to an Exchange servers that require self-signed certificates. The user may receive the following error messages. Unable to connect. Ensure the information entered is correct. <Email address> is unavailable NOTE This issue may occur because the Mail app cannot connect to Exchange by using self-signed certificates. Consider the following options to resolve this issue. Option 1: Install a certificate that is signed by a Microsoft-trusted root certification authority (CA) on the server This enables Exchange to work for all clients without prompting. For more information about the trust root CAs, see the following topics on TechNet: Windows Root Certificate Program overview Windows Root Certificate Program - Members List (All CAs) Option 2: Install a server’s self-signed certificate on a device This enables Exchange to work for Windows 8 devices that have the certificate installed. Note To install a self-signed certificate for a domain’s certification authority, the administrator must provide a certificate file (.cer). The certificate can be installed to the trusted root certificate authority store for either of the following options: For the current user This option does not require admin rights but must be completed for each user on the device. For the local device This option requires administrator rights and needs to be done only one time for a device. The user or the system administrator can use the .cer file to install the certificate. To do this, use one of the following methods: Command-line tool At an elevated command prompt, run the following command: certutil.exe -f -addstore root <name_of_certificatefile>.cer NOTE The command installs the certificate for all users on the device. User interface Double-click the certificate file. A certificate dialog opens. Click Install Certificate. A Certificate Import Wizard window opens. Select the option to install the certificate for only the current user or for the local device. Select Place all certificates in the following store Click Browse to open the store selection dialog. Select Trusted Root Certification Authorities. Select the store, and then click Ok. You are returned to Certificate Import Wizard dialog, and the certificate store and certificate to be installed into that store are displayed. Troubleshooting Windows 8 Mail Client Connectivity If Windows 8 Mail users can't successfully connect to their accounts, consider the following: Verify that the user is using the latest version of the Windows 8 Mail app. A user can check for updates to the Windows 8 Mail app by doing the following: from the Start screen, go to Store > Settings > App updates > Check for updates. The user should wait a few minutes and try again. If the account is a cloud-based email account that requires registration (for example, a Microsoft Office 365 account), the user must register their account before they can set up their account in Windows 8 Mail. If the user is a Microsoft Office 365 user, they register their account when they sign in to Office 365 for the first time. If the user is not an Office 365 user, the user registers their account when they sign in to their account using Microsoft account or Outlook Web App. TIP The user will see the following message if they haven't registered their account. In Windows 8 Mail, you will see the following message: “We couldn’t find the settings for. Provide use with more info and we’ll try connecting again.” For information about signing into Outlook Web App or the Office 365 Portal, see Sign In to Outlook Web App. After the user signs in to your account using Outlook Web App, the user should sign out, and then try to connect using Windows 8 Mail. What else do I need to know? Set up email in Windows 8 Mail Mail: Frequently asked questions 2784275 How to configure an Exchange account and how to troubleshoot Exchange account connectivity issues in the Mail app in Windows 8 and Windows RT 2792112 80070057 error, and Windows Phone 8 cannot sync with Microsoft Exchange 2464593Error 85010013, 8600C2B, or 86000C29 when you try to synchronize a Windows Phone-based device to an Exchange server You may also find Building the Mail app on the Building Windows 8 blog of interest. Updates 11/26/2012: Updated info about AllowNonProvisionableDevices setting in EAS policies. 11/27/2012: Added links to EAS policy documentation. 11/27/2012: Added info about Public Folder support in IMAP and link to IMAP documentation. 12/3/2012: Added link to Building the Mail app on the Building Windows 8 blog. 12/21/2012: Added links to KB 2784275, 2792112 and 2464593. 2/20/2013: Added note about Certificate-base authentication of clients for Exchange ActiveSync not being supported.Configure certificate-based authentication for Exchange ActiveSync
Update: Exchange Server 2013 Cumulative Update 5 and later supports certificate-based authentication with ActiveSync. Note: For official documentation on this subject, please go to this page on TechNet. In previous posts, we have discussed certificate based authentication (CBA) for Outlook Web App, and Greg Taylor has covered publishing Outlook Web App and Exchange ActiveSync (EAS) with certificate based authentication using ForeFront TMG in this whitepaper. Certificate based authentication for OWA only can also be accomplished using ForeFront Unified Access Gateway. In this post, we will discuss how to configure CBA for EAS for Exchange 2010 in deployments without TMG or UAG . To recap some of the common questions administrators and IT decision-makers have regarding CBA: What is certificate based authentication? CBA uses a user certificate to authenticate the user/client (in this case, to access EAS ). The certificate is used in place of the user entering credentials into their device. What certificate based authentication is not: By itself, CBA is not two-factor authentication. Two-factor authentication is authentication based on something you have plus something you know. CBA is only based on something you have. However, when combined with an Exchange ActiveSync policy that requires a device PIN, it could be considered two-factor authentication. Why would I want certificate based authentication? By deploying certificate based authentication, administrators gain more control over who can use EAS . If users are required to obtain a certificate for EAS access, and the administrator controls certificate issuance, access control is assured. Another advantage: Because we're not using the password for authentication, password changes don't impact device access. There will be no interruption in service for EAS users when the they change their password. Things to remember: There will be added administration overhead. You will either need to stand up your own internal Public Key Infrastructure (PKI) using Active Directory Certificate Services (AD CS, formerly Windows Server Certificate Services) or a 3rd-party PKI solution, or you will have to purchase certificates for your EAS users from a public certification authority (CA). This will not be a one-time added overhead. Certificates expire, and when a user’s certificate expires, they will need a new one, requiring either time invested in getting the user a new certificate, or budget invested in purchasing one. Prerequisites: You need access to a CA for client certificates. This can be a public CA solution, individual certificates from a vendor, or an Active Directory Certificate Services solution. Regardless, the following requirements must be met: The user certificate must be issued for client authentication. The default User template from an AD CS server will work in this scenario. The User Principal Name (UPN) for each user account must match the Subject Name field in the user's certificate. All servers must trust the entire CA trust chain. This chain includes the root CA certificate and any intermediate CA certificates. These certificates should be installed on all servers that may require them, to include (but not limited to) ISA/TMG/UAG server(s) and the Client Access Server (CAS). The root CA certificate must be in the Trusted Root Certification Authorities store, and any intermediate CA certificates in the intermediate store on all of these systems. The root CA certificate, and intermediate CA certificates must also be installed on the EAS device. The user’s certificate must be associated with the user’s account in Active Directory Client Access Server Configuration To configure the Client Access server to enforce CBA : 1. Verify if Certificate Mapping Authentication is installed on the server. Right click on Computer in the start menu and choose Manage. Expand Roles and click on Web Server (IIS) Scroll down to the Role Services section. Under the Security section you should see Client Certificate Mapping Authentication installed. If you don't see Client Certificate Mapping Authentication installed, click add Role Services > (scroll) Security and select Client Certificate Mapping Authentication and then click Install. Reboot your server. 2. Enable Active Directory Client Certificate Authentication for the server root in IIS. Start IIS Manager Click on the Server Name. Double click Authenticationin the middle pane. Right click on Active Directory Client Certificate Authentication and select Enable When this is complete, restart the IIS Admin service from the Services console (or use Restart-Service IISAdmin"from the Shell). Important: IISreset does not pick up the changes properly. You must restart this service. 3. Require Client Certificates in Exchange management console. In the Exchange Management Console, expand Server Configuration and then select the Client Access server you want to configure On the Exchange ActiveSync tab, right click on the Microsoft-Server-ActiveSync directory and choose Properties. On the Authenticationtab: Clear the Basic authentication (password is sent in clear text) checkbox Select Require client certificates 4. Modify the ActiveSync XML configuration file to allow Client Certificate Mapping Authentication. In IIS manager open the configuration editor under the Microsoft-Server-ActiveSync directory. Browse the option for clientCertificateMappingAuth and set the value to True Once this is configured, all that's left to do is client configuration. Client Configuration You'll need to get the user’s certificate to the device. This will be accomplished in different ways for different devices. Some possibilities include: Make the Trusted Root Certification Authority (Root CA) certificate available on a web site or other means of distribution. Make the user’s certificate, including the private key, available on a website or other means of distribution. Caution: Use appropriate security measures to ensure that only the user who owns the certificate is able to access it from the device. If the device supports external storage, you can place the certificate on a memory card or other external storage device and install it from the card. Some devices have a certificate manager available for a host operating system. You can plug the device into your computer, run the certificate manager and install the certificate. Once the certificate is on the device, the user can configure the Exchange ActiveSync client (usually a mail app) on the device. When configuring EAS for the first time, users will be required to enter their credentials. When the device communicates with the Client Access Server for the first time, users will be prompted to select their certificate. After this is configured, if users check the account properties, they'll see a message similar to the following: Microsoft Exchange uses certificates to authenticate users when they log on. (A user name and password is not required.) Exchange Server 2003 Mailbox Coexistence This is an added step that requires some simple changes, and must be performed whether TMG is used to access Exchange 2010 or not. Use the following steps to enable this for access to Exchange 2003 mailboxes. Apply the hotfix from the following article (or one that has a later version of EXADMIN.DLL) to the Exchange 2003 servers where the mailboxes are homed.937031 Event ID 1036 is logged on an Exchange 2007 server that is running the CAS role when mobile devices connect to the Exchange 2007 server to access mailboxes on an Exchange 2003 back-end server The article instructs you to run a command to configure IIS to support both Kerberos and NTLM. You must run the command the command prompt using CSCRIPT, as shown below: Click Start > Run > type cmd and press Enter. Type cd \Windows\System32\AdminScripts and press Enter. Type the following command and press enter: cscript adsutil.vbs set w3svc/WebSite/root/NTAuthenticationProviders "Negotiate,NTLM" On the Exchange 2003 mailbox server, launch Exchange System Manager and follow these steps: Expand the Administrative Group that contains the Exchange 2003 server. Expand Servers > expand <server name> > Protocols > HTTP Exchange Virtual Server Right click the Microsoft-Server-ActiveSync virtual directory and select Properties On the Access tab, click Authentication and ensure that only Integrated Windows Authentication checkbox is checked. Use the following steps to configure the Exchange 2010 to Exchange 2003 communication for Kerberos Constrained Delegation (KCD). Open Active Directory Users and Computers on the CAS Right click the CAS computer account > Properties In the Delegation tab, select Trust this computer for delegation to specified services only Select Use any authentication protocol option and then click Add In the Add Services window, click Users or Computers and enter the name of the Exchange 2003 server that the CAS is delegating to Click OK A list of Service Principal Names (SPN) will be displayed for your server. Select the appropriate HTTP SPN for the Exchange 2003 server. You'll need to add the correct SPN, HTTP/serverFQDN Note: You may need to add the SPN as per Setspn Overview Thanks to: DJ Ball for his previous work in documenting certificate based authentication for Outlook Web App (see How to Configure Certificate Based Authentication for OWA - Part I and How to Configure Certificate Based Authentication for OWA - Part II Mattias Lundgren, for starting the documentation process on certificate based authentication for EAS . DJ Ball and Will Duff for reviewing this document. Henning Peterson and Craig Robicheaux for reviewing this document. Greg Taylor for technical review. Jeff MillerSupporting Windows Mail 8.1 in your organization
Windows 8.1 and Windows RT include a built-in email app named Windows Mail. Mail includes support for IMAP and Exchange ActiveSync (EAS) accounts. This article includes some key technical details of Windows Mail in Windows 8.1. (See Supporting Windows 8 Mail in your organization for Windows 8.0.) Use the information to help you support the use of Mail in your organization. Read this article start to finish, or jump to the topic that interests you. Use the reference links throughout the article for more information. NOTE Mail, Calendar, and People apps run on Windows 8.1 and Windows RT. Although this article discusses the Mail app, please note that much of the information in this article also applies to the Calendar, and People apps. When connected to a server that supports Exchange ActiveSync, the Calendar, and People apps may also display data that was downloaded over the Exchange ActiveSync connection. Protocol Support Mail lets users connect to any service provider that supports either of the following two protocols: Protocol Protocol versions & standards Functionality Exchange ActiveSync (EAS) EAS 2.5 EAS 12.0 EAS 12.1 EAS 14.0 EAS 14.1 Send and receive email Sync email, contacts & calendar ActiveSync Policies Remote Wipe IMAP + SMTP IMAP4 rev1 RFC 3501 SMTP RFC 5321 IMAP4 IDLE command (push email) RFC 2177 IMAP LIST Extension for Special Folders RFC 6154 XLIST extension of the LIST command (identifies special folders). Send and receive email only Contacts and calendar data not synchronized Microsoft Exchange does not support Public Folders via IMAP. See IMAP support in Exchange 2013. Post Office Protocol (POP) is not supported. NOTE All Windows Communications apps (Mail, Calendar, and People) can use the data that is synchronized using Exchange ActiveSync. After a user connects to their account in the Mail app, their contacts and calendar data is available in the other Windows Communications Apps and vice versa. Sync Configuration Mail can be configured to synchronize data at different times as follows: Push email (default) Polling at fixed intervals Manually If a push email connection can’t be established, it will automatically switch to poll at fixed intervals. Push Email Push email requires that accounts are either Exchange ActiveSync (which all support Push) or IMAP with the IDLE extension. Not all IMAP servers support IDLE, and it is supported only for the Inbox folder. When a push connection can’t be established, Mail will change to polling on 30 minute intervals. Push email on Exchange ActiveSync requires that HTTP connections must be maintained for up to 60 minutes, and IMAP IDLE requires TCP connections to be maintained for up to 30 minutes. Account Setup Features Windows 8.1 and Windows RT users can add email accounts to Mail using the Settings charm. The Settings charm is always available on the right side of the Windows 8.1 and Windows RT screen. (For more visual details about Charms & the Windows 8.1 user interface, see Search, share, print & more.) NOTE This section provides an overview of account setup in Mail. For step-by-step procedures for setting up an account, see What else do I need to know? at the end of this guide. To make it as easy as possible to add accounts, account setup only prompts the user to enter the email address and password for the account they want to set up. From that data, Mail attempts to automatically configure the account as follows: The domain portion of the email address is matched against a database of well-known service providers (such as Outlook.com). If it’s a match, its settings are automatically configured. The domain portion of the email address is used to discover the user's email settings using the Autodiscover. If automatic configuration fails, the user is prompted for additional details such as an email server name and domain name. Add an Exchange ActiveSync account Figure 1: Exchange ActiveSync (EAS) configuration in Windows Mail If automatic configuration fails, the following additional information is required to connect to a server via Exchange ActiveSync: Server address Domain Username Add an IMAP/SMTP account Figure 2: IMAP/SMTP configuration in Windows Mail The information required to connect to a server via IMAP/SMTP is: Email address Username Password IMAP email server IMAP SSL (if your IMAP server requires SSL encryption) IMAP port SMTP email server SMTP SSL (if your SMTP server requires SSL encryption) SMTP port Whether SMTP server requires authentication Whether SMTP uses the same credentials as IMAP (If not, user must also provide SMTP credentials) Security Features Mail provides administrators with some level of security through Exchange ActiveSync policies (Mobile Device Mailbox Policies in Exchange 2013). It doesn’t support any means of managing or securing PCs that are connected via IMAP. EAS includes support for certificate-based authentication and remote wipe. Exchange ActiveSync Policy Support Exchange ActiveSync devices can be managed using Exchange ActiveSync policies. Mail supports the following EAS policies. : Password required Allow simple password Minimum password length (to a maximum of 8 characters) Number of complex characters in password (to a maximum of 2 characters) Password history Password expiration Device encryption required (on Windows RT and editions of Windows that support BitLocker. See What's New in BitLocker for details about BitLocker improvements in Windows 8.1.) Maximum number of failed attempts to unlock device Maximum time of inactivity before locking Important If AllowNonProvisionableDevices is set to false in an EAS policy and the policy contains settings that are not part of this list, the device won’t be able to connect to the Exchange server. Getting into Compliance Most of the policies listed above can be automatically enabled by Mail, but there are certain cases where the user has to take action first. These are: Server requires device encryption: User has a device that supports BitLocker but BitLocker isn’t enabled. User must manually enable BitLocker. User has a Windows RT device that supports device encryption but it is suspended. User must reboot. User has a Windows RT device that supports device encryption, but it isn’t enabled. User must sign into Windows with a Microsoft account. An admin on this PC doesn’t have a strong password: All admin accounts must have a strong password before continuing. The user’s account doesn’t have a strong password: User must set a strong password before continuing. Windows 8 Picture Passwords and ActiveSync Policy If a Windows 8.x user uses a picture password and Exchange ActiveSync policy requires a password, the user will still need to create and enter a password in accordance with the policy. ActiveSync Policy v/s Group Policy on domain-joined Windows 8.1 devices If a Windows 8.1 PC is joined to an Active Directory domain and controlled by Group Policy, there may be conflicting policy settings between Group Policy and an Exchange ActiveSync policy. In the event of any conflict, the strictest rule in either policy takes precedence. The only exception is password complexity rules for domain accounts. Group policy rules for password complexity (length, expiry, history, number of complex characters) take precedence over Exchange ActiveSync policies – even if group policy rules for password complexity are less strict than Exchange ActiveSync rules, the domain account will be deemed in compliance with Exchange ActiveSync policy. Certificate-Based Authentication Communications applications can connect to a corporate Exchange service configured to require certificate-based authentication. User authentication certificates can be provisioned to Windows 8.1 devices by administrators or end-users can browse to certificate and install to user certificate storage. User can add and connect an email account using a certificate. (For account setup, password entry is required per standard account setup.) User may be prompted to give the Mail application permission to access their user certificate, and should accept the prompt to enable certificate usage. In cases where multiple certificates are available, the user can go to account Settings to select the desired certificate. Non-PIN protected software certificates are supported. Remote Wipe Mail supports the Exchange ActiveSync remote wipe directive, but unlike Windows Phone (which deletes all data on the device), Mail scopes the data deleted to the specified Exchange ActiveSync account for which the remote wipe command is issued. The user's personal data is not deleted. Additionally, attachments saved from that account are made inaccessible. For example, if a user has an Outlook.com account for personal use and a Contoso.com account for work use, a remote wipe directive from the Contoso.com server would impact Windows 8.1 and Windows Phone 7 as follows: Data Windows Phone 7 Windows 8.1 Mail Contoso.com email Deleted Deleted Contoso.com contacts Deleted Deleted Contoso.com calendars Deleted Deleted Contoso.com attachments Deleted Not deleted, but not accessible Outlook.com email Deleted Not deleted Outlook.com contacts Deleted Not deleted Outlook.com calendars Deleted Not deleted Outlook.com attachments Deleted Not deleted Other documents, files, pictures, etc. Deleted Not deleted Account Roaming To make it as easy as possible for users to have all of their accounts set up on all of their devices, Windows 8.1 uploads vital account information to the user’s Microsoft account. This information includes email address, server, server settings, and password. When a user signs into a new PC with their Microsoft account, their email accounts are automatically set up for them. Passwords are not uploaded from a PC for any accounts which are controlled by any Exchange ActiveSync policies. Users will have to enter their password to begin syncing a policy-controlled account on a new PC. If using client certificate authentication, the client certificate, and the certificate selection for an account will not be roamed. Users will have to select their desired client certificate to begin syncing a client certificate account on a new PC. Microsoft Accounts By default, users are required to have a Microsoft account, formerly known as Windows Live ID, to use the Windows Communications apps. This will usually be the Microsoft account that the user is signed into Windows with, but if they have not done so, they will be prompted to provide one before proceeding. If the Microsoft account is… Mail will… Outlook.com or Hotmail account Automatically sync email, Calendar and Contacts using Exchange ActiveSync Not an Outlook.com or Hotmail account (for example, dave@contoso.com) Prompt the user to provide password for their email account Can my organization remove the requirement for a Microsoft account? You can apply a Group Policy to a device to make a Microsoft Account optional for the Windows Communications apps. Note, the Group Policy setting is configured in Computer Configuration node in the Group Policy and applies to all users of the computer/device to which it's applied. The policy setting lets you control whether Microsoft accounts are optional for Windows Store apps that require an account to sign in. This policy only affects Windows Store apps that support it. Windows RT devices can use Local Group Policy. To apply the Group Policy setting: Launch GPEdit by opening the “run” prompt (Windows key + r), and entering GPEdit.msc Go to Computer Configuration > Administrative Templates > Windows Components > App runtime Select Allow Microsoft accounts to be optional to configure the policy If the Group Policy is applied and a Microsoft account is not used, the Communications apps will: Prompt the user for a work account (i.e. an Exchange ActiveSync account) password If account credentials are provided, use Exchange ActiveSync to synchronize email, Contacts and Calendar from the work account A user can add additional accounts if desired. You can use corporate firewalls or other mechanisms to block access to any consumer email services as needed. The following functionality will be unavailable to a user without a Microsoft Account: Windows Store Application Installs Account Settings roaming to additional devices Connectivity to additional 3rd party services (e.g. Social sites) Email communication from Microsoft regarding any updates to Microsoft Services Agreement. Data Consumption By default, Mail only downloads one month of email (up from 2 weeks in Windows 8.0). This is user configurable and can potentially download the user’s entire mailbox. For Exchange ActiveSync accounts, all contacts are downloaded and calendar events are downloaded only for three months behind the current date and 18 months ahead. Additionally, messages can be only partially downloaded to reduce bandwidth use as follows: Content On unmetered networks On metered networks Message bodies Truncated to the first 100KB or 20KB depending on folder and device conditions Truncated to the first 20KB. For more details see Engineering Windows 8 for mobile networks. Attachments Some attachments are downloaded automatically when device conditions allow. Attachments for messages in junk folder are not downloaded automatically. Never downloaded automatically. Embedded images in email messages are downloaded on-demand as the user reads them, and attachments which are not downloaded can be downloaded on-demand as the user attempts to open them. Mail downloads all folders for an account. Users can configure the period of email which is downloaded to adjust the size of data for an account. Mail does not enforce any limits on number and size of attachments users can send. Automatic Replies Mail allows users to view and set their automatic reply messages (aka Out of Office or OOF messages). There is a visual indication when auto-reply is enabled. Users can view and set automatic reply plain text content. For corporate accounts, separate internal and external auto-reply messages are supported. There is no date/time support for specifying start or end time for automatic replies. Enterprise Connectivity Authenticated Proxies The communications applications can connect over LAN or WiFi connections via authenticated proxies which use standard authentication methods including: NTLM, Digest, Negotiate, and Basic authentication. Any user credentials entered can be cached for the session, or remembered persistently. Self-Signed Certificates The communications applications warn the user with a prompt providing an option to connect anyway when trying to connect to services with common service certificate issues. See Self-Signed Certificates in Limitations below for details and recommendations. Limitations The following features are currently not supported by Mail: Direct mailbox connections using POP: Only EAS and IMAP protocols are supported. Note This does not mean that Windows 8.1 does not support POP . This post is about the Mail app. See Using email accounts over POP on Windows 8.1 and Windows RT 8.1 for workarounds. Opaque-Signed and Encrypted S/MIME messages When S/MIME messages are received in Mail, it displays an email item with a message body that begins with “This encrypted message can’t be displayed.” To view email items in the S/MIME format, users must open the message using Outlook Web App, Microsoft Outlook, or another email program that supports S/MIME messages. For more information, see Opaque-Signed and Encrypted S/MIME Message on MSDN. Self-Signed Certificates in Windows Mail 8.1 Users may experience connectivity errors when trying to connect to an Exchange server that uses a self-signed certificate or a certificate with other common issues. The user may receive the following error message. There’s a problem with a server’s security certificate. It might not be safe to connect to the server because… <details>. You can use one of the following options to resolve this issue. To resolve issue with self-signed certificates… Use this option if… Install a certificate signed by a trusted certification authority (CA) on the server You want Exchange to work for all clients without prompting You do not want your users to ignore or bypass certificate-related errors You want to avoid installing a self-signed certificate or a certificate signed by an untrusted CA on all devices Install the server’s self-signed certificate on the device You want to save the cost of a certificate signed by a trusted CA You want Exchange to work from Windows 8.1 devices that have the self-signed certificate installed. Instruct users to ignore common certificate issues You want to avoid the cost of a CA-signed certificate or do not want to install the server’s self-signed certificate on all devices Users are knowledgeable about certificate-related errors At the prompt, users can connect anyway to ignore common service certificate issues such as self-signed certificates, allowing the communications applications to use an encrypted connection to the email service with the certificate issue. If users choose to connect anyway and ignore the service certificate issues, their selection will be remembered, (can be viewed and changed any time via Settings for account). We recommend that users select Cancel when they receive a certificate-related error and contact the administrator to fix the issue (option 1). See Digital Certificates and SSL for more information. Install a server’s self-signed certificate on the device This enables Exchange to work for Windows 8.1 devices that have the certificate installed. Note The administrator must provide a certificate file (.cer). The certificate can be installed to the trusted root certificate authority store for either of the following options: For the current user This option does not require admin rights but must be completed for each user on the device. For the local device This option requires administrator rights and needs to be done only one time for a device. The user or the system administrator can use the .cer file to install the certificate. To do this, use one of the following methods: Use the command-line At an elevated command prompt, run the following command: certutil.exe -f -addstore root.cer NOTE The command installs the certificate for all users on the device. Use the Certificate Import Wizard Double-click the certificate file. A certificate dialog opens. Click Install Certificate. A Certificate Import Wizard window opens. Select the option to install the certificate for only the current user or for the local device. Select Place all certificates in the following store Click Browse to open the store selection dialog. Select Trusted Root Certification Authorities. Select the store, and then click Ok. You are returned to Certificate Import Wizard dialog, and the certificate store and certificate to be installed into that store are displayed. Troubleshooting Mail Client Connectivity If a Mail user can't successfully connect to an account, consider the following: Verify that the user is using the latest version of the Mail app. A user can check for updates to the Mail app by doing the following: from the Start screen, go to Store > Settings > App updates > Check for updates. To rule out any transient issues, the user can wait a few minutes and try again. Some cloud-based email services (for example, Microsoft Office 365) require that the user register their account before they can use email clients such as Mail. Office 365 users register their account when they sign in to the service for the first time. If the user is not an Office 365 user, the user registers their account when they sign in to their account using their Microsoft account or sign in to Outlook Web App. The user must sign out of Outlook Web App before they try to connect using Mail again. TIP The user will see the following message if they haven't registered their account: “We couldn’t find the settings for. Provide us with more info and we’ll try connecting again.” What else do I need to know? Set up your Office 365 or Exchange-based email in Windows 8 Mail Mail app for Windows: FAQs 2784275 How to configure an Exchange account and how to troubleshoot Exchange account connectivity issues in the Mail app in Windows 8 and Windows RT 2792112 80070057 error, and Windows Phone 8 cannot sync with Microsoft Exchange 2464593 Error 85010013, 8600C2B, or 86000C29 when you try to synchronize a Windows Phone-based device to an Exchange server You may also find Building the Mail app and Right from the Start: Delivering the best email experience on any tablet with Windows 8.1 on the Building Windows 8 blog of interest. Updates 10/21/2013: Added note about Windows 8.x picture passwords and Exchange ActiveSync policies. 10/21/2013: Added link to Using email accounts over POP on Windows 8.1 and Windows RT 8.1.Exchange ActiveSync client connectivity in Office 365
Update: 4/23/2012: Microsoft has completed deployment of the interim solution that should eliminate the need for manual server reconfiguration of the affected devices when your Office 365 server location changes. We continue to work with device manufacturers to help them resolve their Exchange ActiveSync protocol implementation issues. Update 3/5/2012: In order to mitigate issues with some mobile device implementations of redirection, Microsoft is currently deploying an interim solution that should eliminate the need for manual server reconfiguration of the affected devices when your Office 365 server location changes. We estimate that the fix will be fully deployed worldwide by April 30th, 2012. Look for the announcement on the blog when the fix is fully deployed with instructions for reconfiguring affected devices. In the meantime, we continue to work with device manufacturers to help them resolve their Exchange ActiveSync protocol implementation issues. This article explains how mobile devices connect to Exchange Online (Office 365) service and how the connectivity may be impacted if the device does not support certain Exchange ActiveSync (EAS) protocol requirements. Exchange ActiveSync protocol versions Most mobile devices that connect to Exchange do so using the Exchange ActiveSync protocol. Each successive version of the protocol offers new capabilities. (The Exchange ActiveSync article maintained by the Exchange community on Wikipedia has more details. -Editor) Before any device accesses an Exchange mailbox, it negotiates with the Exchange server to determine the highest protocol version that they both support, and then uses this protocol version to communicate. Through the protocol version negotiation, the device and the server agree to behave in a particular manner in accordance with the version selected. Mailbox redundancy in Office 365 In Office 365, we store multiple copies of user mailboxes, geographically distributed across different sites and datacenters. This redundancy ensures that if one copy of the mailbox fails for some reason (for example due to a hardware failure on a particular server), we can access the same mailbox elsewhere. At any given time, one copy of a particular mailbox is considered active and the remaining ones are deemed passive. When a user connects to their mailbox, they take actions on the active copy, and changes are then propagated to its passive copies. Mailbox database failover The switch from one active copy of a mailbox to another one stored on a different mailbox server may happen for the following different reasons: Fail over If hardware or connectivity failures arise in a site, Exchange 2010 in Office 365 automatically switches (or fails over) to a different mailbox database to ensure continuous access to your mailboxes. Load balancing If some servers are experiencing higher loads, mailboxes may need to be load-balanced across different servers. Testing or maintenance Mailbox databases may be switched when we are testing our disaster recovery procedures, or when servers are upgraded. In most cases, the fail over and load balancing are not scheduled in advance. The process is executed automatically when the need arises, without manual intervention. Exchange ActiveSync connection process In Office 365, EAS devices connect to a publicly-facing Exchange Client Access Server (CAS). CAS authenticates the user based upon the provided credentials and retrieves the user’s mailbox version and the mailbox’s location. The mailbox’s location is the Active Directory forest and site where the active copy of the user mailbox is stored. The CAS will handle the connection in one of the following ways, depending on the mailbox location relative to the location of the CAS: Same forest, same site If the mailbox is in the same Active Directory site as the CAS, CAS will retrieve the content directly from the Mailbox server. Same forest, different site If the mailbox is in the same Active Directory forest but a different Active Directory site than the CAS, CAS will redirect or proxy the device to the correct Active Directory site in that forest. Different forest, different site If the mailbox is located in a different Active Directory forest than the CAS, CAS will act differently depending on the EAS protocol version that it previously negotiated with the device: If the device is using earlier versions of the protocol ( EAS 12.0 and below), the connection is proxied to a CAS server in the forest where the mailbox is located. If the device is using more recent versions of the protocol ( EAS 12.1 and above), CAS issues a redirection request back to the device pointing it to the specific forest containing the mailbox. The device should then establish a direct connection to the new forest. For an overview of proxying and redirection, see Understanding Proxying and Redirection in Exchange 2010 documentation. How do devices choose which site to access? Phones and tablets connect to Office 365 in a number of ways, depending on the device capabilities, configuration and which protocol version has been negotiated. Specifically: The device may automatically discover the correct mailbox forest based on the user’s email address if the device supports the EAS Autodiscover command. The user may configure the device to access a specific URL: If the user enters the Office 365 endpoint URL for mobile devices (m.outlook.com), this address points the device to a number of forests that are geographically closest to user. The device then connects to one of the returned forests. If the user enters a specific forest URL, the device connects to that forest. If the user enters a specific site URL, the device connects directly to that site. Office 365 contains a number of Active Directory forests, each of which contains several sites. Each forest has a default front-end site. When a device connects to a forest, it transparently connects to the front-end site for that forest. Depending on whether the device connects to the Active Directory site where the user’s mailbox is located, the connection logic either retrieves the content directly, or proxies or redirects the device to the correct site. Issues with redirection More recent versions of EAS protocol support the redirection command. When a device using a more recent version of the protocol reaches a CAS in a site that doesn't contain the requested mailbox, the server responds to the request by redirecting the device to a CAS in the site hosting the active copy of the user’s mailbox. We assume that devices which advertise to the server support for EAS protocol version 12.1 and later comply with the EAS requirement to support the HTTP redirection error code. Note: If you want to determine the Exchange ActiveSync protocol version that your device is currently using, refer to your device manufacturer’s documentation. A problem can occur when a device claims to support redirection, but does not reliably do so. These devices cannot access the mailbox, and the user may receive a number of errors depending on the device (for example, unable to connect to server). A very small number of devices connecting to Office 365 are impacted by this failure to implement Exchange ActiveSync completely (about 1%). Modifying the Office 365 deployment to compensate for these devices that don’t correctly support redirection would result in a degraded experience for all mobile device users. Performance for the devices is better if they connect to the correct Active Directory site directly after being redirected. Phones and tablets that are part of the Exchange ActiveSync Logo Program support redirection and thus, do not experience this issue. We are working with a number of other manufacturers to help them support the redirection logic and fix their connectivity issues. How to fix it? If your users are having trouble connecting to their Office 365 mailboxes on devices that don’t fully support redirection, use one of the following methods to fix the issue: Update the Exchange server setting on your device to m.outlook.com as shown in the example below. Then, try connecting to your account and see if this change resolves the issue. If using the Exchange server name m.outlook.comdoes not fix the issue: Sign in to your account using Outlook Web App on a computer. Click Options in the top right corner and select See All Options… as shown below. On the My Account tab (shown below), click Settings for POP, IMAP and SMTP Access… On the page that opens, under External POP setting you'll see a server name listed. Use the Server nameon this page for the Exchange server value on your device email configuration. Note: Although the setting is listed as the server name for POP , it's also an endpoint for Exchange ActiveSync. If using m.outlook.com and the External POP Settings/Server name value did not fix the issue: Go back to the main page of Outlook Web App. In the top right corner, click on the question mark next to Options and then select About as shown below. On the About page, you'll see the entry for the Host name listed. Use the value next to the Host name as the server setting on your mobile device. Note: When you use the Host name as your Exchange server setting, you may need to update the setting in the future. As I described before, the mailboxes may be moved from one site to another, and devices that do not support the redirect command correctly will lose connectivity. If your user mailbox moves due to failover or upgrades, your site name (Host name) may change and you may need to reconfigure your device to point to the new site. Another method to resolve the issue may be to try using a different email application on your mobile device. Some EAS applications are able to properly handle redirection even on a device that doesn’t support the redirection command. More help and resources Mobile Phone Setup Wizard lists steps to configure email account on mobile devices Exchange ActiveSync Logo Program lists devices that support redirection Exchange Server Protocol Documents specify how devices should behave when connecting to Exchange servers Contact your device manufacturer to see if it's possible to update the Exchange ActiveSync client on your device. Katarzyna Puchala The title of this post was changed shortly after publishing. The permalink URL may differ from the post title.Exchange ActiveSync on-boarding to Office 365
Introduction Exchange Server 2013 Cumulative Update 8 (CU8) and Exchange Server 2010 SP3 Rollup Update 9 (RU9) introduced a new feature to provide a more seamless experience for ActiveSync-enabled users who move from on-premises Exchange servers to Office 365. This blog post explains the current situation with on-boarding Exchange ActiveSync (EAS) users as well as the new functionality offered. EAS On-boarding Today, when a user's mailbox moved from Exchange on-premises to Exchange Online (Office 365), Outlook and Outlook Web App (OWA) have a seamless method to redirect the user to the new mailbox location. Outlook uses Autodiscover to redirect the user, and OWA provides a link to Office 365 login. But what about ActiveSync-enabled devices? Before the above updates are installed, after the mailbox is moved, the user’s mail stops syncing on their EAS device because the device can no longer find the current location of the mailbox. The user has to manually re-configure the device with the new URL, or delete and recreate the email account on the device. The reason for this behavior is that when a mailbox is moved from on-premises to Office 365, the device tries to connect to the user’s mailbox’s last location before the migration, which is the on-premises server. On-premises Client Access servers did not redirect devices to new mailboxes. If the user’s mailbox was not found in the source forest, the Client Access server would return an error message. In short, this is the pre-update mail synchronization flow for an EAS device after a mailbox is moved from on-premises to Office 365: The EAS device tries to sync using the currently configured URL and hits the on-premises Client Access server. The on-premises Client Access server checks if the user’s mailbox is present. The Client Access server gets a response that the user mailbox is not found. The Client Access server returns a “UserHasNoMailbox” error to the mobile device, which is displayed in the form of the following error message: Solution A solution has been built (and shipped in above mentioned updates) to make sure mailbox moves from on-premises to Office 365 are seamless for EAS users, as well. Once the updates are installed on your on-premises servers and a mailbox is moved to Office 365, an EAS device should be able to find the new location of the mailbox and sync without any user impact or intervention. Let’s take a detailed look at how the solution works: Before the move, the EAS device configuration will show it is configured to sync with on-premises URL: The flow after the mailbox is moved to Office 365: The EAS device tries to sync using the currently configured URL and connects to the on-premises Client Access server. The Client Access server checks if the user mailbox is present. The Client Access server gets a response that the user mailbox is not found. The Client Access server triggers a query to find the “TargetOWAURL” property present on the organization relationship object for the Office 365 tenant. The “RemoteRoutingAddress” property, present on the remote mailbox, is used to find the correct organization relationship. The Client Access server receives the TargetOWAURL configured on the Organization Relationship. The Client Access server sends the URL in an HTTP 451 response to the device. The EAS device tries to sync with the new URL, which should be successful. The EAS profile on the device is updated to the Office 365 URL. From this point forward, the device will continue to sync with Office 365. To make this work, certain prerequisites are required: All on-premises Exchange 2010 Client Access servers handling EAS requests must be running at least Service Pack 3 RU9. Exchange 2013 Mailbox roles handling EAS requests must be running CU8. The EAS version on the device should be 14 or higher, and the device must be able to handle 451 redirect responses. The Exchange on-premises organization has successfully set up hybrid with their Office 365 tenant. The OrganizationRelationship object must exist in the on-premises Active Directory environment and the TargetOWAURL should be populated with the Office 365 URL. The username and password for the user must remain the same after the move to Office 365. The user experience will not be seamless if the username or password is changed after the mailbox is moved to Office 365. Supported and Unsupported Scenarios Let’s take a look at what is supported and unsupported scenarios with respect to this solution. Supported scenarios: This feature covers mailbox migrations from Exchange 2010 or Exchange 2013 on-premises to Office 365 (Dedicated or Multi-Tenant). This feature applies to devices that are EAS-compatible and that support HTTP 451 redirection. Note: The implementation of HTTP 451 depends on each device manufacturer. The end user experience may vary based device functionality. Contact your device manufacturer to confirm if your device supports an HTTP 451 response. Unsupported scenarios: This feature does not support: Mailboxes moved from Exchange Server 2007 to Office 365, since Exchange Server 2007 EAS version is 12.1. Off-boarding a mailbox from Exchange Online to on-premises. Cross forest mailbox move between two Exchange Server 2013 or Exchange Server 2010 orgs. EAS devices or applications that do not process HTTP 451 redirects will continue to require manual intervention (the Outlook app for Android and iOS devices (previously known as Acompli) is an example of this). For all unsupported scenarios, users will get the same experience as without the solution, as described earlier. Organizationrelationship and TargetOwaURL The feature depends on the presence of a “TargetOwaURL” configured on the OrganizationRelationship. The Hybrid Configuration Wizard (HCW) creates and configures the OrganizaitonRelationship object and the TargetOWAURL, as well. Here’s an example of Organization Relationship and TargetOWAURL: You can re-run the Hybrid Configuration Wizard (HCW), if the Organization Relationship or TargetOWAURL are missing. Troubleshooting The solution should work as expected. However, if you are experiencing problems, here are some troubleshooting tips: Confirm all the pre-requisites have been met. Make sure the device is actually hitting the on-premises CAS. Check the HTTP Proxy or IIS Log on the CAS to make sure the device is reaching it. You can also see the server’s response. The key is to search for the name of user that is not able to connect to the server. Examples: IIS Log entries Here’s an example of an error entry from the IIS logs of an Exchange Server 2010 SP3 RU8 CAS showing the error returned to the device: 1/26/2015 23:07:39 192.168.1.53 POST /Microsoft-Server-ActiveSync/Proxy/default.eas Cmd=Sync&DeviceId=AC94832BCFD9DCD19D299AD36D2CA8C5&DeviceType=WP8&Log=PrxFrom:192.168.1.63_V141_HH: mail.batre.msftonlinerepro.com_Cpo19000_Fet19034_ExStk:H4sIAAAAAAAEAL2RzWrDQAyE74G8wx5dCH4Hpz%2fYBLcmpeci76q22s2uo5XB7tN3Q1iSU1sf2tNIMJpvQDVp9sG%2fSX4%2f6R5ch3lB%2fDw7nbRBPoBDJ9GAg5B365VSCkTVP96%2bBOS8ciQElj4x2Romp2kAm90szPrGVl37OpTX%2f6VtRxNlh%2fOfUQp9HInxDFpMuXzhgf1hj%2f1sGARNZeJrSZbXzrV4zlLDW%2b8EJ1H6rL8IK8EZG3OSbrEj17DXGMIejyMGyUqRISX3l3mjinBigrUt6A8F19tGPbXvqEVFI8MdCMQy69Wpcwnh0ddAtvXTFzY61Nj5AgAA_S123_Error: UserHasNoMailbox_Dc:BonDC1.contoso.com_SBkOffD:L%2f-480_TmRcv23:07:20.2281657_TmCmpl23:07:39.2625704_ActivityContextData:ActivityID%3d14988279-6caf-4565-8363-4ed43211bc35%3bI32%3aATE.C%5bBonDC1.contoso.com%5d%3d2%3bF%3aATE.AL%5bBonDC1.contoso.com%5d%3d0%3bI32%3aADS.C%5bBonDC1%5d%3d2%3bF%3aADS.AL%5bBonDC1%5d%3d1.75745_ 444 CONTOSO\Mig8 192.168.1.63 - - 200 0 0 19050 Here’s an example of an error entry from the IIS logs of an Exchange Server 2013 CU8 Mailbox server, showing a successful HTTP redirect response sent to the EAS device: 2015-01-22 13:37:53 192.168.1.61 POST /Microsoft-Server-ActiveSync/default.eas User=user12@batre.msftonlinerepro.com&DeviceId=RSUA4U03JH48LAS6T7BD2TENV0&DeviceType=iPad&Cmd=Ping&Log= RdirTo:TryToFigureOutEasEndpoint%3bhttps%3a%2f%2foutlook.Office 365.com%2fMicrosoft-Server-ActiveSync_V141_LdapC6_LdapL31_UserInfo:MailUser_Dc:BonDC1.contoso.com_Budget:(D)Conn%3a1%2cHangingConn%3a0%2cAD%3a%24null%2f%24null%2f0%25%2cCAS%3a%24null%2f%24null%2f0%25%2cAB%3a%24null%2f%24null%2f0%25%2cRPC%3a%24null%2f%24null%2f0%25%2cFC%3a1000%2f0%2cPolicy%3aDefaultThrottlingPolicy%5Fa53e58b3-edc1-4c36-be2c-0eec854b8637%2cNorm%5bResources%3a(DC)BonDC1.contoso.com(Health%3a-1%25%2cHistLoad%3a0)%2c%5d_ 443 user12@batre.msftonlinerepro.com 192.168.1.65 Apple-iPad2C2/1202.440 451 0 0 328 3. Verify the RemoteRoutingAddress After user’s mailbox is moved from on-premises to Office365, the on-premises user object is converted into RemoteMailbox, and “RemoteRoutingAddress” is stamped on the user. The RemoreRoutingAddress, stored in the “TargetAddress” Attribute, is used by on-premises Client Access servers to find out the correct Organization Relationship. On-premises Client Access servers try to find the Organization Relationship where the DomainName matches the SMTP domain of RemoteRoutingAddress. Example: RemoteRoutingAddress of the user is @Batre.mail.Onmicrosoft.com Which is matching the following Organization Relationship: In this case, the on-premises Client Access server will return TargetOWAURL from this Organization Relationship. Conclusion The EAS on-boarding solution will make it much easier for EAS users whose mailboxes are moved from Exchange on-premises to Office 365, because it provides a mechanism for the mobile device to be redirected to the Office 365 mailbox without user intervention. Bhalchandra Atre
