Speaking of the Melissa virus
As an Exchange Support Engineer, I dread the onset of any virus that will affect our customers. However, given that my name is Melissa, this virus was particularly painful for me! Imagine answering a support call during this outbreak “Thank you for calling Microsoft Exchange Support, this is Melissa” only to hear a deafening ‘click’ on the other end. A more typical response to my greeting was an awkward silence followed by “You’re kidding, right?” For a time, I seriously considered using Missy or even Mel when answering calls at work. A lot of customers would tease me that I was the Melissa that spurned the guy that started all of this. But I was ok with it, hey if people needed someone to blame, I’m a big girl, I can take it. Of course my co-workers couldn’t resist taking advantage of a ripe situation. They creatively decorated my cube with yellow police tape and assorted anti-virus CDs. But it was all in fun and I kept my sense of humor about it. It started to get a little extreme though when some of my emails would bounce back because of my name on the From line. Alas the Melissa virus is now a distant memory. However to this day, I have a former colleague who still refers to me only as “Virus”. Since he left Dove dark chocolate nuggets on my keyboard every morning, I am willing to overlook it. He actually left chocolates for all the women on our team. Truly this is a man who knows what women really want! So I think it’s only fair to dedicate this blog entry to my “Dove fairy” Edwah, from “Virus”. I miss you buddy! Melissa TraversExchange is 10 years old!
Seems like yesterday that Exchange 4.0 hit the market. In March of 1996 Exchange 4.0 was released. I thought I would give you a link for the geeks among you that have been along for the ride and for those that go even further back to ALL-IN-ONE, MailWorks, cc:Mail, IBM PROFS etc. ITPRO has a great look back if you're interested in taking a look back at the evolution of hardware, Exchange Clients, Mobile devices, OWA, etc. http://www.windowsitpro.com/Common/adforceimages/Decade_of_exchange.pdf It's been a whirl wind ride and now we are nearing Beta 2 of Exchange "12"! What will Exchange look like 10 years from now? What features would you want to see (hey why wait - ask for them now!). If Exchange 2016 was ready for release, what features would you be most excited by? So, take a look back, reflect on where we have been, then put on your thinking caps and tell us what you want to see in the next release and the one after that! - David EspinozaFirst post!!! of the Microsoft Exchange team blog
This is a group blog written by folks from the Microsoft Exchange server team. We are developers, testers, program managers, technical writers and product support engineers who work with Exchange. At the end of each blog entry, you'll see the author's name and a link to their bio. The bios of all participants can be seen in the "Team Bios" link on the left as well. We're planning on posting to this blog at least 3 times a week, with tips and tricks about Exchange, the history behind certain features or decisions, and other information about Exchange, Outlook, and email in general. And without further ado, the M drive...Property Sets in Exchange Server 2007
NOTE: This article has also been published in the official Exchange 2007 documentation - http://technet.microsoft.com/en-us/library/bb310768.aspx. We recommend that you check the documentation for the most up-to-date version. Overview Previous versions of Exchange did not rely on the usage of property sets to a great extent for applying permissions in the domain partition. While this was not an issue in typical deployments, this became an issue for distributed environments that delegated all tasks. Administrators in these environments had to assign permissions for a multitude of attributes for mail recipients, so that appropriate tasks could be delegated using a least privilege access model. Depending on the version of the Active Directory servers, this could have lead to a serious bloat in the Access Control Lists, thus increasing the size of the NTDS.DIT file. Exchange 2007 improves the delegation story by utilizing property sets for the vast majority of mail recipient attributes. Property Sets For those that are not familiar with property sets, a property set is a grouping of attributes that enables controlling access to a subset of an object's properties by setting one single Access Control Entry (ACE), rather than setting an ACE per individual property. Also, an attribute can only be a member of a single property set. For example, the Personal-Information property set includes properties such as street address and telephone number, both of which are properties of user objects. Property Set Usage in Exchange Server 2003 In Exchange Server 2003, the Exchange schema extension process added many Exchange related mail recipient attributes into the built-in Active Directory property sets, Personal Information and Public Information. The Exchange Enterprise Servers domain local security groups were assigned access to these property sets on the domain partitions during the domain preparation phase so that Recipient Update Service (RUS) could stamp objects. Public Information property set allowedAttributes formData allowedAttributesEffective forwardingAddress allowedChildClasses givenName allowedChildClassesEffective heuristics altRecipient hideDLMembership altRecipientBL homeMDB altSecurityIdentities homeMTA attributeCertificate importedFrom authOrig Initials authOrigBL msExchIMAddress autoReply msExchIMAPOWAURLPrefixOverride autoReplyMessage msExchIMMetaPhysicalURL cn msExchIMPhysicalURL co msExchIMVirtualServer company msExchInconsistentState deletedItemFlags msExchLabeledURI delivContLength msExchMailboxFolderSet deliverAndRedirect msExchMailboxGuid deliveryMechanism msExchMailboxSecurityDescriptor delivExtContTypes msExchMailboxUrl department msExchMasterAccountSid description msExchOmaAdminExtendedSettings directReports msExchOmaAdminWirelessEnable displayNamePrintable msExchOriginatingForest distinguishedName msExchPfRootUrl division msExchPFTreeType dLMemberRule msExchPoliciesExcluded dLMemDefault msExchPoliciesIncluded dLMemRejectPerms msExchPolicyEnabled dLMemRejectPermsBL msExchPolicyOptionList dLMemSubmitPerms msExchPreviousAccountSid dLMemSubmitPermsBL msExchProxyCustomProxy dnQualifier msExchQueryBaseDN enabledProtocols msExchRecipLimit expirationTime msExchRequireAuthToSendTo extensionAttribute1 msExchResourceGUID extensionAttribute10 msExchResourceProperties extensionAttribute11 msExchTUIPassword extensionAttribute12 msExchTUISpeed extensionAttribute13 msExchTUIVolume extensionAttribute14 msExchUnmergedAttsPt extensionAttribute15 msExchUseOAB extensionAttribute2 msExchUserAccountControl extensionAttribute3 msExchVoiceMailboxID extensionAttribute4 name extensionAttribute5 notes extensionAttribute6 o extensionAttribute7 objectCategory extensionAttribute8 objectClass extensionAttribute9 objectGUID extensionData oOFReplyToOriginator folderPathname otherMailbox internetEncoding ou kMServer pOPCharacterSet language pOPContentFormat languageCode protocolSettings legacyExchangeDN proxyAddresses mail publicDelegatesBL mailNickname replicatedObjectVersion manager replicationSensitivity mAPIRecipient replicationSignature mDBOverHardQuotaLimit reportToOriginator mDBOverQuotaLimit reportToOwner mDBStorageQuota securityProtocol mDBUseDefaults servicePrincipalName msDS-AllowedToDelegateTo showInAddressBook msDS-Approx-Immed-Subordinates sn msDS-Auxiliary-Classes submissionContLength msExchADCGlobalNames supportedAlgorithms msExchALObjectVersion systemFlags msExchAssistantName targetAddress msExchConferenceMailboxBL telephoneAssistant msExchControllingZone textEncodedORAddress msExchCustomProxyAddresses title msExchExpansionServerName unauthOrig msExchFBURL unauthOrigBL msExchHideFromAddressLists unmergedAtts msExchHomeServerName userPrincipalName msExchIMACL Personal Information property set assistant physicalDeliveryOfficeName c postalAddress facsimileTelephoneNumber postalCode homePhone postOfficeBox homePostalAddress preferredDeliveryMethod info primaryInternationalISDNNumber internationalISDNNumber primaryTelexNumber ipPhone publicDelegates l registeredAddress mobile st mSMQDigests street mSMQSignCertificates streetAddress otherFacsimileTelephoneNumber telephoneNumber otherHomePhone teletexTerminalIdentifier otherIpPhone telexNumber otherMobile thumbnailPhoto otherPager userCert otherTelephone userCertificate pager userSharedFolder personalTitle userSharedFolderOther X121Address However, when it came to delegation of permissions for management of mail recipients, many Active Directory administrators did not assign permissions to Exchange administrators using these property sets since they provided access to many additional non-Exchange related attributes. Property Set Usage in Exchange Server 2007 Exchange 2007 takes advantage of property sets by creating two new property sets exclusively for Exchange, rather than relying on pre-existing Active Directory property sets. This addresses several issues that existed with previous versions of Exchange: There is no longer a reliance on default Active Directory property sets, which addresses the uncertainty of those property sets as they could change in future release cycles of Windows Server Active Directory. Ensures that only attributes created by the Exchange schema extension are members of the Exchange specific property sets. Allows for the creation and deployment of a delegated security permission model with regards to management of Exchange mail recipient data. During the schema extension phase, Exchange 2007 performs several actions: Extends the schema with new classes and attributes. Creates the property sets, Exchange Information and Exchange Personal Information. Adds the appropriate attributes to the Exchange Information and Exchange Personal Information property sets. Exchange 2003 attributes that had been previously added to the Personal Information or Public Information property sets will be moved accordingly to the Exchange specific property sets. As a result of moving attributes between property sets, the Exchange 2003 recipient permission structure requires updating when implementing Exchange 2007 in a legacy environment. This is accomplished either via executing /PrepareLegacyExchangePermissions or /PrepareSchema. For more information on what /PrepareLegacyExchangePermissions actually does, please see http://www.microsoft.com/technet/prodtechnol/exchange/E2k7Help/4c32f70c-d42b-4bf4-995e-65b68a947194.mspx. The Exchange Information property set includes the attributes listed in the following table. In addition, Authenticated Users have read access to this property set. This allows authenticated users to look up certain pieces of information about mail recipients (e.g. via the Address Book). Exchange Information property set altRecipient altRecipientBL attributeCertificate authOrig authOrigBL autoReply autoReplyMessage deletedItemFlags delivContLength deliverAndRedirect deliveryMechanism delivExtContTypes dLMemberRule dLMemDefault dLMemRejectPerms dLMemRejectPermsBL dLMemSubmitPerms dLMemSubmitPermsBL dnQualifier enabledProtocols expirationTime extensionAttribute1 extensionAttribute10 extensionAttribute11 extensionAttribute12 extensionAttribute13 extensionAttribute14 extensionAttribute15 extensionAttribute2 extensionAttribute3 extensionAttribute4 extensionAttribute5 extensionAttribute6 extensionAttribute7 extensionAttribute8 extensionAttribute9 extensionData folderPathname formData forwardingAddress heuristics hideDLMembership homeMDB homeMTA importedFrom internetEncoding kMServer language languageCode mailNickname mAPIRecipient mDBOverHardQuotaLimit mDBOverQuotaLimit altRecipient altRecipientBL attributeCertificate authOrig authOrigBL autoReply autoReplyMessage deletedItemFlags delivContLength deliverAndRedirect deliveryMechanism delivExtContTypes dLMemberRule dLMemDefault dLMemRejectPerms dLMemRejectPermsBL dLMemSubmitPerms dLMemSubmitPermsBL dnQualifier enabledProtocols expirationTime extensionAttribute1 extensionAttribute10 extensionAttribute11 extensionAttribute12 extensionAttribute13 extensionAttribute14 extensionAttribute15 extensionAttribute2 extensionAttribute3 extensionAttribute4 extensionAttribute5 extensionAttribute6 extensionAttribute7 extensionAttribute8 extensionAttribute9 extensionData folderPathname formData forwardingAddress heuristics hideDLMembership homeMDB homeMTA importedFrom internetEncoding kMServer language languageCode mailNickname mAPIRecipient mDBOverHardQuotaLimit mDBOverQuotaLimit altRecipient altRecipientBL attributeCertificate authOrig authOrigBL autoReply autoReplyMessage deletedItemFlags delivContLength deliverAndRedirect deliveryMechanism delivExtContTypes dLMemberRule dLMemDefault dLMemRejectPerms dLMemRejectPermsBL dLMemSubmitPerms dLMemSubmitPermsBL dnQualifier enabledProtocols expirationTime extensionAttribute1 extensionAttribute10 extensionAttribute11 extensionAttribute12 extensionAttribute13 extensionAttribute14 extensionAttribute15 extensionAttribute2 extensionAttribute3 extensionAttribute4 extensionAttribute5 extensionAttribute6 extensionAttribute7 extensionAttribute8 extensionAttribute9 extensionData folderPathname formData forwardingAddress heuristics hideDLMembership homeMDB homeMTA importedFrom internetEncoding kMServer language languageCode mailNickname mAPIRecipient mDBOverHardQuotaLimit mDBOverQuotaLimit The Exchange Personal Information property set includes the attributes listed in the following table. These attributes are sensitive in nature, so to ensure that normal users cannot look retrieve the data stored within these attributes, they are placed into a separate property set where Authenticated Users are not assigned read access. Exchange Personal Information property set msExchMessageHygieneFlags msExchMessageHygieneSCLDeleteThreshold msExchMessageHygieneSCLQuarantineThreshold msExchMessageHygieneSCLRejectThreshold msExchSafeRecipientsHash msExchSafeSendersHash msExchUMPinChecksum - Ross Smith IVFrom 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) DeveloperOffice 365 Message Attribution
When a message arrives at Office 365, one of the first things we need to do is figure out which organization it belongs to. At first, this sounds simple – just look at the recipient, right? Well, it is more complicated than that, because of Hybrid and complex routing scenarios.The SDE career path at Microsoft
In Microsoft, there are a number of standard job titles. The most important one is SDE – Software Development Engineer. The rest can be considered the supporting cast (one requirement of being an SDE is to be so supremely confident that such a statement as the previous one can be made without actually laughing out loud while doing so). The life of an SDE at Microsoft is as close to heaven as a computer geek can get. Chocolate donuts for breakfast, a quick bite in the cafeteria for lunch, any fast food at all for dinner, and before, in between and after is glorious coding. Of course, other things intervene occasionally – like annoying testers who keep insisting the code actually works, or program managers who insist the code actually be useful to someone (honestly, I don’t know where they find these people), or bosses who insist on “talking”, sometimes even in the form of meetings. These are unfortunately necessary evils and an SDE will tolerate them and, on occasion, even indulge them from time to time. There is a cloud on the horizon in many SDE’s careers however, and it’s called management. At Microsoft, there aren’t a whole lot of real managers, they are mostly technical people who at one time or another did real work and then – probably due to chemical imbalances in the brain brought on by a diet of donuts, cafeteria and fast food – suddenly “stepped up” to the management plate. It’s pretty insidious. One day you’re a happy go lucky developer enjoying work to its legal limit and with masses of extremely marketable skills, and then your boss suggests that maybe you should take on a report or two. Just junior people, you understand, to see how you like it. Zap. Six months later you have a team of 15 and you can’t write a line of code to save your life anymore (but you can create a mean Powerpoint presentation). Microsoft does have an alternative career path for SDE’s (and the other, lesser, disciplines) which enables an IC (individual contributor) to remain an IC but continue to progress in that role. While the ultimate destination of a manager is a VP, the equivalent IC role for an SDE is a DE (Distinguished Engineer). DE is quite a bit harder to attain then VP, actually. An intermediate IC role is usually some kind of architect. I know some people who have followed this path successfully, but it is a bit of a harder road to hoe. In my case, I’ve taken the Bilbo Baggins approach (“There and Back Again”). Prior to 1998, I had spent 13 years as an IC (not all at Microsoft, although I wish I had joined the company in ’85). I then took on two reports. Then six. Then, after Exchange 2000 shipped, I took on a team of fifteen. Then suddenly I had seventy developers working for me. I even attained the exalted level of PUM (Product Unit Manager). Those were the dark times. I forgot how to code. I forgot how to debug. I pretty much forgot how to think. I finally snapped out of it and ever since I’ve been striving once more for IC status. I currently am down to a team of five, but I’m not likely to get much lower than that any time soon. No matter. I’m coding again and once more feel like a contributing member of the team rather than a roadblock on the way to success. And those chocolate donuts are yummy. - Jon Avner
