Why is OOF an OOF and not an OOO?
Here's an interesting historical question - when we say Out of Office, why does it sometimes get shortened to ‘OOF’? Shouldn’t it be ‘OOO’? Inside Microsoft, ‘OOF’ means not just the message which says you’re Out of Office, but it has grown to mean the act of being Out of the Office too - so you’ll get people putting sticky notes on their door saying ‘OOF Thurs & Fri’ or even people verbally saying things like, "Oh, Kevin’s OOF on vacation for the rest of the week’. I suppose that sounds better than "Oh, Kevin’s OOO on vacation ..." OOF was a command used in the days of Microsoft’s Xenix mail system, which set a user as ‘Out of Facility’ - ie Out of the Office. The usage of the term ‘OOF’ just stuck, as did the term ‘Little r’ (e.g. on an email sent to a distribution list, "Who wants to go to the cinema tonight? Little ‘r’ if you’re interested", meaning reply just to me) - as preserved in Outlook with CTRL+R for Reply, and CTRL+SHIFT+R (aka Big R) for Reply All. Ewan DaltonHow to Export and Import mailboxes to PST files in Exchange 2007 SP1
There might be times when an Exchange Administrator will need to export the contents of individual mailboxes to offline files in order to present specific users with a format that is easily portable and ready to consume using Outlook clients. To fulfill this need Exchange 2007 SP1 will have a new set of features to export and import mailboxes to and from PST files. As I know you will ask - yes, those PST files can be bigger than 2 GB, which was a limitation of Exmerge tool used for this purpose in previous versions of Exchange. Export/Import to PST Requirements In order to export or import mailboxes to PST files the following requirements must be met: Export/Import to PST must be run from a 32 bit client machine with Exchange Management Tools installed (Version Exchange 2007 SP1 or later). The 32bit requirement comes from a dependency with the Outlook client. Either Outlook 2003 or Outlook 2007 must be installed on the client machine. The user running the task must be an Exchange Organization Admin or an Exchange Server Admin on the server where the mailbox to export/import lives. Exporting mailboxes to PST files The most basic cmdlet to export a mailbox to a PST file is as follows: Export-Mailbox –Identity <mailboxUser> -PSTFolderPath <pathToSavePST> PSTFolderPath must be a full path pointing either to a directory or to a (.pst) file. If a directory is specified a PST file named after the mailbox alias will be used as the target of the export. Note that if the PST file already exists the contents of the mailbox will be merged into it. Example: After the cmdlet finishes execution, the .pst file will be ready in the specified location: To export multiple mailboxes to their respective .pst files at once you can pipe in the identities of those mailboxes to the export task. Notice that when bulk exporting the PSTFolderPath parameter must forcefully point to a directory since one .pst file will be created for each mailbox. Example: Get-Mailbox -Database 'MDB' | Export-Mailbox -PSTFolderPath D:\PSTs Importing mailboxes from PST files The process for importing mailbox contents from a PST file is quite similar: Import-Mailbox -Identity <mailboxUser> -PSTFolderPath <PSTFileLocation> Again, PSTFolderPath must be the full path to the directory where the .pst file lives or to the (.pst) file itself. In the case where PSTFolderPath points to a directory the cmdlet will try to match the mailbox alias with the name of an existing .pst file in the specified directory and import the content of that file. Example: Just as with the export to PST scenario, when bulk importing mailboxes the PSTFolderPath must forcefully point to a directory and the task logic will try to match mailboxes alias with the .pst file names under that location. If no match is found for a particular mailbox, that mailbox will be skipped. Example: Get-Mailbox -Database 'MDB' | Import-Mailbox -PSTFolderPath D:\PSTs Filtering content in Export/Import to PST When only specific content is desired in the PST file (or back into the mailbox) a common set of filters can be used to leave out the rest of the messages. Export/Import to PST support the following filters: Locale, StartDate, EndDate, ContentKeywords, SubjectKeywords, AttachmentFileNames, AllContentKeywords, SenderKeywords, and RecipientKeywords. Example: Import only those messages that were created between 1/1/06 and 12/1/06 and contain the word "review" in the subject and any of the words {"project","alpha"} in the body. Import-mailbox -Identity ricardr -PSTFolderPath D:\PSTs -StartDate 1/1/06 -EndDate 12/1/06 -SubjectKeywords:'review' -ContentKeywords:'project','alpha' Now, we realize that you would like to try this today, but please be patient! - Ricardo Rosales GuerreroMe Too!
One way of telling how long a Microsoft employee has been working here is their reaction to the phrase “Bedlam DL3”. Just for grins, I was at lunch in the cafeteria with a bunch of co-workers and I blurted out, totally out of context: “Bedlam DL3”. About 3 of the old-timers in the group responded, in chorus “Me Too!” So why does everyone know about this rather mysterious phrase? Well, Microsoft’s a pretty big organization. We’ve got well over 100,000 mailboxes in our email infrastructure, and at times it can become rather cumbersome to manage all these. One of the developers in our Internal Technologies Group (also known as ITG, basically the MIS department at Microsoft) was working on a new tool to manage communications with the various employees at Microsoft, and as a part of this tool, he created several distribution lists. Each distribution list had about a quarter of the mailboxes in the company on it (so there were about 13,000 mailboxes on each list). For whatever reason, the distribution lists were named “Bedlam DL<n>” (maybe the tool was named Bedlam? I’m not totally sure). Well the name of the lists certainly proved prophetic. It all started one morning when someone looked at the list of DL’s they were on, and discovered that they were on this mysterious distribution list called “Bedlam DL3”. So they did what every person should do in that circumstance (not!). They sent the following email: To: Bedlam DL3 From: <User> Subject: Why am I on this mailing list? Please remove me from it. Remember, there are 25,000 people on this mailing list. So all of a sudden, all 25,000 people received the message. And almost to a person, they used the “reply-all” command and sent: To: Bedlam DL3 From: <User> Subject: RE: Why am I on this mailing list? Please remove me from it. Me too! In addition, there were some really helpful people on the mailing list too: They didn’t respond with just “Me Too!” They responded with: To: Bedlam DL3 From: <User> Subject: RE: Why am I on this mailing list? Please remove me from it. Stop using reply-all – it bogs down the email system. You know what? They were right - the company’s email system did NOT deal with this gracefully. Why? Well, you’ve got to know a bit more about how Exchange works internally. First off, the original mail went to 13,000 users. Assuming that 1,000 of those 13,000 users replied, that means that there are 1,000 replies being sent to those 13,000 users. And it turns out that a number of these people had their email client set to request read receipts and delivery receipts. Each read and delivery receipt causes ANOTHER email to be sent from the recipient back to the sender (all 13,000 recipients). Assuming that 20% of the 1,000 users replying had read receipts or delivery receipts set, that meant that every one of the message that they sent caused another message to be sent for every one of the 13,000 recipients. So how many messages were sent? First there were the basic messages – that’s 13,000,000 messages. Next there were the receipts – 200 users, 13,000 receipts – that’s and additional 2,600,000 messages. So about 15.5 MILLION messages were sent through the system. In about an hour. So at a minimum, 15,600,000 email messages will be delivered into peoples mailboxes. But Exchange can handle 15,600,000 email messages EASILY. There’s another problem that’s somewhat deeper. An Exchange email message actually has TWO recipient lists – there’s the recipient list that the user sees in the To: line on their email message. This is called the P2 recipient list. This is the recipient list that the user typed in. There’s also a SECOND recipient list, called the P1 recipient list that contains the list of ACTUAL recipients of the message. The P1 recipient list is totally hidden from the user, it's used by the MTA to route email messages to the correct destination server. Internally, the P1 list is kept as the original recipient list, plus all of the users on the destination servers. As a result, the P1 list is significantly larger than the P2 list. For the sake of argument, let’s assume that 10% of the recipients on each message (130) are on each server. So each message had 100 recipients in the P1 header, plus the original DL. Assuming 100 bytes per recipient email address, this bloats each email message by 13K. And this assumes that there are 0 bytes in the message – just the headers involve 13K. So those 15,000,000 email messages collectively consumed 195,000,000,000 bytes of bandwidth. Yes, 195 gigabytes of bandwidth bouncing around between the email servers. Compounding this problem was a bug in the MTA that caused the MTA to crash that occurred only when it received a message with more than 8,000 recipients. But it crashed only AFTER processing up to 8,000 recipients. So 8,000 of the 13,000 recipients of the message would get it and 5,000 wouldn’t. When the MTA was restarted, it would immediately start processing the messages in its queue – and since the messages hadn’t been delivered yet, it would retry to deliver the message, sending to the SAME 8,000 recipients and crashing. And because of the way the Exchange store interacts with the MTA, even if we shut down the MTA, the messages would still queue up waiting on delivery to the MTA –shutting down the MTA wouldn’t fix the problem, it would only defer the problem (since the message store would immediately start delivering the queued messages into the MTA the second the MTA came back up). So what did we do to fix it? Well, the first thing that we did was to fix the MTA. And we tried to scrub the MTA’s message queues. This helped a lot, but there were still millions of copies of this message floating around the system. It took about 2 days of constant work before the email system recovered from this one. When it was over, the team firefighting the crisis had t-shirts made with “I survived Bedlam DL3” on the front and “Me Too! (followed by the email addresses of everyone who had replied)” on the back. To prevent anything like this happening in the future, we added a message recipient limit to Exchange – the server now has the ability to enforce a site-wide limit on the number of recipients in a single email message, which neatly prevents this from being a problem in the future. Larry OstermanAllowing application servers to relay off Exchange Server 2007
From time to time, you need to allow an application server to relay off of your Exchange server. You might need to do this if you have a SharePoint, a CRM application like Dynamics, or a web site that sends emails to your employees or customers. You might need to do this if you are getting the SMTP error message "550 5.7.1 Unable to relay" The top rule is that you want to keep relay restricted as tightly as possible, even on servers that are not connected to the Internet. Usually this is done with authentication and/or restricting by IP address. Exchange 2003 provides the following relay restrictions on the SMTP VS: Here are the equivalent options for how to configure this in Exchange 2007. Allow all computers which successfully authenticate to relay, regardless of the list above Like its predecessor, Exchange 2007 is configured to accept and relay email from hosts that authenticate by default. Both the "Default" and "Client" receive connectors are configured this way out of the box. Authenticating is the simplest method to submit messages, and preferred in many cases. The Permissions Group that allows authenticated users to submit and relay is the "ExchangeUsers" group. The permissions that are granted with this permissions group are: NT AUTHORITY\Authenticated Users {ms-Exch-SMTP-Submit} NT AUTHORITY\Authenticated Users {ms-Exch-Accept-Headers-Routing} NT AUTHORITY\Authenticated Users {ms-Exch-Bypass-Anti-Spam} NT AUTHORITY\Authenticated Users {ms-Exch-SMTP-Accept-Any-Recipient} The specific ACL that controls relay is the ms-Exch-SMTP-Accept-Any-Recipient. Only the list below (specify IP address) This option is for those who cannot authenticate with Exchange. The most common example of this is an application server that needs to be able to relay messages through Exchange. First, start with a new custom receive connector. You can think of receive connectors as protocol listeners. The closest equivalent to Exchange 2003 is an SMTP Virtual Server. You must create a new one because you will want to scope the remote IP Address(es) that you will allow. The next screen you must pay particular attention to is the "Remote Network settings". This is where you will specify the IP ranges of servers that will be allowed to submit mail. You definitely want to restrict this range down as much as you can. In this case, I want my two web servers, 192.168.2.55 & 192.168.2.56 to be allowed to relay. The next step is to create the connector, and open the properties. Now you have two options, which I will present. The first option will probably be the most common. Option 1: Make your new scoped connector an Externally Secured connector This option is the most common option, and preferred in most situations where the application that is submitting will be submitting email to your internal users as well as relaying to the outside world. Before you can perform this step, it is required that you enable the Exchange Servers permission group. Once in the properties, go to the Permissions Groups tab and select Exchange servers. Next, continue to the authentication mechanisms page and add the "Externally secured" mechanism. What this means is that you have complete trust that the previously designated IP addresses will be trusted by your organization. Caveat: If you do not perform these two steps in order, the GUI blocks you from continuing. Do not use this setting lightly. You will be granting several rights including the ability to send on behalf of users in your organization, the ability to ResolveP2 (that is, make it so that the messages appear to be sent from within the organization rather than anonymously), bypass anti-spam, and bypass size limits. The default "Externally Secured" permissions are as follows: MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authoritative-Domain} MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Anti-Spam} MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Message-Size-Limit} MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Exch50} MS Exchange\Externally Secured Servers {ms-Exch-Accept-Headers-Routing} MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Submit} MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Recipient} MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authentication-Flag} MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Sender} Basically you are telling Exchange to ignore internal security checks because you trust these servers. The nice thing about this option is that it is simple and grants the common rights that most people probably want. Option 2: Grant the relay permission to Anonymous on your new scoped connector This option grants the minimum amount of required privileges to the submitting application. Taking the new scoped connector that you created, you have another option. You can simply grant the ms-Exch-SMTP-Accept-Any-Recipient permission to the anonymous account. Do this by first adding the Anonymous Permissions Group to the connector. This grants the most common permissions to the anonymous account, but it does not grant the relay permission. This step must be done through the Exchange shell: Get-ReceiveConnector "CRM Application" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient" In addition to being more difficult to complete, this step does not allow the anonymous account to bypass anti-spam, or ResolveP2. Although it is completely different from the Exchange 2003 way of doing things, hopefull y you find the new SMTP permissions model to be sensible. More information See the following for more information: Receive Connectors Exchange 2007 Transport Permissions Model - Scott LandryAnnouncing OAuth 2.0 support for IMAP and SMTP AUTH protocols in Exchange Online
Ever since we announced our intention to disable Basic Authentication in Exchange Online we said that we would add Modern Auth (OAuth 2.0) support for the IMAP, POP and SMTP protocols. Today, we’re excited to announce the availability of OAuth 2.0 authentication for IMAP and SMTP AUTH protocols to Exchange Online mailboxes.Modern Auth and Unattended Scripts in Exchange Online PowerShell V2
Today, we are happy to announce the Public Preview of a Modern Auth unattended scripting option for use with Exchange Online PowerShell V2. This feature provides customers the ability to run non-interactive scripts using Modern Authentication.
