Microsoft Hybrid Agent Preview Update
As you are aware, we released the Microsoft Hybrid Agent for Exchange Server as a preview on Feb. 5 th , 2019. The blog post for that release is located here. We have been busy working on a few improvements for the Hybrid Agent over that past two months and wanted to let you know of some new features now available in the latest build of the Hybrid Configuration Wizard. The three enhancements for the Hybrid Agent are: Multi Agent installation and configuration Agent status views Registration/Usage of a load balancer for the internal URL instead of a specific Exchange Client Access Server Multi Agent Deployment Option 1 – Use the Hybrid Configuration Wizard to install additional agents For existing Hybrid Agent preview customers who would like to install additional Hybrid Agents for redundancy, simply download the latest version of the Hybrid Configuration Wizard (HCW) and open the application on the machine where you would like to install an additional Hybrid Agent. Like previous HCW runs, start the application, select Next. Select a desired server to execute against, select Next. Provide credentials to sign into your Office 365 tenant, select Next. The HCW will gather configuration information, select Next when complete. Select the default option provided for either Full or Minimal, select Next. Select Exchange Modern Hybrid Topology, Next. Agree to the Terms, Next. A new page will be shown that will provide you with the status of your existing / previously installed agent. Make sure the status of the existing agent is accurate before proceeding to the next step. Select Install and additional agent option, Next. Example: The HCW will install the additional Hybrid Agent. When the installation is complete, you can open the Microsoft Windows Services console from the machine and verify the service / agent is installed and running (look for Microsoft Hybrid Service - mshybridsvc). At that point, you can either re-run HCW if you wish to make further changes to your hybrid config, or simply cancel the wizard. You can repeat this step on each machine where you would like an additional Hybrid Agent installed. Option 2 – Manually download & install additional agents A second option for installing additional agents is outside the HCW itself and is done by downloading and manually installing the agent on the desired machine. Go to https://aka.ms/hybridagentinstaller. Save the MSHybridService.msi to a location on your machine. From that machine, open a Windows Command console as Administrator and run: Msiexec /i MSHybridService.msi to install the hybrid agent. You will be prompted for your tenant Global Admin credentials. After the installation is complete, you can open the Microsoft Windows Services console from the machine and verify the service / agent is installed and running. You can repeat this step on each machine where you would like an additional Hybrid Agent installed. Checking the Status of Your Hybrid Agents Option 1 – Get status via the Hybrid Configuration Wizard (HCW) Start the HCW application, select Next. Select a server in your Exchange org, select Next. Provide credentials to sign into your Office 365 tenant, select Next. The HCW will gather configuration information, select Next when complete. Select default option provided for either Full or Minimal, select Next. Select Exchange Modern Hybrid Topology, Next. Agree to the Terms, Next. A new page will be shown that will provide you with the status of your existing installed agents. Cancel the HCW app when you are done. Option 2 – Get status via the Hybrid Management PowerShell Module With each installation of the Hybrid Agent, we install the Hybrid Management PowerShell module in the directory …\Program Files\Microsoft Hybrid Service\ on the machine where the agent is installed. By default, this module is not imported and so you will need to import it before you can use it. This module also requires the Azure module for PowerShell if not already installed. Please install the PackageManagement modules first and then see this article for how to install the Azure module. To import the Hybrid Management module, run the following from a Windows PowerShell prompt as Administrator: Import-module .\HybridManagement.psm1 After that you can run: Get-HybridAgent -credential (get-credential) to view agent status: Note: the ‘id’ value provided in the above snip is the agent identity and not your unique tenant guid assigned to the route. Directing your Hybrid Agent(s) to the load balancer instead of a specific server If you would like your Hybrid Agent(s) to direct requests to your load balancer instead of a specific Exchange Client Access Server, this can be done with the Hybrid Management PowerShell module. In preview, the Hybrid Agent supports routing requests to the load balancer for Exchange Server 2013 – 2019 Client Access Servers. You cannot use this if you only have Exchange Server 2010 CAS deployed. Follow the steps above to import the Hybrid Management module for PowerShell. From PowerShell, then simply use the Update-HybridApplication cmdlet to change the value of the internalURL (targetURI parameter) from a specific server to your load balancer endpoint. Before running this cmdlet you will need to get the unique guid value (e.g. 12345678-1234-1234-1234-1111111111111) of your tenant’s endpoint from either your MRS configuration or the Organization Relationship object (TargetSharingEPR). Example: PS C:\PowerShell> Get-OrganizationRelationship ((Get-OnPremisesOrganization).OrganizationRelationship) | Select-Object TargetSharingEpr TargetSharingEpr ---------------- https://e399b770-3b66-407b-a71a-96ef80a67714.resource.mailboxmigration.his.msappproxy.net/EWS/Exchange.asmx Or PS C:\PowerShell> Get-MigrationEndpoint "Hybrid Migration Endpoint - EWS (Default Web Site)" | Select-Object RemoteServer RemoteServer ------------ e399b770-3b66-407b-a71a-96ef80a67714.resource.mailboxmigration.his.msappproxy.net To be clear, the ID parameter required in this cmdlet is not the agent ID, but the guid listed in your custom registered endpoint retrieved using the method above. Example: We really hope you are enjoying and benefitting from using the Hybrid Agent. We see a lot of usage and we’re working hard to improve it all the time. Thank you! Exchange Hybrid TeamExchange TLS and SSL Best Practices
Note: for more up to date guidance on TLS, please see this post. Whether you are running Exchange on-premises, in the cloud, or somewhere in between, we know that security is a top priority. Microsoft is committed to giving you the information needed to make informed decisions on how to properly secure your environment. It has been suggested by some external parties that customers need to disable TLS 1.0 support. One piece of guidance we are aware of suggests taking steps to prepare to disable TLS 1.0 in summer of 2016. Another piece of guidance suggests that TLS 1.0 should not be used with internal-only applications (we do not believe that Exchange is typically used in this manner, as it connects to the outside world via SMTP). While we believe the intentions of both proposals are good and will promote adoption of TLS 1.1 & 1.2, at this time, we do not yet recommend disabling TLS 1.0 on your Exchange Server(s). Additionally, while TLS 1.1 & 1.2 are superior to TLS 1.0, the real world risks may be somewhat overstated at this point due to mitigations that have been taken across the industry. Of course, security is rarely a binary decision: disabling TLS 1.0 doesn’t suddenly turn something insecure into something secure. That said, we will continue to work towards the goal of making TLS 1.1 & 1.2 work fully with Exchange and a broad array of clients. More importantly, many customers may not have taken initial steps towards following current best practices. We believe that the first step towards a more secure environment is to have a TLS organizational awareness. While disabling TLS 1.0 on Exchange is not advised at this time, there are definite steps which can be taken today. TLS 1.0 is not widely viewed as insecure when SSL 3.0 is disabled, machines are properly updated, and proper ciphers are used. The current recommendations, which will continue evolving, are as follows: Deploy supported operating systems, clients, browsers, and Exchange versions Test everything by disabling SSL 3.0 on Internet Explorer Disable support for SSL 3.0 on the client Disable support for SSL 3.0 on the server Prioritize TLS 1.2 ciphers, and AES/3DES above others Strongly consider disabling RC4 ciphers Do NOT use MD5/MD2 certificate hashing anywhere in the chain Use RSA-2048 when creating new certificate keys When renewing or creating new requests, request SHA 256-bit or better Know what your version of Exchange supports Use tools to test and verify Do NOT get confused by explicit TLS vs. implicit TLS (For now) Wait to disable TLS 1.0 on the Exchange server Let’s get started down the list! Deploy supported operating systems, clients, browsers, and Exchange versions Perhaps it goes without saying, but the first step to securing any environment is to make sure that all servers, devices, clients, applications, etc. are updated. Most issues that support sees after following recommendations on Exchange are easily fixed with updates already available from the vendor of the incompatible device (printers, firewalls, load balancers) or software (mailers, etc.). For Exchange, this means test & apply your Windows & Exchange updates regularly. Two reasons for this – first, an environment is only as secure as the weakest link; second, older software typically won’t let you take advantage of the latest TLS versions and ciphers. Make sure firewalls, old Linux MTAs, load balancers, and mass mailer software are all updated. Make sure the multifunction printers have the latest firmware. Test everything by disabling SSL 3.0 on Internet Explorer Disabling SSL 3.0 in the browser is a good first step, because it insures that all your users remain safe, no matter where they may browse. Additionally, it easily allows you to test to make sure that websites and applications will continue to work or not. There’s still a small bit of the Internet that is still relying on SSL 3.0, but the time is overdue for it to be retired. To test your environment with Internet Explorer, follow KB3009008. Disable support for SSL 3.0 on the client After testing, you may also consider disabling it at the SCHANNEL layer for all clients. While you are viewing these settings, make sure that your clients have TLS 1.1 & 1.2 enabled. In most cases, the most recent version supported by both the client & server will be used. This is a good way to start moving towards a more secure environment. All supported versions of Windows have TLS 1.1 & 1.2 capabilities, but the older ones may not have them enabled by default. Note that registry changes under SCHANNEL are only good for applications that use the SCHANNEL API. Some applications could utilize 3 rd party or open source security APIs (like OpenSSL) which may not look at these registry keys. Also, note that changes do not take effect until reboot. Disable support for SSL 3.0 on the server The next recommendation is to disable SSL 3.0 on all servers, Exchange included. Do this by following all recommendations in the original security bulletin. Since servers can be both clients and servers, it is recommended to follow all applicable steps. As before, while you are viewing these settings, make sure that your servers have TLS 1.1 & 1.2 enabled. Note: Any of these registry changes require a reboot to take effect! You can do this with confidence because TLS 1.0 will be the minimum which you support. Exchange and Windows have both supported TLS 1.0 for over a decade. TLS 1.0 itself is not considered vulnerable when SSL 3.0 is disabled on clients and servers. In fact, most Exchange sessions already have been using TLS 1.0 or even later, for years. You are simply disabling the ability for the session to be downgraded to SSL 3.0. Disabling SSL 3.0 is typically not too impactful except for clients and devices that are older than (roughly) 10 years old. These recommendations should have already been carried out in your organization with haste. Even so, the POODLE vulnerability itself does require someone to intercept the traffic and sit between the client and server during the initial session negotiation. While this is not super difficult to accomplish, it is also not trivial. It is a much more severe problem for users who travel and for mobile devices which use hotspots. As many customers do support remote access to email, this is something for Exchange administrators to worry about. Since some mobile device vendors have not released ways to disable SSL 3.0, you can at least keep your Exchange resources safe by disabling SSL 3.0 on the server side. In addition, enabling support for TLS v1.1 and v1.2 are highly recommended. But leaving TLS 1.0 enabled is a good thing for now. Clients and applications should always prefer the most secure option, provided that Windows, the application, and the client all support it. Note: If you terminate SSL at load balancers, you’ll want to disable SSL 3.0 there as well (and perform subsequent steps there in addition). Check with your vendor to get their guidance. Also, be sure to check all Exchange servers which may be sharing a single VIP or DNS record. Office 365 completed these changes, and you will find that SSL 3.0 is not possible for any protocol. Prioritize TLS 1.2 ciphers, and AES/3DES above others The next step we recommend is based on a step we took in Office 365 to prioritize the latest ciphers which are considered much more resilient to brute force attack. The thing with ciphers is that it isn’t just about enabling the most secure one and disabling the rest. You want to offer several choices for clients to allow maximum compatibility. You typically want to disable the ones which are the least secure, but leave others to provide choice. The negotiation of a particular cipher depends on: The client passes an ordered list of ciphers which it supports The server replies with the best cipher which it has selected (server gets final say) Changing the order on the server can minimize the use of a less secure cipher, but you may want to go further and disable it completely. Cipher changes are made through this registry key, explained here. Strongly consider disabling RC4 ciphers Of course, there is risk of some clients not continuing to work if you disable too many ciphers. That said, Microsoft has been recommending that disabling RC4-suite of ciphers is a good best practice. It is considered to be a weak cipher. Disabling RC4 should be done with some care as it can introduce incompatibilities with older servers and clients, though problems should be minimal as supported versions of Windows have supported 3DES and AES alternatives for years. The rollout of this in Office 365 is in progress and should be completed shortly. Do NOT use MD5/MD2 certificate hashing anywhere in the chain Ciphers depend on the certificate chain being used - you can introduce problems when connecting to a host which has an insecure signature algorithm used in their chain. For example, we have seen that Office 365 SMTP transport is no longer able to connect to hosts with MD5 and MD2 hashing because they do not support modern ciphers. This applies to the certificate and any certificates in the chain. We see this with SMTP because Exchange is acting as a client, and because there are many older SMTP systems and firewalls still out there. Use RSA-2048 when creating new certificate keys Some things to watch out for when you renew or reissue certificates. First is that when creating your requests, use 2048-bit RSA. Anything less is not considered secure anymore. When renewing or creating new requests, request SHA 256-bit or better Second, when you renew, you should consider moving the signature algorithm from SHA1 to SHA2 if you haven’t already done so. This isn’t considered something that you need to worry about until renewal time, unless your certificate happens to be good for another couple of years – in which case, go ahead and take care of it now. You can check your Exchange certificates with a browser (or in Certificate Manager MMC): This example certificate was generated with Exchange 2013 on Windows 2012 R2. It has an RSA 2048-bit key and has an RSA SHA256 (SHA-2) signature algorithm. Know what your version of Exchange supports Some applications sometimes need to be re-compiled and tested to take advantage of these new protocols. So, every part of Exchange and Windows-based clients need to be examined and tested thoroughly. Currently, for Exchange Server, we are aware of the following limitations: SMTP – key piece of Exchange server infrastructure – support for TLS 1.1 and 1.2 were added in Exchange Server 2013 CU8 and Exchange Server 2010 SP3 RU9. This means if you want to add support for the latest ciphers and TLS versions, you may need to apply an update. IMPORTANT: SMTP is the main protocol used when communicating outside of your organization, something which is a key purpose of email. If you disable TLS 1.0, SMTP would no longer be able to use Opportunistic TLS with any external party which doesn’t support TLS 1.1 or 1.2. Emails will then be sent/received in the clear, which is certainly significantly less secure than TLS 1.0. That said, we have enabled new logging in the Exchange SMTP protocol logs to allow you to audit the impact of future changes on SMTP. Additional Note: SMTP is notably a protocol where Exchange acts as both a client and a server. Some older server implementations have been observed to incorrectly implement version negotiation. In these cases, the remote servers terminate the connection when Exchange (acting as a client) offers a version newer than TLS 1.0. This results in a complete stoppage of email to these systems. Fortunately, these situations are becoming rare as time passes, but this is pointed out because the effects often are more impactful than a mail client which cannot connect. POP/IMAP – not used as frequently in all environments, but if you do, beware that we only currently support TLS 1.1 and 1.2 on-premises in the Exchange Server 2016 Preview. We hope to make this available in a future CU, or you can make a request for it via proper channels so we can prioritize it. Office 365 already has this support. HTTPS (OWA, Outlook, EWS, Remote PS, etc.) – The support for TLS 1.1 and 1.2 is based on the support in IIS itself. Windows 2008 R2 or later supports both TLS 1.1 and 1.2, though the specific version of Windows may have these disabled or enabled by default. There is another important caveat here: the HTTPS proxy between CAS and Mailbox requires TLS 1.0 in current versions of Exchange Server – so disabling TLS 1.0 between CAS and Mailbox causes the proxy to fail. This is also something we have addressed in the Exchange 2016 Preview. We hope to make this available in a future CU, or you can make a request for it via Support. If you have dedicated roles, you can technically disable TLS 1.0 between the client & CAS, but we still are not recommending this. Office 365 already supports TLS 1.1 & 1.2, if the client supports them. Clients – TLS 1.0 is universal, with near 100% support. Though TLS 1.1 and 1.2 are growing more common, many Exchange clients still do not work with anything but TLS 1.0. For example, at this time, we are tracking multiple issues with Outlook running on Windows 8.0 or older. We are hoping to address these issues soon, but with Windows 7 commonly running in most customer environments, this is a really good reason to not disable TLS 1.0 yet. Comprehensive testing of other clients running without TLS 1.0 has not been completed by Microsoft at this time. Note: Windows Remote Desktop may also have challenges, depending on your version of Windows. For servers which are managed remotely, be sure to test this first. Use tools to test and verify There are several tools and websites you can go to for testing your server(s) and clients. It is highly recommended to do so. Some offer a grading/scoring system. Others offer pass/fail. We’re inclined to recommend one with a scoring system, since security is about risks and tradeoffs. Don’t be surprised if one or more of these tools doesn’t fully test for POODLE and just thinks TLS 1.0 is bad. Use your newfound knowledge to read the results for what they are. We prefer tools that let you check specific things (like cipher order, or individual TLS/SSL versions) in addition to the blanket “vulnerability tests”. There is also one fantastic (non-Microsoft) website called SSLLabs which simulates multiple clients and can warn you of compatibility issues with the clients which it knows about. For example, here we see that disabling TLS 1.0 would likely cause issues with older versions of Android clients: In addition, you can see how you compare with the rest of the Internet. This is great for HTTPS. Most certificate vendors have test tools available as well, though they have differing coverage of what is tested. Other tools are available which test additional protocols. Here is a test being run against IMAP on port 993 (referred to as the “SSL binding”; see below for explanation): As you can see, even on port 993, TLS 1.0 is used with AES256. Do NOT get confused by explicit TLS vs. implicit TLS In the course of human events, shortcuts are taken. One unfortunate shortcut occurred when TLS 1.0 added optional support for a per-protocol implementation of STARTTLS, also known as “explicit TLS”. Prior to “explicit TLS”, if a server application level protocol wanted to implement SSL/TLS in addition to a non-secure option, it had to take up a separate port on the machine for each. This is “implicit TLS”. See the following chart: Protocol IANA port (Explicit TLS) Protocol IANA Port (Implicit TLS) E-SMTP 25 SMTPS 465** POP3 110 POPS 995 IMAP4 143 IMAPS 993 HTTP 80* HTTPS 443 * HTTP doesn’t implement explicit TLS, because it is stateless and the overhead would not be worth it. ** Exchange specifically does not support SMTPS (implicit TLS). The first protocol which implemented this verb was ESMTP. By doing so, SMTP could support clients & servers on the same port, and could also easily implement “opportunistic” TLS/SSL. In fact, Exchange has never supported SMTPS (465), although we do reuse that port by default in Exchange 2013 for one of the three transport roles. For POP and IMAP, Exchange supports both the explicit option and the implicit option. What can be confusing is that because STARTTLS didn’t come about until TLS 1.0 – some people started confusing explicit TLS with “TLS” and some mail applications started using the terminology interchangeably. So, disabling port 995 & 993 does not turn off SSL 3.0 (you are disabling implicit POPS & IMAPS, but not SSL) – nor is enabling port 110 & 143 (explicit TLS) required for TLS 1.x. The terminology is confusing, but the concepts are mostly unrelated. This unfortunate optimization was brought into Exchange: However, tinkering with ports and implicit/explicit should not be necessary as you are NOT disabling SSL 3.0 by doing so. Securing Exchange Server shouldn’t mean changing any of these settings – just the SCHANNEL registry settings discussed above. (For now) Wait to disable TLS 1.0 on the Exchange server In summary, as of July 2015, Exchange currently supports TLS 1.0, but can also support TLS 1.1 & 1.2 with the following minimum requirements met: Protocol TLS v1.1/1.2 Minimum Requirements SMTP Exchange 2013 CU8 or Exchange 2010 SP3 RU9 POP/IMAP Exchange 2016 Preview HTTP (server) Windows 2008 R2; MAPI clients must run Windows 8.1 or later HTTP (proxy to MBX) Exchange 2016 Preview As you can see, since Exchange Server 2016 isn’t released yet as an in-market product (it is for lab use only at this time), and since Windows 7 is still the most prevalent Windows version, it is quite impractical to fully disable TLS 1.0. Not only will POP/IMAP break (for lack of TLS 1.1 and 1.2 support), but you cannot disable TLS 1.0 on any Exchange server running the mailbox server role. Most importantly, disabling TLS 1.0 will result in compatibility issues with some common mobile devices, clients, and possibly interrupt some Internet email. Don’t panic – if you have disabled SSL 3.0 and decided on a cipher order that your organization can agree on, you are likely quite secure, and you are not vulnerable to the POODLE attack. Microsoft is committed to adding full support for TLS 1.1 and 1.2. TLS v1.3 is still in draft, but stay tuned for more on that. In the meantime, don’t panic. On a test Exchange lab with Exchange 2013 on Windows Server 2012 R2, we were able to achieve a top rating by simply disabling SSL 3.0 and removing RC4 ciphers. This is nearly as good as one can achieve at the time of this posting on released versions of Exchange without impacting common clients. Additionally, this configuration should be highly compatible with nearly all clients and devices from the past decade or more, while utilizing the latest security with clients which do support it. Of course, security requires a watchful eye as new threats and vulnerabilities are discovered from time to time. As always, stay tuned to Security Bulletins and updates. Scott Landry Senior Program Manager, Exchange SupportabilityEstablishing Exchange Content Index Rebuild Baselines Part 3
In Part 1 of this series, I explained the E2K7_IndexRebuildAnalyzer.ps1 script and in Part 2, I discussed the Search Rebuild Framework that Anatoly Girko and I developed. Before concluding this series I did want to provide a series of graphs as well as an “observed averages” table that illustrate the rebuild characteristics we have observed since the inception of the framework. Hopefully this allows for better conceptualization as well as empowering you to make better estimates when calculating your own rebuild rates.. Observed Averages to Date within Microsoft Anatoly and I went back and forth on how to best to present this. As one might imagine there are an infinite number of possibilities for presentation. We decided to scope the graphs and table to the message size that most Exchange Storage Architects design to: 150 KB per mail item. We then performed a secondary filter on Mailbox Count and only took into account Mailbox Databases within our data collections that had 100 or more active mailboxes to build the averages below. Once done, we removed the 10% best performing and 10% worst performing rebuild operations from within our collection to derive the averages used to build the graphs and tables. Note: In the various graphs and table to follow Averages Mailbox Sizes in several range increments are noticeably missing. This data was not overlooked or purposefully omitted. Absence of statistical data for these ranges is due to the fact that no valid data exists in our historical collections. Put another way we have never performed Content Index rebuild operations and/or collected Post-Rebuild metrics for databases where the Average Mailbox Sizes for end user mailboxes were in the following ranges: 1700-1799 MB 1800-1899 MB 2000-2099 MB 2100-2199 MB Graphs We will be presenting four Excel Pivot Charts that reflect the throughput characteristics we have observed to date based upon the filtered collection as described above. These Pivot Charts are meant to illustrate the relationship that exists between various properties as they occur within and around the Mailbox Store (e.g. mailbox count, item count and EDB file sizes) and contrast them with the historical throughput times required to complete Full Crawl against Mailbox Stores with similar characteristics. Graph 1 The view contained within Graph-1 specifically depicts the relationship between Mailbox Counts per Database, the relative size of the Mailbox Databases in gigabytes and how this ultimately impacts the total time to complete Content Index rebuild of the Mailbox Stores in minutes. This graph makes a clear argument that as the total number of active mailboxes on an Exchange Mailbox Database increases there will also tend to be a parallel relationship for increases to the EDB file size on the storage subsystem. This relationship subsequently has an impact on the overall time to complete a Full Crawl of a Content Index. This is really just a fancy way of saying that: with more active mailboxes typically comes more mail items; with more mail items comes a larger EDB file size on disk; the larger an EDB file size is on disk the longer it will “usually” take to rebuild a Content Index. The only situation where this hypothesis will never hold true is in the case of a Mailbox Database that had a large amount of whitespace present in the file. In such a case the overall time to complete a Content Index rebuild will be noticeably faster than anticipated. This anomaly situation has been seen within the environments we support but the subsequent statistics were removed from our collection by leveraging the filtering technique discussed above. Graph 2 Graph-2 depicts the relationship that exists between the Average Mailbox Size (for mailboxes that exist on databases contained within the same filtered sample set) and how it impacts the Content Index rebuild throughput at the Mailbox Database level in Seconds per/mailbox. This graph essentially restates the argument presented in Graph-1 albeit at the active mailbox level. Specifically as the active mailbox size averages increase so do the average number of mail items within those mailboxes. On average the more mail items within a mailbox the longer it will take the Search Indexer to complete crawl against a given mailbox which in turns impacts how long it will take to complete Full Crawl for all mailboxes within the database. Graph 3 Graph-3 depicts the relationship that exists between the Average Mailbox Size (for mailboxes that exist on databases contained within the same filtered sample set) and how it impacts the Content Index rebuild throughput in Megabytes per/second. Graph-3 builds on the initial hypothesis alluded to in Graph-2. Specifically it shows that as the Average Mailbox Size and Average Item Counts within a Mailbox Database increase there is a negative relationship with respect to Search Indexer throughput. Graph-3 shows this relationship in megabytes per second. Graph 4 Graph-4 depicts the relationship that exists between the Average Mailbox Size (for mailboxes that exist on databases contained within the same filtered sample set) and how it impacts the Content Index rebuild throughput in Items per Second (based upon Average Message Size of 150KB): As was the case with Graph-3, Graph-4 shows the negative performance impact with respect to throughput in Items per/second. Observed Averages Table To present the table we utilized the same filtered set (described above and presented in the graphs) but elected to create focused averages based upon Average Mailbox Size. These rows are subsequently delineated as independent rows in increments of 99 megabytes. The throughput characteristic for each row represents the aggregate averages for all similarly sized databases that have completed rebuild operations in our collection. Specifically where the Average Message Size was 150KB and the Average Mailbox Size for all active mailboxes on those databases were within the ranges defined by Column-A. The historical averages presented in this table (at least to me) produce three potential ways of estimating Content Index rebuild times: A “Historical Average” could be implemented based upon Average Mailbox Size where the Average Message Size for items residing within those mailboxes is 150KB. Because we have large amounts of historical rebuild data in our collection we choose to leverage this average. We derive our estimate by determining the Average Mailbox Size value via “pre-rebuild” metrics and compare this to the historical average. We then take the composite average for Rebuild: Seconds per/Mailbox and then multiply that figure by the number of mailboxes on the database which require crawling to determine the total time necessary to complete. An “Organizational Average” could also be established based upon Average Message Size irrespective of the number of items and average size of the mailboxes across the organization (that Organizational Average is provided in the Averages Row above). A composite average between historical average and organizational average. For example, if I have a Content Index that needs to be rebuilt for a database whose users have an aggregate Average Mailbox Size in the 500-599 MB range and assuming the Average Message Size is 150KB, if that database has 200 users on it, I could derive the estimate in one of three potential ways: The Historical Averages Table: 200 mailboxes * 63 seconds = 12,600 seconds total. This equates to 210 minutes or roughly 3.5 hours to complete Full Crawl. The “Organizational Average”: 200 mailboxes * 108 seconds = 21,600 seconds total. This equates to 360 minutes or roughly 6.0 Hours to complete Full Crawl. Composite Average (Average of “Historic” + “Organizational”): 3.5 + 6.0 = 9.5 Hours 9.5 / 2 = 4.75 Hours Conclusion The total time it takes to rebuild a Content Index will always be variable because mail populations and items therein are always variable too. When rebuilding Content Indexes the most accurate and robust estimates will always come from leveraging historical averages. I also wanted to mention that when I/we make decisions to rebuild Content Index internally at MSFT we do our best to schedule them for “least user impact” time intervals. However, our implementations are global so it is more or less impossible to completely eliminate end-user impact. The best you can hope for is to minimize the impact on the surface area. Furthermore, within our data collections we don’t factor in Search Indexer Throttling Delays. Any and all Search Indexer Rebuild Throttle Delays are handled and understood within the moment and are representative within the individual tickets as they are presented to operations. By leveraging the filtering techniques used throughout this post you insulate your figures from those negative averages (same is true for “overly high throughput” rebuild operations) making your overall estimates considerably more accurate. If you are the type of personality that that has a propensity for betting with averages I fully stand by our table. If a more exact science is required, I would suggest implementing a framework such as the one we describe within this post series. We hope you find this post series useful, and better yet, have learned something new along the way! Happy Trails! Eric Norberg Service Engineer Office 365-DedicatedUpdated: Exchange Server Deployment Assistant
We’re happy to announce updates to the Exchange Server Deployment Assistant! These updates offer you more deployment options and outline new features that make deployments more flexible and easier to configure. We’ve updated the Deployment Assistant to include the following: Support for the Exchange 2013 Edge Transport server role in all on-premises and hybrid deployment scenarios Support for the new, automated process for requesting an Exchange 2013 or Exchange 2010 Hybrid Edition product key New in Exchange 2013 SP1, Edge Transport servers minimize the attack surface by handling all Internet-facing mail flow, which provides SMTP relay and smart host services for your Exchange organization, including connection filtering, attachment filtering and address rewriting. For more information, see Edge Transport Servers. Also newly released, you can now use the new product key wizard to submit your request to Microsoft Support to obtain an Exchange 2013 or Exchange 2010 product key for use in hybrid deployments. The request process is quick and easy and you’ll have your product key in minutes! You can request a Hybrid Edition product key if all the following conditions apply to you: You have an existing, non-trial, Office 365 Enterprise subscription You currently do not have a licensed Exchange 2013 or Exchange 2010 SP3 servers in your on-premises organization You will not host any on-premises mailboxes on the Exchange 2013 or Exchange 2010 SP3 server on which you apply the Hybrid Edition product key And, there’s even more on the way! We’re working hard on testing and adding new deployment scenarios to support configuring hybrid deployments with an Office 365 tenant and multi-forest on-premises Exchange organizations. We’ll start by supporting scenarios for multi-forest Exchange 2010 organizations that add Exchange 2013 SP1 servers for hybrid support, and then follow with scenarios supporting for native multi-forest Exchange 2013 and Exchange 2007 organizations. Keep checking back here for release announcements. In case you're not familiar with it, the Exchange Server Deployment Assistant is a free web-based tool that helps you deploy Exchange 2013 or Exchange 2010 in your on-premises organization, configure a hybrid deployment between your on-premises organization and Office 365, or migrate completely to Office 365. The tool asks you a small set of simple questions and then, based on your answers, creates a customized checklist with instructions to deploy or configure Exchange Server. Instead of trying to find what you need in the Exchange library, the Deployment Assistant gives you exactly the right information you need to complete your task. Supported on most major browsers, the Deployment Assistant is your one-stop shop for deploying Exchange. Do you have a deployment success story about the Deployment Assistant? Do you have suggestions on how to improve the tool? We would love your feedback and comments! Feel free to leave a comment here, or via the 'Feedback' link located in the header of every page of the Deployment Assistant. Happy deploying! The Deployment Assistant TeamAnnouncing Microsoft Connectivity Analyzer (MCA) 1.0 and Microsoft Remote Connectivity Analyzer (RCA) 2.1
Back in November 2012, we announced our MCA Beta client. We have been very busy working to improve the testing options that are available from the MCA client. Here’s what we’ve built for the 1.0 release: Microsoft Connectivity Analyzer Tool 1.0 We are excited to announce the 1.0 release of the Microsoft Connectivity Analyzer. This tool is a companion to the Microsoft Remote Connectivity Analyzer web site. The MCA tool provides administrators and end users with the ability to run connectivity diagnostics for five common connectivity symptoms directly from their local computer. Users can test their own connectivity, and save results in an HTML format that administrators will recognize from viewing results on the RCA website. Install the MCA 1.0 tool here: https://testconnectivity.microsoft.com/?tabid=client Watch the Introduction Video: The MCA tool offers five test symptoms: “I can’t log on with Office Outlook” – This test is equivalent to the Exchange RCA test for “Outlook Anywhere (RPC over HTTP)”. There is an option to run the SSO test provided on the parameters page. “I can’t send or receive email on my mobile device”. – This test is equivalent to the Exchange RCA test for Exchange ActiveSync. ***New MCA Test*** “I can’t log on to Lync on my mobile device or the Lync Windows Store App” – This test checks for the Domain Name Server (DNS) records for your on-premise domain to ensure they are configured correctly for supporting Mobile Lync clients. Also it connects to the Autodiscover web service and makes sure that the authentication, certificate, web service for Mobility is correctly set up ***New MCA Test*** “I can’t send or receive email from Outlook (Office 365 only)” – This test checks Inbound/Outbound SMTP mail flow and also includes Domain Name Server validation checks for O365 customers. ***New MCA Test*** “I can’t view free/busy information of another user” – This test verifies that an Office 365 mailbox can access the free/busy information of an on-premises mailbox, and vice versa (one direction per test run). Microsoft Lync Connectivity Analyzer Tool: You will also notice the Lync Connectivity Analyzer Tool on the client page. We are working on combining MCA with MLCA in the near future but wanted to make both these great tools available to customers now to improve our client diagnostics options. To learn more about MLCA – go HERE Feedback: Send all feedback to the MCA Feedback alias. Please let us know what you think of the tool and whether this will be helpful in troubleshooting connectivity scenarios. Also feel free to provide feedback on additional tests you would like to see added in the future. Microsoft Remote Connectivity Analyzer 2.1 We are excited to announce the 2.1 release of the Microsoft Remote Connectivity Analyzer web site. The tool provides administrators and end users with the ability to run connectivity diagnostics for our servers to test common issues with Exchange, Lync and Office 365. We have added new Office 365 Domain Name Server tests, enhanced existing tests, and improved the overall site experience. Check out the updates to the website here: https://testconnectivity.microsoft.com Here are the highlights of the 2.1 RCA release: Version 2.1 (March 2013) Added support for localized language support for 60 languages Updated version of the downloadable Microsoft Connectivity Analyzer v1.0 Tool for troubleshooting connectivity from the local machine Added Microsoft Lync Connectivity Analyzer downloadable tool for troubleshooting Lync issues from the local machine Added Office 365 General Tests section Added Office 365 Exchange Domain Name Server (DNS) Connectivity Test Enjoy! Thanks. Brian Feck on behalf of the entire MCA/RCA team. Follow the team on Twitter - @ExRCAExchange Online Protection: A Premium Protection and Policy Service for Email
This summer, Microsoft introduced the new Office, including the new version of Exchange Server 2013 and Exchange Online, which provides businesses with robust communication and collaboration capabilities available on-premises or in the cloud. When you talk about messaging and collaboration, especially within the larger context of cloud services, one of the questions to quickly follow is, how do we keep our organization safe from spam and malware? Today, many Exchange Server and Exchange Online customers use Forefront Online Protection for Exchange (FOPE) for messaging protection, policy enforcement, and mail-routing control. The next release of FOPE will be called Exchange Online Protection (EOP). EOP provides the protection and control you’ve become accustomed to with FOPE, but with new features too. EOP is available as a stand-alone cloud service if you run Exchange, or another messaging solution, on-premises. If you have an Office 365 subscription, EOP is directly integrated in the Exchange Administration Center, which provides a seamless experience for administrators managing and protecting their organization’s mailboxes. Messaging Protection in the Exchange Administration Center Forefront Online Protection for Exchange (FOPE) had a user interface separate from on-premises Exchange Server and Exchange Online. The new EOP user interface is identical in appearance with the Exchange Administration Center for on-premises customers, For Exchange Online customers, EOP features have been integrated directly. EOP Features at a Glance EOP provides inbound and outbound spam and malware filtering, reporting, message trace, and mail-flow configuration features. Some of these features were included with FOPE, and in many cases have they have been enhanced. EOP features include the following: URL lists for spam filtering that block messages containing specific URLs within their message body. EOP includes additional lists beyond those available in FOPE. The ability to skip spam filtering for trusted senders, based on subscription lists The ability to filter messages written in specific languages, or sent from specific countries or regions Malware filtering that can delete and strip unsafe attachments The capacity to mark bulk email (such as advertisements) as spam through the user interface The capability to search for, view, or release quarantined email messages in the EAC Transport rules which you can use to control mail flow, based on a message’s content Message tracing capability, which allows you to search for and view details about a specific message Inbound connectors and outbound connectors you can use to enforce secure communication between you and a partner, or to make hybrid mail flow (where you host a portion of your mailboxes on-premises and a portion in the cloud) possible New reports, which you can use to monitor your organization’s mail flow, available in the Office 365 portal, by using a Microsoft Excel download application, or by using a Web service. Anti-Spam Protection Anti-spam protection is comprised of connection filtering, content filtering, and outbound spam processing. You can configure settings so that they are tailored to best meet the needs of your organization. Connection Filter Connection filtering is based on blocking or allowing inbound messages, based on the originating IP address. The connection filter checks IP Allow and IP Block lists prior to checking the content of each message. Messages from specifically allowed IP addresses bypass filtering. Messages from senders in the IP Block list are blocked, except in cases where they also appear in the IP Allow list. In the EAC, you can add an IP address or address range to an IP Allow list or IP Block list without hassles. You can also check Enable safe list to skip messages from trusted senders, derived from lists that Microsoft subscribes to. Content Filter Content filtering examines each part of the inbound email message, such as the header and message body, using a list of regular expressions. A score is then assigned to the message if a rule is matched. Several URL lists are also used to block messages that contain specific, suspicious URLs. You can configure actions for each confidence-threshold level by editing the default content filter policy. For example, you can send messages to the quarantine or to the Junk Email folder of each recipient. Content filtering includes international filtering, which means that you can choose to block messages written in specific languages or sent from specific countries or regions, and Advanced Spam Filtering Options, which inspects attributes in a message and acts upon the message if it matches a specific configured attribute. If you are concerned about phishing, some advanced options offer a combination of Sender ID and SPF-record technologies to authenticate and verify that messages are not spoofed. Outbound Spam Why do you need outbound spam filtering? Because malicious programmers and their malware are out there taking over computers inside corporate networks every day. This means that users in your organization can be sending large amounts of outbound spam without your knowledge. EOP includes outbound spam filtering to protect your organization and your email recipients, including your customers and partners, from spam. You can configure outbound spam settings in the EAC. Malware Filtering Malware consists of viruses and spyware, and is used to harm computer operations and collect sensitive information from victims. EOP uses multiple anti-malware scan engines to protect against malware threats. In addition to this, EOP includes a real-time threat response. This means that when outbreaks occur, the anti-malware team can write specific policy rules that detect the threat and protect your organization even before definitions are available from the anti-malware engines used by the service. EOP’s malware filter in the Exchange Administration Center allows you to customize your default company-wide malware filter policy, including how to take action on detected malware and who to notify in case malware is detected. You can also customize these notification messages. Transport Rules Your organizations may be required by law, regulatory requirements, or company policies to apply messaging policies that limit the interaction between recipients and senders, both inside and outside the organization. Using Exchange Transport rules, which replace Policy rules in FOPE, you can look for specific conditions on messages that pass through your organization and take action while messages are in transit. Transport rules let you apply messaging policies to email messages and prevent information leakage. Interesting new features for Transport rules include new predicates and actions. New predicates include those that can check the name extension for an attachment, or check for a message that exceeds a specified size. New actions include how to notify a sender in case a Transport rule is invoked, or the ability to require Transport Layer Security (TLS) on messages routed outside of your organization. Quarantine Messages that are identified as spam or that match and Exchange transport rule can be sent to the quarantine. If you are an administrator, you can search for quarantined messages, view details about quarantined messages, release specific messages to a recipient within your organization and also quickly report a quarantined message as a false positive. Message Trace What happened to the email I sent you? It’s a common question heard in any organization, from end users and IT folks. The message trace feature enables you as an administrator to follow email messages as they pass through your EOP service. It helps you determine whether a targeted email message was received, rejected, deferred, or delivered. This lets you efficiently answer your user’s questions and troubleshoot mail flow issues, and alleviates the need for users to contact technical support for assistance. Connectors You may have a situation that requires secure transmission of messages to a specific partner, or one where you have specific policies for mail traveling from your cloud mailboxes to your on-premises Exchange mailboxes, in a hybrid environment. With Inbound connectors and outbound connectors, you get fine-tuned control of mail flow, including the ability to apply security policies based on the IP address and domain of a sender or recipient. Reporting EOP offers a variety of reporting features both in and out of the Exchange Administration Center (EAC). Audit logging and reports are included in the EAC. Audit logging reports track specific changes made by administrators in order to help you meet regulatory, compliance, and litigation requirements. Additional reports are available with the Excel Download Application. You can use the Mail Protection reports for Office 365 reporting workbook to gather messaging statistics and details, if you are part of a Microsoft Office 365 Enterprise organization. After you download the workbook to your local computer and configure it, the workbook connects to your organization and retrieves messaging data. The data includes information about message traffic, spam, malware, and messages affected by transport rules. For Exchange Online customers, additional reports are available in the Office 365 portal. These include a report that shows the number of active and inactive mailboxes. (A mailbox is considered active if a user has accessed it at least once in the last 30 days.) Another shows the number of groups created and deleted by day, week, month, or year. There are also plans for additional reports, available via Web services, slated for the general availability (GA) release. Conclusion The new and improved EOP service brings anti-spam and anti-malware protection settings directly into the new EAC. EOP features include filters, reports, quarantine, troubleshooting tools, and connectors that enable you to protect your users and fine-tune your email messaging environment. Tony TrivisonHow to Configure S/MIME in Office 365
S/MIME in Office 365 S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public key encryption and digital signingof MIME data. Configuring S/MIME in Office 365 is a slightly different procedure than configuring S/MIME on-premises. This blog is for people who want to move from on-premises to Exchange Online and want to continue to use S/MIME. This article will also apply to any Office 365 customers who want to use S/MIME for sending digitally signed and encrypted mails. Configuring S/MIME will allow users to encrypt and/or digitally sign an email. S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity, non-repudiation of origin (using digital signatures), privacy, and data security (using encryption). Further, Office 365 also provides the capability for end users to compose, encrypt, decrypt, read, and digitally sign emails between two users in an organization using Outlook, Outlook Web App (OWA) or Exchange ActiveSync (EAS) clients. Below, we will take you through the configuration steps that you will need to follow to configure S/MIME for Exchange Online Only (Scenario 1), and for Exchange Hybrid(Scenario 2). Scenario 1: Exchange Online In this scenario, all the users are hosted on cloud and there is no on-premises Exchange organization. Requirements .SST File (Serialized store): The SST file contains all the root and intermediate certificates that are used when validating the S/MIME message in Office 365. The .SST file is created from certificate store explained below. End user’s certificate for signing and encrypting the message issued from Certificate Authorities(CA) either Windows based CA or Third party CA. Configuration Remember that in Exchange Online, only the SST will be used for S/MIME certificate validation. 1. Create a .SST file for the Trusted Root CA / Intermediate CA of the certificate issued to the users: You can use either Certificate MMC or PowerShellcmdlets to export SST file. I am using Certificate console to export the .SST here: Open certmgr.msc snap-in, expand Trusted Root Certificate Authorities > Certificates > select the CA Certificates which issued the certificates to end users for S/MIME and right click > All Tasks > Export… Note: There may be some Intermediate CA’s. You can move them to Trust Root CA folder and select them (including the Trusted CA certificates) and export it all in one .SST file. 2. Select Microsoft Serialized Certificate Store(.SST) > Click Next and save the SST file: 3. Upload .SST to office 365 server: Update the SST on office 365 exchange server by executing the following commands using remote PowerShell. $sst = Get-Content <sst file copied from the box>.sst -Encoding Byte (Example: $sst = Get-Content TenantRoot.sst -Encoding Byte) Set-SmimeConfig -SMIMECertificateIssuingCA $sst 4. Publish user’s certificate to the Exchange Online GAL (Global Address List) using Outlook. If not published, users will not be able to exchange S/MIME encrypted messages. Note: To publish the certificate, the user must first have the certificate installed on their local machine. On the File menu in Outlook 2013, click Options. On the Outlook Options window, click Trust Center, click Trust Center Settings..., and then click Email Security. In the Trust Center window, click Settings… (Here, you need to choose certificate issued by the CA you are going to use for S/MIME). In the Change Security Settings window, type the Security Settings Name (you can name it anything) and choose Signing and Encryption certificate. Select the appropriate certificate assigned in previous steps, leave the Algorithm default and click OK. Once the information is selected, you will notice the Default Setting is populated with Security Settings Name. Now you can click the Publish to GAL button. To publish the certificate to the GAL, click OK. 5. To confirm the certificate is published in AAD (Azure Active Directory), connect to Exchange Online using remote PowerShelland run following command. Check to make sure that the UserSMimeCertificate attribute is populated with the certificate information. If not, return to step 4. Get-Mailbox <user> | FL or FT *user* 6. Once you confirm the end user has the certificate on their machine under certificates > personal store and also published in AAD, the users can use Outlook, OWA, or EASto send and receive S/MIME messages. Note: Make sure you check S/MIME Supported Clients section below before exchanging S/MIME messages. Scenario 2: Exchange Hybrid In Exchange Hybrid topology, some mailboxes are homed on-premises and some mailboxes are homed online, and users share the same e-mail address space. Requirements: Public Key Infrastructure (PKI). You can use Active Directory Certificate Services to issue certificates to the end users. SST File (Microsoft serialized certificate store). Tenant admins will have to configure their tenant in O365 with signing certificates issuing CA & Intermediate certs information. They will have to produce a SST file, which is a collection of certificates, and then later import it into O365 to validate S/MIME. DirSync. You will need version 6593.0012 or higher of the DirSync tool. DirSync is used to synchronize the Active Directory user object to the Azure AD, so that cloud users can also see the certificate information of recipients when performing S/MIME (encrypt) operation. You can verify the DirSync version following these steps: Open Control Panel. Click Programs. Click Programs and Features. Click Windows Azure Active Directory Sync tool. Check the version as the screenshot below: Configuration: Public Key Infrastructure (PKI) The users in your organization must have certificates issued for digitally signing and encryption purposes. You can either install Certificate Authority On-premises to issue certificates to the end users or have third party certificates issued to them. There are two attributes in a user object where certificate information stored: 1) UserCertificate and 2) UserSMimeCertificate. UserCertificateis populated automatically in on-premises deployment with a Windows root CA. This is populated at the time the user enrolls for a user certificate. This could be done manually for each user, or an administrator can set a GPO to automatically enroll all users. Certificates are stored in the userSMimeCertificate attribute when an Outlook client publishes a certificate to GAL. Outlook 2010 and above will populate both attributes with the same certificate http://support.microsoft.com/kb/2840546. But Outlook 2007 and below will not. http://support.microsoft.com/kb/822504 2.When setting a SST file, remember in Exchange online, only the SST will be used for S/MIME certificate validation. Create a SST file for the Trusted Root CA / Intermediate CA of the certificate issued to the users: You can use either Certificate MMC or PowerShellcmdlets to export the SST file. I am using the Certificate console to export the SST here: Open certmgr.msc snap-in, Expand Trusted Root Certificate Authorities > Certificates > select the CA Certificates which issued the certificates to end users for S/MIME, and right click > All Tasks > Export… Note: There may be some Intermediate CA. If there are, move them to Trust Root CA folder and select them, including the Trusted CA certificates, and export them all in one .SST file. Select SST > Click Next and save the SST file: Upload .SST to Office 365 server: Update the SST on Office 365 Exchange server by running the commands below using remote PowerShell: $sst = Get-Content <sst file copied from the box>.sst -Encoding Byte (Example: $sst = Get-Content TenantRoot.sst -Encoding Byte) Set-SmimeConfig -SMIMECertificateIssuingCA $sst 3.If end users are issued third party certificates, they can publish the certificate information to the GAL by following these steps: Note: To publish the certificate, the users must first have the certificate installed on their local machine. On the File menu in Outlook 2013, click Options. On the Outlook Options window, click Trust Center, click Trust Center Settings..., then Email Security. On Trust Center window, click Settings… (Here, you need to choose which certificate you are going to use for S/MIME). In the Change Security Settings window, type the Security Settings Name (you can name it anything), Choose Signing and Encryption certificate, select the appropriate certificate assigned in previous steps, leave the Algorithm default, and click OK. Once the information is selected, you will notice the Default Setting is populated with Security Settings Name. Now you can click the Publish to GAL button. To publish the certificate to the GAL, click OK. To confirm that the certificate is published in AAD (Azure Active Directory), connect to Exchange Online using remote PowerShell and run the following command. Check to see if the UserSMimeCertificate attribute is populated with the certificate information. If not, return to step 4. Get-Mailbox <user> | FL or FT *user* If Windows Certificate Authority is used, then the CA will publish the certificate information into the user object. In both cases, you need to use DirSync to replicate the on-premises Active Directory information to the cloud so that cloud users can exchange S/MIME messages. 4. After the above steps, your end users can use Outlook, OWA, or EASto send and receive S/MIME messages. Note: Make sure you check S/MIME Supported Clients section below before exchanging S/MIME messages. S/MIME Supported Clients All the client machines should have the PKI issued user certificate installed under (whichever is applicable) Certificates - Current User - Personal - Certificates - Trusted Root Certification Authorities - Certificates - Intermediate Certification Authorities - Certificates If the PKI issued certificate is not available, users will not be able to send digitally signed messages or decrypt the S/MIME encrypted messages. Outlook Web App: OWA for S/MIME - Supported only on Windows Vista or greater with browser IE9 and above. Not supported on other browsers or on MOWA (Mobile for Outlook Web Access). Third party certificates aren’t supported for OWA S/MIME; only Windows Certificate Authority issued certificates are supported. To use Outlook Web Access with the S/MIME control, the client system on which the user is running Internet Explorer must have Outlook Web Access with the S/MIME control installed. S/MIME functionality in Outlook Web Access cannot be used on a system that does not have Outlook Web Access with the S/MIME control installed. SMIME control in OWA requires .Net 4.5. All users accessing their mailboxes using OWA should install this on their machine. .Net 4.5 can be installed from Microsoft Downloads page. Outlook Outlook 2010 and above are supported. EAS Clients Windows phone 8.1 is a supported EAS client for S/MIME. To learn how to install a certificate on Windows Phone 8.1, see Installing digital certificates. For any other devices, you need to check with the device vendors. FAQ 1. Do both of these user object attributes (UserSMIMECertificate and UserCertificate) need to be populated with certificate information? Either, or both. 2. Do we support S/MIME for Cross Org/Cross Tenant? Cross Org/Cross Tenant S/MIME is not supported in Outlook Web App and EAS (Exchange Active Sync) With Outlook, it is a supported scenario. A tenant administrator may create contact objects with associated S/MIME public certificates, for users external to their organization that’d synchronize to Office 365 directory. Also, when we are looking for certificates for recipients, we check in all the Address Books. This includes the Global Address Book (GAL), the Contact Address Book (contacts folder), as well as any other address books (which includes LDAP address books). As long as we can find an entry in an address book for the recipient and it contains a certificate that we trust, then we can use it and send S/MIME mail. Note: Certificate in Exchange online GAL (for contact) is supported, however OWA client doesn’t support this scenario at present.. 3. When I select Encrypt mail and click on Send button in Outlook/OWA, I get error saying that the sender does not have a certificate. Why? In the example below, David is a sender. He was trying to send an S/MIME encrypted email message to a couple of recipients who have certificates published in the Active Directory, but David himself doesn’t have a certificate. When he clicks Send, he gets the below error. So, when sending an S/MIME encrypted message, we always check the sender’s certificate so that the message is encrypted such that the sender himself can see it from his Outlook ‘sent items’ folder. References Understanding S/MIME Special thanks to Frank Brown, Mike Brown, Timothy Heeney, Tariq Sharif, Vikas Malhotra and Eduardo Melo for reviewing this post! Suresh KumarCalCheck - The Outlook Calendar Checking Tool
Over the past year or so I have been working on this tool - adding functionality and checks based off my experience as an Outlook engineer, and from suggestions given by other engineers. Well, this February the tool has been released so that all our customers can download and use it to check for potential problems in their calendars - which will hopefully be a real time saver when you encounter a problem with your Outlook Calendar - or with a user’s Outlook Calendar in your organization. Installation Download CalCheck from the Microsoft Download Center. Documentation: Information about the Calendar Checking Tool for Outlook (CalCheck) - Outlook | Microsoft Learn. Important: The 64-bit version of this tool is only for use with the 64-bit version of Microsoft Outlook 2010. The download is a ZIP file - just unzip it in an empty directory, open a command window in that directory, and run it. What CalCheck does The Calendar Checking Tool for Outlook (CalCheck) is a command-line program that checks Microsoft Outlook Calendars for problems. The tool opens an Outlook profile to access the Outlook Calendar. It performs various checks, such as permissions, free/busy publishing, delegate configuration, and automatic booking. Then each item in the calendar folder is checked for known problems that can cause unexpected behavior, such as meetings that appear to be missing. As CalCheck goes through this process, it generates a report that can be used to help diagnose problem items or identify trends. Checks performed The following Calendar-specific checks are performed and logged in the report: Permissions on the Calendar Delegates on the Calendar Free/Busy publishing information Direct Booking settings for the Mailbox or Calendar Total number of items in the Calendar folder The following item-level checks are performed and logged in the report: No Organizer email address No Sender email address No dispidRecurring property (causes an item to not show in the Day/Week/Month view) Time existence of the dispidApptStartWhole and dispidApptEndWhole properties No Subject for meetings that occur in the the future or for recurring meetings (a warning is logged) Message Class check (a warning is logged) dispidApptRecur (recurrence blob) is checked for time on overall start and end times, not for exceptions Check for Conflict items in the Calendar Check for duplicate items, based on certain MAPI properties Check if over 1250 recurring meetings (a warning is logged) and 1300 recurring meetings (an error is reported); 1300 is the limit Check if you are an attendee and you became the Organizer of a meeting Check meeting exception data to ensure it is the correct size Server Mode You also have the option to run CalCheck in Server Mode. In Server Mode, CalCheck attempts to open all mailboxes on the Exchange server and perform the checks listed in the "Checks Performed" section of this article. Server Mode generates a CalCheckSvr.log file, which lists the mailboxes that have errors. Additionally, CalCheck generates a separate CalCheck__.log file for each mailbox. This log file shows more mailbox-specific detail. To use Server Mode, you must use a messaging profile associated with an account that has permissions to all of the mailboxes on the specified Exchange server. To run server mode, use the “-S” command-line switch. Example Running to check a single mailbox/calendar: If you don’t specify a profile on the command line - then you will be prompted to choose a profile as in the above screenshot. Once you have chosen your profile - the tool will run - and you will see similar output as long as everything is successful: Looking at this window shows you that there is a CalCheck.log, and where to go and find it. Opening that will show some info like the following: 02/17/2012 05:09:20PM Calendar Checking Tool - Version 1.0 02/17/2012 05:09:20PM ==================================== 02/17/2012 05:13:45PM Opening mailbox: Mailbox 02/17/2012 05:13:45PM /O=Org/OU=OU/cn=Recipients/cn=Mailbox 02/17/2012 05:13:45PM Local time zone: Eastern Standard Time 02/17/2012 05:13:45PM Successfully opened the Calendar folder. 02/17/2012 05:13:45PM Processing calendar for Mailbox 02/17/2012 05:13:46PM Successfully located and opened the local free busy message for this mailbox. 02/17/2012 05:13:47PM Publishing 2 month(s) of free/busy data on the server. 02/17/2012 05:13:47PM Resource Scheduling / Automatically accept meeting requests is disabled. 02/17/2012 05:13:47PM ==================================== 02/17/2012 05:13:47PM Delegates for this mailbox: 02/17/2012 05:13:47PM =========================== 02/17/2012 05:13:47PM No delegates are set. 02/17/2012 05:13:47PM =========================== 02/17/2012 05:13:47PM Permissions on this Calendar: 02/17/2012 05:13:47PM ============================= 02/17/2012 05:13:47PM Default: None 02/17/2012 05:13:47PM Manager: Reviewer 02/17/2012 05:13:47PM Coworker1: None 02/17/2012 05:13:47PM Coworker2: Reviewer 02/17/2012 05:13:47PM Coworker3: Reviewer 02/17/2012 05:13:47PM ============================= 02/17/2012 05:13:48PM Found 1404 items in the Calendar. Processing... 02/17/2012 05:13:48PM WARNING: No Subject on this item. You may want to add a Subject to this item. 02/17/2012 05:13:48PM Properties to help investigate this reported item: 02/17/2012 05:13:48PM Subject: Location: No subject on recurring item Start Time: 01/11/2011 10:00:00PM End Time: 01/11/2011 10:30:00PM Last Modifier: Mailbox Last Modified Time: 02/04/2011 02:48:08PM Is a recurring appointment: true Sender Name: Mailbox Sender Address: /o=Org/ou=OU/cn=recipients/cn=Mailbox Organizer Name: Mailbox Organizer Address: /o=Org/ou=OU/cn=recipients/cn=Mailbox Recurrence Start: 12:00:00.000 AM 1/11/2011 Recurrence End: 12:00:00.000 AM 2/1/2011 Recurrence End Type: End After X Occurrences Number of Exceptions: 0x0000 02/17/2012 05:13:50PM ERROR: Detected a duplicate item in the Calendar. Please check this item. 02/17/2012 05:13:50PM Properties to help investigate this reported item: 02/17/2012 05:13:50PM Subject: Doctor appointment Location: Doctor’s Office Start Time: 03/04/2012 04:30:00PM End Time: 03/04/2012 06:00:00PM Last Modifier: Mailbox Last Modified Time: 08/01/2011 06:29:05PM Is a recurring appointment: false Sender Name: Mailbox Sender Address: /o=Org/ou=OU/cn=recipients/cn=Mailbox Organizer Name: Mailbox Organizer Address: /o=Org/ou=OU/cn=recipients/cn=Mailbox For problem items that are found - the report gives you information you can use to go and find the problem items so you can remove it, recreate it, or if possible - fix it, etc. Command Switches - and what they do CalCheck [-P ] [-M ] [-S ] [-A] [-F] [-R] [-V] [-No] CalCheck -? -P Profile name (If this parameter is not specified, the tool prompts you for a profile) -M Mailbox DN (If this parameter is specified, only process the mailbox that is specified) -S Server name (Process the complete server unless a mailbox is specified) -A All calendar items are output to CALCHECK.CSV -F Create a CalCheck folder, and move flagged error items to the folder -R Put a Report message that contains the CalCheck.log file in the Inbox -V Verbose output to the Command Prompt window -No To omit a calendar item test The No parameter works with "org" to omit the “Attendee becomes Organizer” test and works with "dup" to omit duplicate item detection -? Print this message Some additional tips about specific switches: “-M” You must use the legacyExchangeDN for the mailbox, and the profile you use must be for a mailbox that has permission to open that other mailbox. “-A” Will create a CSV file that includes all calendar items - one in each row. There will be several properties listed for each item that can be used to look for problems not detected by the tool: You can view all items in the Calendar by opening the CSV in Excel. You can sort and filter items based on things like start time, subject, recurring items, etc. This can be useful for finding problems that can’t be detected by CalCheck, or that currently aren’t looked for by CalCheck. If you find a problem item in the CSV, you can open the Calendar and put it into Category view to get a similar view of the Calendar in Outlook. To do this, in Outlook click the View tab, click the Change View drop down, and choose By Category. This will give a view of the Calendar like the following: This view shows all the items in the Calendar as a list - similar to looking at emails in the Inbox folder. You can sort on things here like Subject, Location, Start, and End. This can be used to find the problem item in the Calendar folder when it is difficult or impossible to find in the normal Calendar view. “-F” Will create a CalCheck folder in your folder list, and will move items marked as an Error to that folder: Items can easily be moved back to the Calendar, or can be deleted from here if not needed, or corrected if possible and then placed back in the Calendar. The general rule of thumb would be to recreate the item and delete the item that was moved out to the CalCheck folder. “-R” Will create a mail message in the Inbox folder with the CalCheck.log file attached to it. This is useful when running the tool in Server mode - as each user will get their report in their Inbox: “-No” There are two of these: “-No org” and “-No dup”: The “-No org” will omit the check for the “attendee becomes the organizer of the meeting” check. Part of this check uses the legacyExchangeDN of the mailbox. If the legacyExchangeDN has changed for any reason - like a migration - then this test will give errors for items that may not really be in error. The error that is logged by CalCheck will show both DNs. Here is an example: 12/21/2011 05:27:25PM ERROR: dispidApptStateFlags is 1, but the address for this mailbox does not match the organizer address. 12/21/2011 05:27:25PM Check to ensure the Organizer Address is correct, and whether or not this user should be the organizer. 12/21/2011 05:27:25PM Organizer Address: /o=Org1/ou=admin group 1/cn=recipients/cn=user1 12/21/2011 05:27:25PM DN for this user: /o=Org2/ou=admin group 2/cn=recipients/cn=user1 12/21/2011 05:27:25PM See KB 2563324 for additional information: http://support.microsoft.com/default.aspx?scid=kb;EN-US;2563324 12/21/2011 05:27:25PM Properties to help investigate this reported item: 12/21/2011 05:27:25PM Subject: Test The mailbox here is the same actual mailbox - but because the legacyExchangeDN changed - it is marked as an error. The “-No dup” will omit the duplicate item detection - as this test creates an in-memory list of items and tests each item against that list. This can slow the process down a bit due to the extra processing and memory usage. What CalCheck does not do CalCheck is a reporting tool only. It will not automatically modify or “fix” any items. It will move items detected as error items to the CalCheck folder if the “-F” switch is used, but otherwise no changes will be made to any items. CalCheck only works against Calendars located on an Exchange server. It will not work against other servers, such as IMAP or POP3, etc. CalCheck can’t find every kind of corruption that can possibly happen to a Calendar item. However - it can find many known problems that can be knocked out without having to spend time combing through a Calendar and/or contacting a help desk. Feedback Tool official documentation: Information about the Calendar Checking Tool for Outlook (CalCheck) - Outlook | Microsoft Learn Thanks - and I hope this will help save time in diagnosing and resolving calendar issues for you! Randy Topken Senior Escalation Engineer Outlook teamIn-Place eDiscovery and In-Place Hold in the New Exchange; Part II
In Part I of this post, we covered what’s new in In-Place eDiscovery in the new Exchange. In this post, let’s take a look at how the new Exchange retains data immutably. One of the first steps you must take when reasonable expectation of litigation exists or when served an eDiscovery request is to preserve messaging records so they can be produced when required. Before Exchange 2010, this was generally achieved using different methods, including archiving data to an external system, suspending automated deletion mechanism (such as Exchange’s Messaging Records Management), or in some cases - by instructing users to not delete records. Failure to preserve records required for litigation may expose your organization to legal and financial risk. In Exchange 2010 and Office 365, we introduced Litigation Hold to enable you to preserve messaging records. Litigation Hold is a mailbox property – placing a mailbox on litigation hold places all items in a mailbox on hold indefinitely (or until hold is removed), resulting in accumulation of a large volume of data – all of which may not be required to be preserved. In the new Exchange, you can use In-Place Hold to retain items immutably. In-Place Hold is integrated with In-Place eDiscovery, allowing you to perform both search and hold using the same interface and the same query parameters. You can use In-Place Hold in the following scenarios. Indefinite Hold: You can create an In-Place Hold without any query parameters and without a hold duration to hold all items in a mailbox indefinitely or until the hold is removed. This emulates the behavior of litigation hold. Query-Based Hold: Using In-Place Hold, you can create a search query and specify the source mailboxes and parameters such as keywords, senders and recipients, as well as start and end dates. You can also specify the type of items to search – email messages, calendar items such as meetings and appointments, tasks, notes, or Lync content archived in Exchange mailboxes. Time-Based Hold: Whereas Litigation Hold placed all mailbox contents on hold indefinitely or until you remove the hold, In-Place Hold allows you to specify a duration of time for which to hold items. The time is calculated based on the received date or the date the item was created in the mailbox (for items such as appointments, tasks and notes that are not sent/received). One of the more common feature requests in Exchange 2010 was to be able to specify a definite time period for which an item is retained. Whereas retention policies allow you to specify the email lifecycle and automatically delete items when the specified period is reached, they don’t guarantee retention for that period. In other words, you could specify items will be kept for a maximum of 7 years, but you couldn’t guarantee items won’t be deleted before that period by a user or a process. The commonly recommended workaround to meet this requirement was to use configure the Deleted Item Recovery period to the minimum period you want an item to be retained for. In this example, setting the deleted item retention period to 7 years means if a user deletes an item before 7 years, it is retained in the Recoverable Items folder for 7 years. However, the period for Deleted Item Retention is calculated from the date of deletion. If a user deletes an item after 6 years, it is retained for an additional 7 years in the Recoverable Items folder, resulting in a total retention period of 13 years. In others words, you can guarantee an item will be retained for a minimum of 7 years, but not the maximum retention period. In the new Exchange, when you create a time-based In-Place Hold, because the hold period is calculated from the item received/creation date, you can guarantee the item won’t be held beyond that period. You can combine a time-based In-Place Hold with a Retention Policy (that has a single default policy tag) to ensure items in the mailbox are deleted by the Managed Folder Assistant (MFA) after 7 years, and items deleted by a user or a process before that period are retained for at least the specified duration. You can also combine a query-based In-Place Hold with a time-based hold to preserved items matching query parameters for the specified period. You can also place a user on multiple holds - for example, when a mailbox may contain records pertaining to multiple cases or investigations. In-Place Hold & Permissions Like In-Place eDiscovery, In-Place Hold can be used by authorized users with delegated Discovery Management permission. However, there’s a slight twist. The Discovery Management role group is assigned the Mailbox Search and Litigation Hold management roles. The former allows an authorized user to create a mailbox search for In-Place eDiscovery and Hold. The latter actually allows you to place mailbox content on hold. If a user is only assigned the Litigation Hold role, for example by creating a custom role-based access control (RBAC) role group or via membership of a role group such as Organization Management that has the Litigation Hold role assigned, the user is able to use In-Place Hold - but only to place all mailbox content on hold. The user can’t specify query parameters. In other words, the user can’t create a query-based In-Place Hold. Creating an In-Place Hold Let’s go back to the query Robin created in Part I of this post. When creating the In-Place Hold, on the Mailboxes page Robin must select Specify mailboxes to search and select the mailboxes or distribution groups. If she selects Search all mailboxes, the option to place content on hold will not be available. You must specify mailboxes or distribution groups to place on hold. If you select Search all mailboxes, the option to place content on hold will not be available. Figure 1: To create an In-Place Hold, you must select Specify mailboxes to search Note: If you select a distribution group, the hold applies to mailbox users that are members of the group when the hold is created. On the Search query page, Robin can use the same query she used for the In-Place eDiscovery. Figure 2: Messages matching query parameters are preserved She can also select the message types to place on hold. Figure 3: You can specify the message types to hold or hold all message types Placing archived Lync content on hold If the new Lync is enabled to archive Instant Messaging and meeting content into the new Exchange, Lync content is archived in the user’s mailbox and automatically placed on hold. You need to configure OAuth authentication between Lync and Exchange to enable this. Additionally, the mailbox must be located on a Mailbox server in the new Exchange. On the In-Place Hold settings page, Robin selects the option to Place content matching the search query in selected mailboxes on hold. She can then select Hold indefinitely to hold content indefinitely (or until the In-Place Hold is removed or a mailbox is removed from the search). To hold items for a specific period, she can select Specify number of days to hold items relative to their received date and specify the number of days. Figure 4: You can specify a hold duration or hold items indefinitely It’s important to reiterate here that for the time-based hold, the duration is calculated from the date a message is received/created. How In-Place Hold Works Let’s take a look at what happens under the hood. When a user deletes a message, it goes to the Deleted Items folder. When the Deleted Items folder is emptied or messages are deleted from it, or the user uses Shift-Delete to delete a message, it is moved to the Recoverable Items\Deletes folder. Contents of this folder are exposed when the user uses Recover Deleted Items in Outlook or Outlook Web App. If the user doesn’t do anything, messages from the Deletes folder are purged when the Deleted Items Retention period configured for the mailbox database or the user expires. If the user deletes a message from this view, few things can happen: If Single Item Recovery is enabled for the mailbox, the item is moved to the Recoverable Items\Purges folder and retained until the deleted item retention period expires. This provides the administrator the capability to recover items without having to recover from backups. If the mailbox is placed on Litigation Hold, the items is moved to the Recoverable Items\Purges folder and retained until the hold is removed. If the mailbox is placed on an In-Place Hold, the item is moved to the Recoverable Items\DiscoveryHolds folder. Figure 5: Deleted items and original copies of modified items are preserved in the Recoverable Items folder of each mailbox When the MFA , a mailbox assistant that processes mailboxes and expires content, processes the mailbox, it checks if messages meet the query parameters of any In-Place Holds the user is placed on. This evaluation is done for up to 5 queries, beyond which all items are retained – emulating the same behavior as litigation hold. If the number of holds is brought below 5, the MFA again reverts to the query-based In-Place Hold behavior. When the In-Place Hold is removed, messages placed on hold are removed if they no longer match query parameters of any other In-Place Hold that the user may have been placed on. In-Place Hold and Immutability When talking about preservation, the concept of immutability invariably comes up. Immutability means messages placed on hold must be preserved without alteration. Not only should we prevent them from deletion (even if the user placed on hold thinks they’ve successfully purged the message), but the messages should also be prevented from tampering or alteration. Immutability is not a product feature but a combination of feature and the hold processes your organization implements. In-Place Hold also helps you preserve content from intentional tampering or modification. This is achieved by performing a copy-on-write (COW) – when the user or any process attempts to modify a message, before the modified message is saved a copy of the original message is made and saved in the Recoverable Items\Versions folder. Items captured in the Versions folder are also indexed and returned in an In-Place eDiscovery search. When the hold is removed, the copies made in the Versions folder are also removed by the Managed Folder Assistant. Together, In-Place Hold and In-Place eDiscovery provide an easy-to-use mechanism for authorized legal, human resources or other non-technical personnel to easily search and immutably preserve messaging records. Bharat Suneja and Julian Zbogar-SmithNow Available: Office 365 Mail Flow Troubleshooter
Can't send or receive email? The Mail Flow Guided Walkthrough (GWT) can help. Problems with mail delivery can be a very frustrating for both the user and the administrator. Unfortunately, mail flow issues aren't uncommon and will likely occur at some point in time whether your mailboxes are hosted on-premises, in Office 365, or a combination of both. To help you troubleshoot mailflow issues, we've just released the Mail Flow Guided Walkthrough (GWT). You can use the walkthrough for troubleshooting issues sending and receiving mail or when mail is delayed in the following scenarios: The sender’s mailbox is hosted on Office 365 and the recipient’s mailbox is outside your organization. The sender’s mailbox is outside your organization and the recipient’s mailbox is hosted in Office 365. The sender’s and recipient’s mailboxes are both located in Office 365. The sender’s mailbox is hosted in Office 365 and the recipient’s mailbox is located on an on-premise Exchange server and both users are in the same organization. The sender’s mailbox is hosted on an on-premise Exchange server and the recipient’s mailbox is hosted in Office 365 and both users are in the same organization. The goal of this walkthrough is to assist you in resolving these issues in a timely manner by focusing on the scoping and steps used to isolate and resolve problems. I’d like to thank everyone who contributed to the development of this troubleshooter with special recognition going to the following folks: Tom Kern, Nitin Shukla, Sainath Vijayaraghavan, Jim Martin, Bruce Wilson, Stephen Gilbert, Scott Landry, Charlotte Raymundo, Mary Browning, Star Li, Chen Jiang, Victor Zhang. Joe Turick
