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 DaltonMe 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 OstermanHybrid Mailbox moves and EMC changes
As customers are upgraded or sign up for the latest version of Office 365 for business, they may notice some changes in their recipient and organization management experience. For instance, we now allow the Organization and Hybrid Migration management experience to be initiated from the Exchange Administration Center (EAC) in Exchange Online. This allows you as the administrator to take advantage of many of the enhancements that were added to the migration and organization management experience. The good news is you can do this without having to upgrade your on-premises Exchange 2010 Hybrid server to Exchange 2013. Hybrid Mailbox Moves In hybrid deployments with Exchange Online, you should consider using the EAC to perform your hybrid mailbox moves. Some of the main features that have been added or enhanced are listed in Mailbox Moves in Exchange 2013: Ability to move multiple mailboxes in large batches Email notification during move with reporting Automatic retry and automatic prioritization of moves Option for manual move request finalization, which allows you to review your move before you complete it Periodic incremental syncs to update migration changes The other benefit to using the EAC in Exchange Online - it's a web-based tool, and you have access to the latest enhancements as they are made available in Exchange Online. The Migration team is continually working to improve the migration experience and resolve issues that we may face along the way. The Exchange Management Console (EMC) in Exchange 2010 SP3 is still a supported tool for performing hybrid mailbox moves. However, you'd be missing out on the enhancements that were built into the EAC and you could potentially run into some of the limitations that exist in the EMC when connecting to the new service. Previous EMC move mailbox experience Most customers with a hybrid deployment are currently running Exchange 2010 in their on-premises environment. Many customers are accustomed to performing their mailbox moves from the EMC on-premises. If there was an issue initiating the move, the customer would be notified with an error message such as the following: Figure 1: A generic error when performing a remote mailbox move using the Exchange Management Console in Exchange 2010 SP3 This would let the administrator know that they needed to start investigating the moves. In many cases, when you get a generic error (such as the error above) or if you wanted to get a more verbose error message you would use PowerShell to connect to Exchange Online and initiate the move, as shown in the following steps: Connect to Exchange Online Using Remote PowerShell Initiate the move request: $OnPremAdmin=Get-Credential When prompted, enter the on-premises administrator credentials. New-MoveRequest -Remote -RemoteHostName mail.contoso.com -RemoteCredential $OnPremAdmin -TargetDeliveryDomain “Contoso.mail.onmicrosoft.com” Current EMC move mailbox experience With the latest version of Office 365, if you were to use the EMC on-premises to initiate a mailbox move and there was an issue, you would not get ANY errors. Meaning you may think the move was submitted successfully even if it was never submitted to the Mailbox Replication Service (MRS). This could mean no move logs, no moves in the queue, and no record that a move was even attempted! Although using the EMC to move mailboxes to Exchange Online is (still) supported, all of the move features are not available in the EMC. You should really use the EAC in the cloud to get the best and most reliable administration experience for your mailbox moves. Moving mailboxes to Exchange Online using the EAC Here's a quick walkthrough of how to move a mailbox from Exchange 2013/2010/2007/2003 in a hybrid environment with the new service. This is assuming you've successfully completed hybrid configuration and your on-premises Exchange organization happily coexists with your cloud-based Exchange organization. You can use the Microsoft Exchange Server Deployment Assistant (EDA), our web-based tool, to get step-by-step instrucions for configuring a hybrid environment. Log into https://portal.MicrosoftOnline.com with your tenant administrator credentials In the top ribbon, click Admin and then select Exchange Click Migration > click + and then select the appropriate move mailbox option. In this example, we're moving a mailbox to the cloud so we select Migrate to Exchange Online. On the Select a migration type page, select Remote move migration as the migration type for a hybrid mailbox move On the Select the users page, select the mailboxes you want to move to the cloud. On the Enter on-premises account credentials page, provide your on-premises administrator credentials in the domain\user format. On the Confirm the migration endpoint page, ensure that the on-premises endpoint shown is the CAS with MRS Proxy enabled. Note This will be the same endpoint regardless of wehther you're moving a mailbox to the cloud (onboard request) or moving a mailbox from the cloud to your on-premises Exchange organization (offboard request). Enter a name for the migration batch and initiate the move. EMC Changes In Exchange 2010, the EMC has three sections: 1) Organization Configuration 2) Server Configuration and 3) Recipient Configuration. These sections will be visible to administrators as long as they have permissions, via RBAC , to the objects that are in that container. Before the Service upgrade, if a customer was in a hybrid deployment and connected their Exchange 2010 SP2 EMC to Office 365, they'd see two sections (Organization Configuration and Recipient Configuration in their cloud organization. The Tenant Administrator would not see server configuration settings because they have no control or view into the Server Configuration settings. Figure 2: Exchange 2010 SP2 EMC connected to Exchange Online before the service uprade After the service upgrade, the customers will actually see only one container in the cloud organization in Exchange 2010 SP3 EMC - Recipient Configuration. We removed the Organization Configuration container because we don't support (or test) allowing an Exchange 2010 EMC to control or change organizational settings in a newer version of Exchange. To prevent issues, we've completely removed that container from the view in EMC. Configuration changes to the tenant’s Exchange organizational settings in Exchange Online should be accomplished by connecting to the EAC in Exchange Online. Figure 3: Exchange 2010 SP3 EMC connected to Exchange Online after the service uprade Timothy Heeney/Mixed-ing it up: Multipart/Mixed Messages and You
Greetings, Exchange Administrators! In today’s edition of “and You”, we’ll be covering Exchange’s handing of messages generated by iPhones, iPads, and Macintosh Mail clients. Specifically, we’re going to cover what /mixed content body messages are, how Exchange handles them now, and how we handle them down the line. Before we can dive into the content, you first have to understand how internet messages are structured, and that means learning a little bit about how Exchange stores messages, and quite a bit about MIME . Not the mute freaks – Multipurpose Internet Mail Extensions, also known as “The Mime not everyone hates.” Exchange, Messages, and LOL Cats Exchange stores messages as a series of properties, where each property has a name and a value. For instance, PR_SUBJECT is the subject property, and “Test Message” is the value. Messages in Exchange have one body with multiple forms of representing it (HTML, Rich Text and Plain text). The HTML view of the body looks like so: This is a cat. Do Not Want The RTF (rich text format) view of the same body is also capable of containing both formatting and images, and so would look like: This is a cat. <Mentally insert picture of cat here – it’s only eight lines up, so honestly, you can do it. > Do Not Want The plain text version of the body is composed of plain text, a fact that should be obvious based on its name. A good way of simulating plain text body generation is to paste your content into notepad. If it survives the paste into notepad, it will be part of the plain text. Sadly, the cat picture does not: This is a cat. Do Not Want Messages in Exchange can have multiple attachments. This is good, because even if Exchange is forced to generate a plain text version of the body, the cat picture can come along so that should you decide to click it, you can view a picture of a cat which does not want something. Key points for non technical and allergic to cats people: For Exchange, messages can have one body and can have many attachments. And in this corner, MIME MIME is a plain text format for email messages. MIME messages are divided into “parts”, each of which might have content or even child parts, like a series of Russian dolls. Each MIME part (even the root part, or the message itself) has a header called Content-Type, which describes the type of content in the part. Content type is divided into major parts and minor parts, separated by a slash. For example, consider the content-types multipart/alternative or multipart/mixed. Every part has a type, even going so far as to define a Miranda type for parts which can't afford to assign one (text/plain). Sometimes the types are quite helpful at understanding the meaning of the content, sometimes not so much. For instance, Content-Type: Application/PDF – that one means that it is Adobe’s Portable Document Format. On the other hand, Content-Type: application/octet means “I can’t tell what this is. Here’s a binary blob for your troubles. Hopefully you can figure out what to do with it” Multipart/ is a general type, meaning that this MIME part may contain many child MIME parts. The sub type of the part (the part after the slash) tells us more about the child parts, and in this case, how they are related to each other. Now we will take a closer look at some of the multipart sub types to see where things can go wrong. Relativity First off we’re going to look at Multipart/related, (also called a “related” body part). Related, in this case, means that the sub MIME parts are actually related to each other – in other words, that give the following MIME structure: 1. Multipart/related 1.1. Text/HTML 1.2. Image/Gif That 1.1 and 1.2 are not meant to be interpreted as “separate” parts – they have meaning as one. In this case the html contains image links to the 1.2 image (our friend the cat). Key point for non technical and allergic to cats people: Multipart/Related means “We belong together.” Alternatives Multipart/alternative means that each child of this part is a different representation of the same data. They are “Alternative” versions of each other. The intention is that a client picks the type that it can best display and displays that one. So given this mime structure: 1. Multipart/alternative 1.1.1. Text/Plain 1.1.2. Text/Html 1.1.3. Application/Pdf The client doesn’t have to show the text/plain part as the body. No, if the client knows how to display a text/html body, it is free to do that. So multipart/alternative is a way of grouping a number of different formats of the same data together and letting the client decide which one it shows best – it’s like kid’s beauty pageant, except that instead of the ladies from the rotary club, you have the email client as the judge. Key point for non technical and allergic to cats people: Multipart/Alternative means “Pick the one you like best.” Mixed Up Multipart/Mixed, according to RFC 1521, means that the parts are completely independent of each other (not related to each other) but that their order matters. What is the expected behavior? “Clients usually display the parts one after the other.” This, however, brings into play another parameter on the MIME part – Content-Disposition. This parameter has a couple of normal values – Inline and Attachment. Attachment is easy to understand – in the context of Exchange, it means “Show me in the well, that I may be blocked by Outlook from being saved or opened.” Inline, on the other hand, we handle differently. Remember that whole “messages have one body, and maybe many attachments” thing? Keep that in mind while we look at how our Cat message looks like with a /mixed body: 1. Multipart/Mixed 1.1. Text/Html - Inline 1.2. Application/Gif - Inline 1.3. Text/Html - Inline And the intention among clients that generate this is that the receiving client should display the text/html part first and then glob on the image to the end of it, and then the rest of the body. There’s no limit to multipart/madness, you can combine them (and dispositions) into nigh endless combinations. For example: 2. Multipart/Mixed 2.1. Text/Html -Inline 2.2. Image/Gif -Inline 2.3. Text/Html -Inline 2.4. Text/Plain -Inline Means “Show 2.1, followed by the image from 2.1 then the html from 2.3 and then the text from 2.4. Do it NOW.” 3. Multipart/Mixed 3.1. Text/HTML -Inline 3.2. Image/Gif –Attachment 3.3. Text/Html –Inline 3.4. Text/Plain –Attachment Means “Show the text from 2.1, NOT the attachment from 3.2 unless someone does something, the text from 3.3, but NOT the text in 3.4 (unless they do something like click an attachment in the well). The problem, of course, comes from Exchange’s original definition of a message – one body (with multiple representations), maybe many attachments. Key point for non technical and allergic to cats people: Multipart/Mixed can mean “Maybe show all of these, in the order listed.” Combo #5 MIME Types are not exclusive. I can combine Multipart/Mixed, Multipart/Alternative and Multipart/Related into a single message, and actually have a meaning 1. Multipart/Mixed 1.1. Multipart/Alternative 1.1.1.1. Text/Plain 1.1.1.2. Multipart/Related 1.1.1.2.1.1. Text/HTML 1.1.1.2.1.2. Image/Gif - inline 1.2. Image/Jpeg - attachment Yes, this structure is legal. And it is meaningful. To understand this you unwrap in order, one level at a time. Multi Mixed – this message is different parts, put together, and the order matters. Multipart/Alternative- I have two children, pick the prettier one and show it off. Text/Plain – I am a blob of plain text Multipart/Related – My children are bits and pieces of each other Text/HTML – Pretty, Pretty Text. Image/Gif – I am a picture of a cat, referenced by pretty, pretty text, I hope. Image/Jpeg – I’m an attachment (in case you couldn’t see the picture of the cat above). Exchange has always dealt well with multipart/alternative bodies, picking the one which we can best support and promoting it. We deal well with multipart/related as well – not every attachment on a message is visible – attachments have a disposition, which is either not set, inline or attachment. Setting neither indeterminate – the client does what the client does (and good luck establishing an algorithm that works for everyone). On the other hand, messages with /mixed content bodies where multiple parts are inline, those do not work so well. Blender’d Messages In the case of /mixed bodies, there are multiple MIME parts which are meant to combine together like Japanese robots to form Voltron, or an image of a cat and some text. Today, if you receive such a message, we do the best we can with it (which is pretty dis-satisfying): We pick the first “body type part” – aka, a text/<something> part, and that one becomes the body as seen by Outlook. All of the rest of them, those are attachments and we shove them into the attachment well. Oh, sure they might have a disposition of inline, but because the most common usage of inline is in HTML, we actually check, and anything that isn’t referenced by a link from the body, we won’t be fooled by. Into the well it goes. From an Outlook perspective you get the first part of the message, then two attachments, one of which is the picture and the other is the trailing text. You are welcome to open the attachments in order, and combine them in your head to form a message, but once you get more than a couple parts it isn’t reasonable. Exchange has never supported “proper” display of /mixed body messages in OWA or Outlook, until now. Blended Messages Starting with Exchange 2007 service pack 3 roll up 3 (E12SP3RU3) and Exchange 2010 service pack 1 rollup 4 (E14SP1RU4) are a set of changes to how Exchange handles /mixed body messages. We think that in general your users will enjoy the less mangled nature of these messages, but if I’ve learned anything from fourteen years of working on Exchange, it’s that “different == angry”. People get used to our behavior, so even when it’s wrong (or incomplete) they expect the same behavior, and come to rely on it. Consider this is your fair warning that this change is coming, some details on how it works, where it works, and where it doesn’t. We're adding support for Exchange to combine multiple body parts into a single, aggregate body. The short of this is that broken up messages should show combined together, and readable in OWA and Outlook. There are, however, limitations to this. First off, right now this will only work for message generated by Apple iPods, iPads, or Apple Mail clients. This isn’t an accident – we developed the rules used to combine these bodies using test data from our counterparts at Apple, and while we handle messages by them well, the internet is wide and wondrous, and anyone can write messages with multipart/mixed bodies. For now this is restricted to clients we have good test data on, good rules for and a good way to identify. To create the aggregate body, we check each MIME part in the /mixed body. If a MIME part has a disposition of Attachment, it goes to the attachment well. I am not going to argue with a client that specifies that it is an attachment. If a body part has a disposition of inline or not set, if it is a plain text or html body part, we add it to the aggregate body. If the body part is an image which can be displayed inline, we add a link to it in the aggregate body. If the body part is not text, or is an image we can't display inline, it goes to the well. How do I know if this breaks me? If you're the owner of an application which is used to sending in /mixed content messages with MIME parts that you rely on Exchange treating as well attachments, and you send them from an Apple platform, and you haven’t been setting a content disposition, and the parts are text or image types (and you are setting content type), then you need to add a Content-Disposition to the MIME parts you want to be attachments, and set them to Attachment. If you're a normal consumer wondering why messages with images or signatures got split into pieces, you don’t need to do anything. Conclusions Today we’ve covered different MIME structures, different representations of bodies, dispositions, types, and a host of other things, but the hard boiled summary is that mail between Apple clients and Exchange clients will be handled better. The best case scenario isn’t that your users call up and say “Wow, I’m really impressed that the messages I got from John on his Mac aren’t chopped up into a dozen pieces anymore.” The best case scenario is that things just work. No one has to call anyone, because you neither notice nor care what platform the message came from, or what format it was sent in. You can see your email, your signatures, and yes, your LOL cats. Enjoy! Epilogue: How things went wrong Already I’ve read (and responded to) reports on the Exchange Update Forums that this new code introduced a new problem. PDF attachments from Mac clients which declare their disposition to be Inline aren't visible in the attachment well. Visible in Outlook Web Access, yes, but MAPI, no. So how on earth did this happen? And how did we miss this bug? (“Do you do any quality control?” as one person asked.) The answer to this is yes, we do. But rather than just say that, let’s look at the journey we took to get this fix included in a rollup, what the problem is, how we missed it, and what we're doing about it. This fix begins with a conference call between me, a few team mates, and our counterparts at Apple, in which someone asked “Well, can you guys do anything to actually support this style of message body?” I spent the next few days researching what it would take to build a synthetic body out of the parts and eventually concluded that it would be possible. With that we began the discussions of “Why now?” and “What is it going to take?” That phase took quite a while. The core problem was that we were well aware that producing a new type of body was going to require a large investment in testing. Eventually we concluded that we could and would do it. And we did. We wrote the code that supports this type of body, we wrote the code that tests it. We have a huge number of tests that test various types and formats of bodies. We had only the new ones to test the new body. Line for line there's more code to test this than there's to support it. So the fix was done, the code was tested, but we still weren’t ready to check in the code. Instead, we took a much more cautious approach. The fix was available as an interim update and that interim update was tightly controlled since we wanted it to go to customers who would be putting it into daily use. After a month or so we loosened it up and the fix went out to four more customers, eventually being in play at around 12 customers for about three months. After three months of field deployment with positive results, we decided to schedule it for a rollup (which should've been RU2, but wound up being RU3). But there’s a problem. You see, Exchange 2007 and 2010 don’t pay much attention to Content-Disposition, because for years inline has been a great way to make sure the attachment is essentially invisible (an inline attachment has its hidden property set to true, since it is displayed inline with body content). And the test code missed this case – it’s an inline attachment which can't be displayed inline by Exchange, but in a message which contains multiple body parts which can be merged to build the synthetic body. Unfortunately neither our in-house nor field testing encountered this. The bug is that in processing these messages, we honor attachment disposition in a case where we should not. Any attachment which can't be displayed inline should never be allowed to become part of the synthetic body. We know of two types of attachments – TIFF and PDF, which can be displayed inline on Mac clients but not on Windows clients. The fix for these two also fixes any other types where the client might render inline but we can't. How did we miss this? We went back over our test code and test data and said “It contains PDFs, and validates the attachment well status.” It does indeed (and TIFFs as well). It also doesn't ever attempt to create a PDF attachment and render it inline in the body. That’s the missed case which I certainly wish we had found before it ever hit any customers. So to resolve this we're creating an interim update, and we’ll be rolling it into the main branch to prevent further incidents of this. Over time I expect that we'll expand the number of mailers we produce synthetic bodies for. For now, I think this experience has validated that we should keep it limited and expand support where we can closely test. I remain convinced that improving interop between Mac clients and Exchange is a good idea. So there we have it: The problem, the fix, the problem with the fix, and the fix for the problem with the fix. We now return to your regularly scheduled blog. Jason NelsonFrom crush to product documentation: The story of Squeaky Lobster
When customers first hear about being able to enable extra JET Blue or ESE Database performance counters via adding a "Squeaky Lobster" registry value, they often think it must be a joke or ask you to repeat it. And invariable the question comes up ... _why_ "Squeaky Lobster"? Various lore or conjecture has surfaced around it ... that it was a developer's child's toy or that is just thought up after lunch one day. Not exactly ... and retrieving the information was a little tricky as the initial checkin was 2 years before I started ... The story starts with a certain developer, let's call him, "Andrew Goodsell", for the time being, but I call (or called) him, "boss", and I can assure you those explanations are not quite right. If you were to get incriminating information about your boss, you might wonder what is the proper time to blog about it? Right after you stop working for him I think is the right answer to that ... and as of today I have transferred to the Exchange organization, while "Andrew" has not. I am as they say, unsupervised. ;-) Andrew, is a very sharp man who prides himself on his professional decorum, and a bit of a perfectionist to boot. In fact his professionalism is what makes this singular lapse in judgment so amusing and fairly uncharacteristic of any decision he would make (or have let me make ;-) today. Andrew has been involved in a fair share of the database performance work in ESE and as anyone decent at perf knows, one of most critical steps is having a way of accurately measuring performance, base-lining performance, at several levels in a software stack. Exchange 5.5 added ESE Database performance counters to facilitate this work. Most of these perf counters were intended for only internal ESE and Exchange developer usage (as you can probably deduce from one of the code snipits below, and looking at what these counters measure... things like B+ Tree Inserts/sec for example). Enter cute girl ... So that autumn while Andrew was working on adding perf counters and working on Exchange 5.5's performance, a cute girl was managing computers in the Exchange Performance lab. Andrew was working on performance and adding performance counters while this girl worked with the powerful computers in the performance lab. It isn't a wonder how they ran into each other. She was cute, it is no wonder Andrew got a crush. Some of the simplest ESE performance counters would also be helpful for advanced administrators in debugging Exchange server issues (Cache Size, File Operations/sec, etc). Andrew mentioned he thought if competing companies had access to some of the more detailed perf counters, they might be able to reverse engineer our implementation details and steal intellectual capital (now that's the professional Andrew I know, trying to protect our intellectual capital). After he says this, he rolls his eyes and says something to the effect of "I don't know what I was thinking!" (this is because the implementation details are more complex than what the counters show, but at the time this made sense). So there was a need to split the ESE Database perf counters into two kinds. ... internal (dev only) and external (admins). The internal ones would have to be hidden. Now, fairly smitten with this girl, ANYTHING she did was fascinating (to Andrew). Oh come on, we've all been there. And one such thing she did was participate in a Giving Campaign, basically an event where we raise money for charities and non-profits. In order to encourage people to give money, various prizes would be donated and a raffle sort of mechanism to win the prizes would be done. The girl of interest donated a toy Squeaky Lobster to the charity raffle. Andrew thought that was the funniest and most random thing to contribute as a prize for a giving campaign ever. Who would want a Squeaky Lobster? Most random prize in giving campaign I guess equals most uneasy to guess registry value ever. Anyway, a name was chosen that was about as random as you could get for 1997 (as there weren't very many words available in 1997, I think the Seattle was recovering from that awful grunge thing). Knowing the crowd Andrew hung out with back then, it would not surprise me if they decided it at or on the way back from lunch as they used to work 12 hour days and take extra long lunches. An excerpt of Andrew's fateful check in from SLM logs (note, I've deleted the developer actual email aliases), relevant information highlighted: #F eseperf.cxx v1 #K text #O in #P 1.00 #T Fri Sep 26 11:15:00 1997 #A <dev_alias_1_deleted>3 #C 47424, 41913 finalize perf ctrs #I 2 #D 1113 27a28,32 > #pragma const_seg( ".text" ) > const char szDisplayDevOnly[] = "Squeaky Lobster"; #pragma const_seg() As an aside, note the ".text" segment notation, I had forgotten about that, now that's old school. Man, 8 years is a LONG time in the computer industry. And so a little over 4 months later, the first Squeaky Lobster Enabled product shipped on Feb 3, 1998, with ESE97 in Exchange 5.5. In fact this is when the database engine under Exchange was renamed from JET Blue to ESE (to avoid confusion with JET Red, which has only vestigial relations to JET Blue / ESE). ESE97 shipped in 1998, just to confuse everyone. The above picture is of the original Exchange 5.5 packaging with the original Squeaky Lobster. But at this point in our story, the counters are secret so it's not a big deal. But there is no way to keep any sort of more extensive analysis mechanism a secret for long ... eventually someone will need the information. And eventually an Exchange performance case came along sometime in 1998 (according to the earliest record I can find in the PSS DB) that required the extra analysis these performance counters offered. The PSS engineer told a customer how to enable the counters so they could analyze the customer's issue. I mean, it comes down to the customer, you do what is necessary and possible to support them. Then another case came in, and another, and eventually someone from PSS thought to publish a KB on 4/17/2000, KB 259895, what counters are enabled by squeaky lobster, _official_ Microsoft documentation admitting the existence of Squeaky Lobster!!! Well, that didn't last long (about 6 months). In about 2000 someone public (Brian Sheaffer / Paul Thurrott) noticed and of course such a thing was far too silly for the serious professionals that control the web site of most big corporations. ;-) About as silly as Squeaky Lobster for a prize in a charity benefit! I mean we're a professional organization. Now there are about 300 PSS related investigations, service tickets and KBs referencing this phrase (including the above one). There is a Squeaky Lobster in Andrew's office as well, but do not be fooled, it is not the original. That Squeaky Lobster was given to him by a PSS engineer who thought it was funny, or maybe to thank him for being repeatedly asked by customers, "What was that? Can you spell it?". A mere 4 and a half years after the checkin, someone wised up ... and for Windows 2003 RTM, and Exchange 2003 SP1, code was checked in to try "Show Advanced Counters" first, and if that fails try "Squeaky Lobster". The comment in the code is: > // deprecated name (yes, we are ending the insanity) > err = DwPerfUtilRegQueryValueEx(hkeyPerf,(char*)"Squeaky Lobster",&Type,&lpbData); Note: we moved away from that archaic .text seg stuff, the compilers are now smart enough. And finally to come full circle, once this happened the name of the registry value appropriate for product documentation on our web site. Note that page specifies Exchange 2003 SP1. If you replace "Show Advanced Counters" with "Squeaky Lobster", the instructions should work for Exchange 5.5 through Exchange 2003 RTM as well as current products, though the registry key you use for step 2, varies. For Ex 5.5 it is "ESE97" instead of "ESE". In Ex2k you have to use "ESE98" before SP2, and finally for SP2 and later, just "ESE". The same process works for Windows, but use "ESENT" instead of "ESE", oh and you have to enable the performance counters for Windows first. I promised an Exchange MVP, Michael B. Smith, about a year ago and I apologize for the delay, some would even mock me for taking so long with this single post, but at that time, the fact that there was a Ms. Squeaky Lobster unknowingly influencing Microsoft product development was not known. You got to wait until you get all the details, Eric. It wasn't till Andrew, accidentally spilled the information at a dinner. After that I blurted out, "I'm SOOO BLOGGING THAT!", Andrew had an immediately look of regret on his face, and now he won't really talk about it anymore. ;-) So that is about all the Squeaky Lobster trivia I could collect. The next time you have to really dig into Exchange (or Active Directory) database performance, just remember how responsible professional ESE software engineers are adding easily discoverable (based upon the activities of their current crush at the time) mechanisms for diagnosing your top issues. So with that in mind, the next time you go to buy a software product, remember to check the box to see if this is one of the many Squeaky Lobster Enabled products. Oh just checked an Exchange 2003 box, not actually listed on the box, hmmm, I guess serious professionals are in control of the packaging too. ;-) So Sept 26th of this year is Squeaky Lobster Day, the 9 year anniversary of the checkin of the Squeaky Lobster registry value, be sure to Squeaky Lobster a server at 11:15, and then go to an extra long lunch, and make a silly decision you'll regret and feel embarrassed about 9 years down the road ... sorry, Andrew, you can't stop the insanity ... Cheers, Brett Shirley ESE (aka JET Blue) DeveloperA brief history of time - Exchange Server way
Ever wondered how Exchange Server evolved over the years? And how come Exchange Server 2007 shows "8.0" as its version number? Here is a brief history of time... it might add a bit to the known history! First Exchange proof of concept was in the early 90's. Development team usage only. Mercury - we couldn't get Exchange to scale past 25 users. We were bleeding internally with Xenix mail, so we figured that we'd keep Exchange alive but just use it as a MIR (Microsoft Internal Release). A perf and scale team was put in-place to see what we could do about the abysmal performance. Touchdown - the perf and scale team figured out the important issues, and Exchange once again had the potential to become an external release, marketed and sold by Microsoft. Indeed, after several test releases, we shipped in early '96 as Exchange 4.0 4.1 - Exchange 4.0 spent a long time in development, but it was a little rough around the edges. We immediately started work on a 4.1. After having implemented X400 as the primary messaging protocol and an X500-like directory structure, we quickly realized that this Internet 'thing' was really going to take off. It started to become obvious that we needed more than a .1 release. The 4.1 moniker was dropped and we were now working toward 4.5. After implementing several ground-breaking protocols such as SMTP and LDAP v2, this was certainly not a dot release. We shipped as Exchange 5.0 in early '97. Exchange 5.0 brought another important technical addition - the introduction of a Web-based e-mail client called Exchange Web Access (EWA). EWA was subsequently renamed Outlook Web Access (OWA). EWA was revolutionary for its time. It allowed employees or other individuals with mail stored in an Exchange 5.0 or later server to use a web browser to access their e-mail from anywhere at any time. In other words, the Exchange server provided the necessary information and interface through the web browser, no special e-mail client application was required on the user's machine. While on the subject of Exchange 5.0: If you still have an Exchange 5.0 CD around, there is an Easter egg on the CD in the form of a file called EXGL32.DLL. Rename that file to .AVI and view it... it is essentially credits for all the people that worked on Exchange 5.0 and while at it, we made some fun about the versioning in it too. Just so you get an idea: The Exchange 4.1 Team! Oh... wait... The Exchange 4.5 Team! Uh... let's try this again... The Exchange 5.0 Team! Yeah, that'll work! Osmium (aka Oz) - More and more Internet protocol work was poured into the product including LDAP v3 and NNTP support. It was also obvious that 16GB of database space was not enough. Exchange 5.5 was born and shipped near the end of '97. Platinum (aka Pt) - After we shipped Exchange 5.5, we started building the Exchange 6.0 product. Big changes were afoot. The Exchange Directory team had moved over to Windows and Active Directory was coming together. Both the Windows and Office teams used year numbers for their releases, so externally, the product would be called '2000' rather than 6.0. There was no point changing the internal version numbers, so we stuck with 6.0 inside the code. Exchange 2000 was released in November of the year 2000. Mercury - Exchange 2000 also turned out to be a little rough around the edges, especially with upgrades and integration with Exchange 5.5. We had to act quickly, so SP1 quickly followed. However, more was needed, so we started work on a 6.1 which was codenamed 'Mercury'. Ironically, this was the same code name as what we had used back in the early 90's, and suffered the same fate as the first Mercury. For various business reasons, the Mercury project was canceled. We had already written a lot of new code, and this was eventually divided and shipped as part of Exchange 2000 SP2 + SP3, with the rest in Titanium. Titanium (Ti) - We were now working on Exchange 6.5, this was to sync up with Windows 2003 and Office 2003. Major technical breakthroughs occurred in this release including the advent of RPC/HTTP, cached mode and ActiveSync for mobile clients. Exchange 6.5 was externally shipped as Exchange 2003 (shipped in September of 2003). Kodiak - after Exchange 2003 shipped, it was time for a major shake-up of the product. We had many new ideas and needed a place to check-in our code - the version number is now 7.0. Spam is a major problem – is it time to create a special version of Exchange just to tackle this? The small business market is in need of a 'tiny' version of Exchange – perhaps the market is ripe for Exchange for Workgroups, or perhaps Exchange Express. For the enterprise product, is it time to switch from ESE (JET) to SQL? After a lot of research and investigation, we decided to cancel the Kodiak project, but take our best ideas forward. E12 - A new version of Exchange needs to come together. There's too much proof-of-concept code occupying the 7.0 version space. It's time to increment to 8.0. With major changes all round, including Unified Messaging, multiple server roles and PowerShell integration, the code name was aligned with the Office team. Office was working on their '12' wave, and so we used the code name of Exchange 12 (or E12). Exchange 8.0 / E12 was externally shipped as Exchange 2007 at the end of year 2006. E?? - We just shipped Exchange 2007 SP1 (or, E12 SP1 to you and me). What's next, you ask? Is it Exchange 9.0 or perhaps Exchange 13? Perhaps it's something completely different... Stay tuned! - Paul BowdenOutlook Web Access - A catalyst for web evolution
"The Exchange Web Client" was the first web email client produced by Microsoft. It had an interesting green and black color scheme but it did most of the basic needs for doing messaging. We didn't have enough time to add calendaring support in the first version. What we did in this first version was the first step in what has now become a new way of building web applications. OWA was born out of the sheer will of my friend Bob Gering when he decided we should look exactly like Outlook. We started changing our frameset design, colors and graphics to look and feel like Outlook. It was this desire to look, act and feel like Outlook that caused us to move web applications forward in a new evolutionary path. Traditional web applications constantly refresh the document for just about every action. During Exchange 5.5 development in 1996/97 we used hidden frames to communicate to the server when sending messages so we wouldn't clear the user's document. However, we still had many frames updating during navigation of the mailbox. We also developed a Java applet for the date picker control in the calendar view to augment the user experience since DHTML on the current browsers at that time was just about non-existent. In the end we found that the applet did not meet our performance needs because virtual machine initialization was too expensive. OWA 5.5 had richer support than prior versions but it still lacked the type of experience that users get in a win32 application but it did work on just about every browser under the sun. In 1998 we started on the incredible task of rewriting OWA for Exchange 2000. There were competing teams that were working on this task. WebDav had a team, led by Russ Simpson, working on a very basic hotmail like experience. The architecture of this version was the most interesting part. It was scalable and fast because it was actually built into the Exchange store process. Bob Gering, Ward Beattie, Iain McDonald and I were on the CDO (Collaboration Data Objects) team building a version with DHTML controls on an alpha version of IE5. Management fixed the redundant effort issue and joined the two teams together with Ward leading the way. It made perfect sense to combine the efforts of great plumbers along with great painters. The first DHTML prototype for OWA was written on top of a pre-beta version of IE5. IE5 was such a huge improvement. IE4 was a great step forward and we did evaluate it but IE5 had many other built-in technologies that let us improve the user experience. The IE5 browser could certainly absorb xml but making a DAV request was impossible from the browser, so we added an ActiveX control to the prototype that made it possible to make DAV requests such as SEARCH, PROPFIND, etc... The OWA prototype was demo'd to Billg and he loved it. This gave us enough momentum to get a component that we needed to be installed by IE5 that we called XMLHTTP. XMLHTTP was born and implemented by the OWA dev effort of Shawn Bracewell. Exchange funded the effort by having OWA development build XMLHTTP in partnership with the Webdata team in SQL server. XMLHTTP changed everything. It put the "D" in DHTML. It allowed us to asynchronously get data from the server and preserve document state on the client. In some cases, OWA is communicating with multiple servers to update the navigation document. XMLHTTP was not just a self serving effort. We knew that eventually this component would be discovered and used by other web developers that wanted to build rich applications but we just didn't know when they would discover it. Oddpost appeared about a year or so after we shipped Exchange 2000. This application really pushed the limits and used similar techniques found in OWA. The Oddpost team deserves credit for moving the web forward also. They did a fantastic job harnessing the power of IE 5.x. In Exchange 2003 we took it up another notch by asynchronously polling the server for new mail notifications and calendar reminders. We also added spell check that uses XMLHTTP exclusively to retrieve spelling suggestions from the server. The OWA team's desire to build a rich Win32 like application in a browser pushed the technology into IE that allowed AJAX to become a reality. The OWA team today is one of the most talented in its history. Each version of OWA makes huge strides in technology and user interface, and the next release is no different, you're going to love it. - Jim Van EatonEHLO Again!
Earlier last month, the Exchange team blog turned seven. Our first post, creatively titled “First Post!!!” of the Microsoft Exchange team blog, was dated Feb 09, 2004. From the squeaky lobster to the Exchange 2007 secret decoder ring, we’ve enjoyed sharing Exchange stories with you. It has been an interesting journey, sharing technical tips and guidance, announcing product releases and updates, seeking community feedback, and sharing important moments in Exchange history and culture with you — the squeaky lobster stories, Exchange limerick contests, why an OOF's an OOF and not an OOO, the Autodiscover song and, from 'the edge of reason', the tale of the nuclear toaster man. If you're missing Mercury, Platinum, and Ti, take a brief trip down the memory lane in A brief history of time - Exchange Server way. In December 2004, we reached a million hits, a milestone for our new blog back then! The EHLO Evolution Over the years, we’ve received a lot of feedback about this blog. You’ve loved, liked, and appreciated our posts, and found them useful. Two common questions emerged from your feedback: Is this the official Exchange team blog? Is this really a Microsoft site? Is the content on this blog “authoritative”? As we’ve said for years – we hear ya! The Exchange team blog has moved to a new home on TechNet. The new url – blogs.technet.com/exchange, and the branding should answer the above two questions. Exchange blog content is authoritative. Blog posts are written by Exchange product group members, including program managers, developers, testers, and experts from the support and field organizations. Technical posts go through a tech review by one or more subject matter experts. In some cases, the author himself/herself is the one with the most insight or knowledge of a component or feature that no additional tech review is required or possible. That is not to say that there can never be any mistakes. But we take quality of posts seriously and if there are problems - we work quickly to get them addressed. Eventually, you’ll find a lot of the useful content published on the blog being incorporated in product documentation. The blog allows us to get important content to you quickly, share timely announcements and opinions, and more importantly, to continue the conversation with you and get your valuable feedback. We’d like to draw your attention to some of the changes: URLs: One of the requirements for the move to TechNet was a seamless user experience for you. You can continue to access the blog using the msexchangeteam.com domain (and be automatically redirected to the new blog). We’ve ensured you can access previous posts using their old msexchangeteam.com URLs, so you can continue to use any links to previous posts. Older RSS feeds will also continue to work. You can also subscribe to the feed in both Atom and RSS formats from the shortcuts in the right column. New posts, however, will not have an "old" URL associated with them, but can still be accessed through the old RSS feed. Design: We’re happy to bring a clean new look to the blog, which highlights blog posts and does away with the distractions. The blog home page allows you, the reader to choose if you want to see all content or an excerpted view of the post contents on the home page. Community and other links have been moved to the footer section at the bottom of the page. We’re not quite done yet, so you’ll see incremental design changes and tweaks happen here. To help you feel "right at home" on this new site, we kept our "You had me at EHLO" bubbles graphic, but we might look to update that in the future too. The bubbles graphic has been updated too, to include a major theme from our blog’s history. Can you spot it? Navigation: The navigation bar on top allows you to easily access the Library, which includes links to blog-related applications and downloads, scripts and files, videos and the Exchange Server TechNet Library, which is the home of Exchange documentation on TechNet. You can also easily access the Exchange wiki, which contains community-contributed content, and the Exchange TechCenter. Browse by tags: As you may have noticed, we now have a tag cloud on the right. Search: The search bar is a part of the navigation bar, always accessible. Since we’re now on TechNet, search results are served by TechNet, and offer rich search functionality, including the ability to subscribe to search results, and view search results sorted by relevance, ratings, time published, or alphabetically. Comments: Now that we’re on the TechNet blog platform, you can use your TechNet login (LiveID) to comment. If you visit and post in Exchange or other forums on TechNet, you can use the same account to post comments. As always, we welcome your continuous feedback on blog posts, and blog ideas that you email us regularly via the "EHLO Idea"s alias. If you created an account with our previous blog site (something we never required) - you will still need to create one now, as we did not do any account/profile migration work. We request you to keep blog comments relevant to the post. Although the blog team and post authors from the Exchange team try to answer most questions, many times we can’t respond to questions of a support nature which require more details about your deployment and infrastructure. For such questions, we must direct you to Exchange forums. You can also contact Microsoft Support for assisted support by email or phone. Links to Exchange forums can be found in the new navigation bar on top of this blog and also in the footer, along with links to Support. Sharing: On each post page, you will see links to share the post on Twitter, and the familiar Facebook Like button. At the bottom of the post, you’ll see a number of additional sharing options to share the post on social networking and sharing services such as Digg, Delicious, LinkedIn and more. We hope you like the clean and simpler new look! It should also be quicker to load. A Big Thank You From The Exchange Blog Team To all contributors to the blog – thanks for sharing your knowledge, guidance, tips and opinions with the Exchange community. Keep the posts coming! To fellow bloggers in the Exchange community – if you have an Exchange blog or web site, send us the details so we can add them to the Cool Community Links page. To all our visitors - thanks for continuing to read, and above all – for the constant and relentless feedback. You help us continue to build the best messaging and collaboration platform in the world! Tell us what you think about our new blog home! The Exchange Blog TeamSqueaky Lobster rears its head again in the Microsoft employee giving campaign
This post is mainly for other softies who read the blog, but we hope our customers and partners enjoy it with us as the squeaky lobster has long been part of Exchange culture and lore and -- if we have anything to do with it -- will continue to embarrass the developer who started it all for years to come. A little over 11 years ago, a developer on the JET team made an infamous checkin, to create a reg key controlling some obscure perf counters, named "Squeaky Lobster". The name was a reference to a girl he had a crush on at the time who donated a squeaky lobster to the annual Microsoft Giving Campaign charity auction. He thought it was a funny thing to donate to a giving campaign and gee whilikers, he had a checkin to make that day that surely nobody else would ever see, so why not? And so, it began. Not with a bang, but a whimper. But it doesn't end there, no no no. Fortunately, said developer has some friends and co-workers who won't let him forget about this incident of his youth, and celebrate Squeaky Lobster Day every September 26 th by attempting to embarrass him. This year, the celebration is a little delayed, because the giving campaign doesn't start until October. and we decided that after 11 years (we turned it up to 11, awww yeah), it was time to donate another Squeaky Lobster to the giving campaign - except this time, it would be signed by Andrew himself! Unfortunately this auction is only available inside Microsoft, but for those of you who do work here we encourage you to please bid on this (priceless, really) piece of Exchange history and continue the noble tradition of never letting Andrew forget: (URL to donation site removed) - KC Lemson
