Announcing the support for modern public folder migrations without dumpster data
Long time Exchange administrators will remember that Exchange Server had a feature that was for a while unceremoniously referred to as the “dumpster”. We have since renamed the feature to a more descriptive Recoverable Items Folder. This blog post also contains a bit of history of this feature for those interested. Up to now, during public folder migration, all the public folder data including dumpsters was migrated from on-premises servers to the cloud. Administrators did not have an option to exclude this data at migration. We are introducing the ability to migrate public folders to cloud without migrating the dumpster data. To do this, administrators need to pass the ExcludeDumpsters parameter while creating the migration batch. This option can be used when source server version is Exchange 2013 or 2016. Here is an example of how to use this parameter: New-MigrationBatch -Name PublicFolderMigration -CSVData $bytes -SourceEndpoint $PfEndpoint.Identity -ExcludeDumpsters Note: Please do not use -ExcludeDumpster parameter if you expect users or admins to restore deleted public folders during the migration. The migration batch will fail with error “ErrorFoldersRestoredDuringMigrationPermanentException” if users/admins restore deleted public folder while migration is still in progress. See this article for more information. Why would you want to do this? Excluding this data can help you scale your public folder migration if you do not need the data to come over. This will result in faster public folder migration as the amount of data that will need to be migrated is going to be smaller. To check the dumpster folders size, you can run the following: Get-PublicFolder \NON_IPM_SUBTREE\DUMPSTER_ROOT -Recurse -ResultSize:unlimited | ?{$_.FolderClass -ne "$null"} | ft name,foldersize In addition to size consideration, we have seen some organizations where dumpster data got corrupted (for various reasons) and administrators did not want that corrupted data migrated to cloud. If you find yourself in that situation, this feature will enable you to leave that data behind. The obvious drawback to doing this is that users will lose the ability to recover items that were previous deleted from public folders (pre-migration). Note: The ExcludeDumpsters parameter is optional and if not passed to migration batch, all dumpsters will migrate to cloud. Once you choose to exclude dumpsters and the migration is finalized, there is no way to go back and re-include the dumpsters into cloud public folders. If, during the migration in which you used the ExcludeDumpsters parameter, you decide that you do want to migrate the dumpsters data to the cloud, remove the current migration batch and create another without the ExcludeDumpsters parameter. This option can be added at point 4 of Step 7 in below TechNet articles for public folder migration (we will work to change the documentation next): Use batch migration to migrate Exchange 2013 public folders to Exchange Online Use batch migration to migrate Exchange 2016 public folders to Exchange Online Keep checking this blog for further updates on the subject! In case of any questions, please do reach out to us via the comments section below. Public folder teamOutlook REST API beta and Outlook REST API v2.0 Deprecation Notice
Today we are announcing the deprecation of the Outlook REST API beta and Outlook REST API v2.0 and that they will be decommissioned on November 30, 2022. Once past this date, the services will be retired, and developers may no longer access them.Announcing the Microsoft Solutions Advisory Board
Microsoft Office Content Publishing is now producing guidance on cross-product solutions involving Exchange Server 2013, SharePoint 2013, Lync Server 2013, Office 365, and Windows Azure. Our goal is to help our customers solve bigger business problems than could be solved through any of these products individually. We have some ideas regarding what solutions to get started on but we need your input to find out if these are the right ones and what other ones we should do. We are forming a Solutions Advisory Board (SAB) consisting of customers, Microsoft Most Valuable Professionals (MVPs), and people in various roles inside of Microsoft. The SAB will: Send out newsletters on a regular basis about upcoming solutions, and suggestions for new ones. Host regular online meetings in which: Microsoft presents ideas for solutions to the group and collects your feedback Microsoft opens the floor to SAB members to present their requests for solutions SAB members can showcase their own solutions (and businesses) to the SAB Send out an annual survey for the members to complete If you would like to participate in the discussion around solutions that use any combination of Exchange 2013, SharePoint 2013, Lync Server 2013, Office 365, or Windows Azure, we invite you to join this new group. Please contact us at sab@microsoft.com to join. Office Solutions Content TeamNew Exchange Online migration options
We are in the process of rolling out a new migration experience that will greatly simplify your journey to Office 365 and Exchange Online. This new experience will help any customer running at least one Exchange 2010, 2013 and/or 2016 server on-premises to migrate to the cloud seamlessly. When you initiate the migration, we evaluate what you have configured already in Exchange Online and we walk you through the Hybrid Configuration Wizard to evaluate the on-premises environment. Once all the information on your current state is collected, we ask a couple of questions about your desired state (things like how fast you want to move to Exchange Online and whether you require advanced features). The hybrid wizard then walks you through the configuration needed to migrate your users to Exchange Online. Based on your current configuration and the options selected while running the hybrid wizard, you will be taken down one of the following paths. Full Hybrid: This is a common configuration for customers that are larger in size and will take some time to migrate or customers that will not be able to move all their mailboxes to Exchange Online in the short to medium term. This is the most complex option to configure, but will give you enhanced features like cross-premises free/busy and enhanced mail flow options. For more on Full Hybrid you can go here. Minimal Hybrid: This is a recently introduced option that was added to the Hybrid Configuration Wizard in June. It allows you to configure your environment to support hybrid migrations and recipient administration without the need for the additional overhead of configuring free/busy and other enhanced features of full hybrid. Often this is used for customers that want to move all their mailboxes to Exchange Online over the course of a couple of months or less, but want to keep directory synchronization in place. For more information on Minimal Hybrid please go here. Express Migration: The newest option we have added is the Express Migration. This is the path in the Hybrid Configuration Wizard that will benefit smaller customers or a customer that truly wants to move to Exchange Online over the course of a couple of weeks or less. If you have a need to keep directory synchronization in place, then this is not the option for you. This option will configure your users and walk you through the new migration experience to get the mailboxes to Exchange Online with minimal disruption for your users. More About Express Migration In the past, an administrator of the small to medium business had to choose to either take the complex configuration route of hybrid or the complex user experience of a cutover or staged migration. Now you can get a greatly simplified Express Migration experience. With the Express Migration option, you will get a onetime directory synchronization of your users along with the Minimal Hybrid configuration to allow you to perform the migrations. After that initial synchronization of user accounts, directory synchronization will be automatically disabled in both Office 365 and on-premises. This will give small and medium customers that would have previously perform a cutover migration the ability to get the benefits of the hybrid migration without the overhead. The following are the benefits of performing an Express Migration over a more traditional cutover migration: Usernames and passwords will sync from on-premises Users will not have to recreate Outlook profiles Mail flow will continue to work between users before, during, and after the migration There is essentially no down time for users during the migration How to initiate the migration All the migration approaches discussed in this article (Full, Minimal, and Express) can be initiated from one interface now. We will guide you to the proper option as we go. One of key components in this new experience is the migration pane. This is a new pane we have created in the Office 365 Admin Portal that will match the modern look and feel of the rest of the portal. However, it is not just the look and feel that is revamped, we also have a lot of intelligence built in. For instance, when you enter the migration pane we will detect if you have executed the Hybrid Configuration Wizard, already synchronized your users, and whether there is a migration endpoint already created. Depending on what is already in place we can take you toward the proper migration approach. To get to the new migration experience you will have to expand the “Users” section in the portal (Http://portal.office.com) and then select the “Data Migration” option. Once there, select the Exchange email source to initiate the experience. This is a page where we list various sources from where you can migrate. In this case, you would select the Exchange option. Once the source is selected we perform a quick check of the tenant to see if you have executed the Hybrid Configuration Wizard. If you have not yet executed it, that means we know you have not prepared your on-premises environment for migration. Therefore, we will take you through downloading and running the hybrid wizard. When in the hybrid wizard you will see a welcome screen, just select next on that: You will then see the Server detection screen, again just select next since the correct server should be detected. By default, we will try to connect to the Exchange server running the latest version. Provide your credentials for both Exchange on-premises and Exchange Online. Select the appropriate migration option. For this example, we are demonstrating Express Migration so we will select the Minimal Hybrid option. Select update, which will perform all the configurations needed to allow you to start moving mailboxes at a later step. Next up: Provisioning users If you have not synchronized your users already at this point you will see an option to perform a onetime sync of your users or to install AAD Connect separately. As mentioned, if you plan on moving all of your mailboxes to Exchange Online and do not have the need to keep directory synchronization around, then select the one-time sync option. Selecting this option is what we consider an “Express Migration”. If you need directory synchronization for any reason, then you need to install and setup AAD Connect separately. Note: if you did select the one-time sync and later decided that you do need to have directory synchronization, you can setup AAD Connect to perform directory synchronization. If you did not select Minimal Hybrid as an option in the wizard, then you will not be given the one-time directory synchronization option. The reason you would not get it if you opted for Full Hybrid is because that deployment scenario requires the advanced coexistence features and directory synchronization. Once the option for “Synchronize my users and passwords one time” is selected, the hybrid wizard displays a progress bar. The wizard is waiting for the AAD Connect to be configured and for the initial set of users to synchronize. To complete the hybrid configuration setup, you will need to configure AAD Connect. In almost all cases the default options in AAD Connect are the best options. Once completed you will see the ending page for the hybrid application that will allow you to give feedback. Once closed you will be taken to the user list page to start moving mailboxes. On the user list page you will have the option to select the users you want to migrate. Under the hood this is using MRS to migrate the users just like a hybrid migration. You can use this new pane to migrate mailboxes, regardless of the hybrid deployment option chosen. The experience is as simple as selecting the users and clicking start migration. At that time, we will perform a lookup to see if the prerequisites are in place. If anything is missing, we will walk you through taking care of the missing prerequisite. Limitations There are some limitations with the new Migration pane that need to be called out. We are working to overcome these limitations in the future: Only one migration endpoint is supported: If there is more than one endpoint we will choose the one created by the Hybrid wizard or by the new Migration experience. Only one batch can be started at a time: we do not yet support multiple batches with this migration pane. This means that you need to wait for the previous migration to finish before you can start another migration. We know multiple batch support is important for medium and larger customers, we have this as a top priority. We do require you license users separately: we require that all users being migrated through this experience be licensed before the migration begins (except for shared mailbox object type), this is not an automatic process so you need to license users before migrating. Conclusion These updates will make the Exchange Online onboarding experience more seamless for many Exchange customers. We have created and are continuing to improve the Migration pane to meet the needs of our customers. While running through the experience if you have any feedback please use the provided feedback button that are available throughout the experience. Office 365 On-boarding TeamLife in a Post TMG World – Is It As Scary As You Think?
Let’s start this post about Exchange with a common question: Now that Microsoft has stopped selling TMG, should I rip it out and find something else to publish Exchange with? I have occasionally tried to answer this question with an analogy. Let’s try it. My car (let’s call it Threat Management Gateway, or TMG for short), isn’t actively developed or sold any more (like TMG). However, it (TMG) works fine right now, it does what I need (publishes Exchange securely) and I can get parts for it and have it serviced as needed (extended support for TMG ends 2020) and so I ‘m keeping it. When it eventually either doesn’t meet my requirements (I want to publish something it can’t do) or runs out of life (2020, but it could be later if I am ok to accept the risk of no support) then I’ll replace it. Now, it might seem odd to offer up a car analogy to explain why Microsoft no longer selling TMG is not a reason for Exchange customers to panic, but I hope you’ll agree, it works, and leads you to conclude that when something stops being sold, like your car, it doesn’t immediately mean you replace it, but instead think about the situation and decide what to do next. You might well decide to go ahead and replace TMG simply based on our decision to stop selling or updating it, that’s fine, but just make sure you are thinking the decision through. Of course, you might also decide not to buy another car. Your needs have changed. Think about that. Here are some interesting Exchange-related facts to help further cement the idea I’m eventually going to get to. We do not require traffic to be authenticated prior to hitting services in front of Exchange Online. We do not do any form of pre-authentication of services in front of our corporate, on-premises messaging deployments either. We have spent an awfully large amount of time as a company working on securing our code, writing secure code, testing our code for security, and understanding the threats that exist to our code. This is why we feel confident enough to do #1 and #2. We have come to learn that adding layers of security often adds little additional security, but certainly lots of complexity. We have invested in getting our policies right and monitoring our systems. This basically says we didn’t buy another car when ours didn’t meet our needs any more. We don’t use TMG to protect ourselves any more. Why did we decide that? To explain that, you have to cast your mind back to the days of Exchange and Windows 2000. The first thing to admit is that our code was less ‘optimal’ (that’s a polite way of putting it), and there were security issues caused by anonymous access. So, how did we (Exchange) tell you to guard against them? By using something called ISA (Internet Security and Acceleration – which is an odd name for what it was, a firewall). ISA, amongst other things, did pre-authentication of connections. It forced users to authenticate to it, so it could then allow only authenticated users access to Exchange. It essentially stopped anonymous users getting to Windows and Exchange. Which was good for Windows and Exchange, because there were all kinds of things that they could do if they got there anonymously. However once authenticated users got access, they too could still do those bad things if they chose to. And so of course could anyone not coming through ISA, such as internal users. So why would you use ISA? It was so that you would know who these external users were wouldn’t you? But do you really think that’s true? Do you think most customers a) noticed something bad was going on and b) trawled logs to find out who it was who did it? No, they didn’t. So it was a bit like an insurance policy. You bought it, you knew you had it, you didn’t really check to see if it covers what you were doing until you needed it, and by then, it was too late, you found out your policy didn’t cover that scenario and you were in the deep doo doo. Insurance alone is not enough. If you put any security device in front of anything, it doesn’t mean you can or should just walk away and call it secure. So at around the same time as we were telling customers to use ISA, back in the 2000 days, the whole millennium bug thing was over, and the proliferation of the PC, and the Internet was continuing to expand. This is a very nice write up on the Microsoft view of the world. Those industry changes ultimately resulted in something we called Trustworthy Computing. Which was all about changing the way we develop software – “The data our software and services store on behalf of our customers should be protected from harm and used or modified only in appropriate ways. Security models should be easy for developers to understand and build into their applications.” There was also the Secure Windows Initiative. And the Security Development Lifecycle. And many other three letter acronyms I’m sure, because whatever it was you did, it needed a good TLA. We made a lot of progress over those ten years since then. We delivered on the goal that the security of the application can be better managed inside the OS and the application rather than at the network layer. But of course most people still seem to think of security as being mainly at the network layer, so think for a moment about what your hardware/software/appliance based firewall does today. It allows connections from a destination, on some configurable protocol/port, to a configured destination protocol/port. If you have a load balancer, and you configure it to allow inbound connections to an IP on its external interface, to TCP 443 specifically, telling it to ignore everything else, and it takes those packets and forward them to your Exchange servers, is that not the same thing as a firewall? Your load balancer is a packet filtering firewall. Don’t tell your load balancing vendor that, they might want to charge you extra for it, but it is. And when you couple that packet level filtering firewall/load balancer with software behind it that has been hardened for 10 years against attacks, you have a pretty darn secure setup. And that is the point. If you hang one leg of your load balancer on the Internet, and one leg on your LAN, and you operate a secure and well managed Windows/Exchange Server – you have a more secure environment than you think. Adding pre-authentication and layers of networking complexity in front of that buys you very little extra, if anything. So let’s apply this directly to Exchange, and try and offer you some advice from all of this. What should YOU do? The first thing to realize is that you now have a CHOICE. And the real goal of this post is to help you make an INFORMED choice. If you understand the risks, and know what you can and cannot do to mitigate them, you can make better decisions. Do I think everyone should throw out that TMG box they have today and go firewall commando? No. not at all. I think they should evaluate what it does for them, and, if they need it going forward. If they do that, and decide they still want pre-auth, then find something that can do it, when the time to replace TMG comes. You could consider it a sliding scale, of choice. Something like this perhaps; So this illustrated that there are some options and choices; Just use a load balancer – as discussed previously, a load balancer only allowing in specified traffic, is a packet filtering firewall. You can’t just put it there and leave it though, you need to make sure you keep it up to date, your servers up to date and possibly employ some form of IDS solution to tell you if there’s a problem. This is what Office 365 does. TMG/UAG – at the other end of the scale are the old school ‘application level’ firewall products. Microsoft has stopped selling TMG, but as I said earlier, that doesn’t mean you can’t use it if you already have it, and it doesn’t stop you using it if you buy an appliance with it embedded. In the middle of these two extremes (though ARR is further to the left of the spectrum as shown in the diagram) are some other options. Some load balancing vendors offer pre-authentication modules, if you absolutely must have pre-auth (but again, really… you should question the reason), some use LDAP, some require domain joining the appliance and using Kerberos Constrained Delegation, and Microsoft has two options here too. The first, (and favored by pirates the world over) is Application Request Routing, or ARR! for short. ARR! (the ! is my own addition, marketing didn’t add that to the acronym but if marketing were run by pirates, they would have) “is a proxy based routing module that forwards HTTP requests to application servers based on HTTP headers and server variables, and load balance algorithms” – read about it here, and in the series of blog posts we’ll be posting here in the not too distant future. It is a reverse proxy. It does not do pre-authentication, but it does let you put a non-domain joined machine in front of Exchange to terminate the SSL, if your 1990’s style security policy absolutely requires it, ARR is an option. The second is WAP. Another TLA. Recently announced at TechEd 2013 in New Orleans is the upcoming Windows Server 2012 R2 feature – Web Application Proxy. A Windows 2012 feature that is focused on browser and device based access and with strong ADFS support and WAP is the direction the Windows team are investing in these days. It can currently offer pre-authentication for OWA access, but not for Outlook Anywhere or ActiveSync. See a video of the TechEd session here (the US session) and here (the Europe session). Of course all this does raise some tough questions. So let’s try and answer a few of those; Q: I hear what you are saying, but Windows is totally insecure, my security guy told me so. A: Yes, he’s right. Well he was right, in the yesteryear world in which he formed that opinion. But times have changed, and when was the last time he verified that belief? Is it still true? Do things change in this industry? Q: My security guy says Microsoft keeps releasing security patches and surely that’s a sign that their software is full of holes? A: Or is the opposite true? All software has the potential for bugs and exploits, and not telling customers about risks, or releasing patches for issues discovered is negligent. Microsoft takes the view that informed customers are safer customers, and making vulnerabilities and mitigations known is the best way of protecting against them. Q: My security guy says he can’t keep up with the patches and so he wants to make the server ‘secure’ and then leave it alone. Is that a good idea? A: No. It’s not (I hope) what he does with his routers and hardware based firewalls is it? Software is a point in time piece of code. Security software guards against exploits and attacks it knows of today. What about tomorrow? None of us are saying Windows, or any other vendor’s solution is secure forever, which is why a well-managed and secure network keeps machines monitored and patched. If he does not patch other devices in the chain, overall security is compromised. Patches are the reality of life today, and they are the way we keep up with the bad guys. Q: My security guy says his hardware based firewall appliance is much more secure than any Windows box. A: Sure. Right up to the point at which that device has a vulnerability exposed. Any security device is only as secure as the code that was written to counter the threats known at that time. After that, then it’s all the same, they can all be exploited. Q: My security guy says I can’t have traffic going all the way through his 2 layers of DMZ and multitude of devices, because it is policy. It is more secure if it gets terminated and inspected at every level. A: Policy. I love it when I hear that. Who made the policy? And when? Was it a few years back? Have the business requirements changed since then? Have the risks they saw back then changed any? Sure, they have, but rarely does the policy get updated. It’s very hard to change the entire architecture for Exchange, but I think it’s fair to question the policy. If they must have multiple layers, for whatever perceived benefit that gives (ask them what it really does, and how they know when a layer has been breached), there are ways to do that, but one could argue that more layers doesn’t necessarily make it better, it just makes it harder. Harder to monitor, and to manage. Q: My security guy says if I don’t allow access from outside except through a VPN, we are more secure. A: But every client who connects via a VPN adds one more gateway/endpoint to the network don’t they? And they have access to everything on the network rather than just to a single port/protocol. How is that necessarily more secure? Plus, how many users like VPN’s? Does making it harder to connect and get email, so people can do their job, make them more productive? No, it usually means they might do less work as they cannot bothered to input a little code, just so they can check email. Q: My security guy says if we allow users to authenticate from the Internet to Exchange then we will be exposed to an account lockout Denial of Service (DoS). A: Yes, he’s right. Well, he’s right only because account lockout policies are being used, something we’ve been advising against for years, as they invite account lockout DoS’s. These days, users typically have their SMTP address set to equal their User Principal Name (UPN) so they can log on with (what they think is) their email address. If you know someone’s email address, you know their account logon name. Is that a problem? Well, only if you use account lockout policies rather than using strong password/phrases and monitoring. That’s what we have been telling people for years. But many security people feel that account lockouts are their first line of defense against dictionary attacks trying to steal passwords. In fact, you could also argue that a bad guy trying out passwords and getting locked out now knows the account he’s trying is valid… Note the common theme in these questions is obviously – “the security g uy said…..”. And it’s not that I have it in for security guys generally speaking, but given they are the people who ask these questions, and in my experience some of them think their job is to secure access by preventing access. If you can’t get to it, it must be safe right? Wrong. Their job is to secure the business requirements. Or put another way, to allow their business to do their work, securely. After all, most businesses are not in the business of security. They make pencils. Or cupcakes. Or do something else. And is the job of the security folks working at those companies to help them make pencils, or cupcakes, securely, and not to stop them from doing those things? So there you go, you have choices. What should you choose? I’m fine with you choosing any of them, but only if you choose the one that meets your needs, based on your comfort with risk, based on your operational level of skill, and based on your budget. Greg Taylor Principal Program Manager Lead Exchange Customer Adoption Team
