One of the great things the Exchange Product Group did, starting with Exchange 2007, was to start generating informative log files as part of the installation/upgrade process. Gone are the days when you had no log files and you got 75% of the way through and the setup program bombed with some generic error and that's all you got (maybe an event in the Event Viewer as well, but still not a whole lot to go on). These logs are written to C:\ExchangeSetupLogs by default.
However, I recently worked on an issue with one of my customers on an Exchange 2010 SP3 upgrade. They had all the setup logs, but hadn’t followed any of the best practices I’m about to talk about. This resulted in having to deal with VERY large log files in the C:\ExchangeSetupLogs directory that had everything in them since the server was first built. So, I wanted to post some information out on best practices related to these files…
One of our best practices *is* to keep all your setup logs…which most customers do. However, there are a few related best practices I wanted to share that go along with this:
The biggest advantage to following these best practices is simply that if you run into issues with an upgrade (or after), you’re not dealing with the huge log files (especially if opening them with Notepad) or a directory with hundreds and hundreds of files in it. This can make troubleshooting a little easier. Hopefully, you’ll never need these files, but that never seems to be the way it works out.
As I mentioned in the Current Cumulative Updates for Office -Q3 2012 post, each quarter I will post information on the latest updates for the Office for Windows and Office for Macintosh products.
The information below is being provided regarding the most currently available updates available for the supported Windows and Macintosh versions of Office as of January 3, 2013.
As a reminder on why I'm providing this information and how it should be used, please see my Keeping Up with Office Updates post which discusses the cumulative updates for Office (and Outlook in particular) that companies need to be aware of and push out to their users.
Note: Each of the KB articles includes the list/links for all the Office products (Word, Excel, Outlook, etc). Most of you focus on Outlook and that’s the only ones required and is also provided separately but I wanted to provide the larger “Office” list in case you want it.
As a reminder, Microsoft Update does *NOT* make the cumulative updates available to users. These have to be downloaded and either installed independently or deployed using tools such as WSUS, SCCM, etc.
Note: Each of the KB articles includes the link for downloading the package which updates ALL Office Products…there are not separate updates for each of the various components of Office as there is with the Windows releases.
Several customers are reporting an issue after installing the July 2013 Security Update for Lync 2013 related to icons not be rendered correctly or missing entirely. This issue has been found to be related to other updates missing on the workstation, as those other updates are NOT part of the July 2013 Security Update…but are required for other changes in the Lync 2013 Client to work properly.
In addition to the July 2013 security update for Lync 2013 (KB2817465), you MUST also install the latest Office 2013 updates for MSO.DLL and MSORES.DLL (KB2817491). These are available from Windows Update or downloaded via the KBs.
We are working to have the KB for the July 2013 Security Update for Lync 2013 (KB2817465) updated to include this information.
Recently a customer asked me for a way to determine which Lync 2013 client their users had installed (basic vs. full) using the registry. We don't have this well documented (ok, to be honest I could not find any documentation on it), so I did some testing in my lab and put together the following information for them...which I thought I'd share as I'm sure others may have this same question.
If you just want to verify if ANY version (Basic, Full, or as part of Office 2013 Pro) of Lync 2013 client is installed, you can use the following registry key:
For 64-bit Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\15.0\Registration\{0EA305CE-B708-4D79-8087-D636AB0F1A4D}
ProductName = "Microsoft Lync 2013"
For 32-bit Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\15.0\Registration\{0EA305CE-B708-4D79-8087-D636AB0F1A4D}
The following registry value will exist if the Lync 2013 Basic client is installed:
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\Office15.LYNCENTRY
DisplayName = “Microsoft Lync Basic 2013”
Note the name of the key, it is DIFFERENT between Lync 2013 Basic and Full.
The following registry value will exist if the Lync 2013 Full client is installed:
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\Office15.LYNC
DisplayName= “Microsoft Lync 2013”
Lync 2013 as part of Office 2013 Pro does NOT have its own registry key, since its installation is controlled by the Office 2013 Pro setup. So, a way to detect if Lync 2013 is installed as part of Office 2013 Pro would be to use the first key I provide above (to determine Lync 2013 is on the system) and the ABSENCE of the other keys above would denote that Lync 2013 was installed as part of Office 2013 Pro.
Hope this helps. Note that this is NOT an all inclusive list of registry keys...as there are other registry keys that could also be used that exist depending on if Lync 2013 is installed and/or which version of Lync 2013 is installed.
As I mentioned in the Current Cumulative Updates for Office - Q3 2012 post, each quarter I will post information on the latest updates for the Office for Windows and Office for Macintosh products.
The information below is being provided regarding the most currently available updates available for the supported Windows and Macintosh versions of Office as of October 1, 2013.
This came from doing this command but one of the fields was not exporting…
[PS] C:\scripts>Get-MailboxDatabaseCopyStatus e2k10DB01 | Select @{ n = "OutstandingDumpsterRequests";e={$_.OutstandingDumpsterRequests}} |export-csv test.txt
Use this for any Fail Exports to CSV or similar to this...."Microsoft.Exchange.Management.SystemConfigurationTasks.DumpsterRequestEntry[]"
You need to 1) use a Select Statement and 2) modify the Values not exporting.
Example.
Get-MailboxDatabaseCopyStatus e2k10DB01 | FL "OutstandingDumpsterRequests" | Export-CSV C:\Test.txt
This will be my only entry:
"Microsoft.Exchange.Management.SystemConfigurationTasks.DumpsterRequestEntry[]"
Note: I remove the Export-CSV and this shows the correct {} Value on the Screen.
So Next just to show this one Value.
Get-MailboxDatabaseCopyStatus e2k10DB01 | Select @{ n = "OutstandingDumpsterRequests";e={$_.OutstandingDumpsterRequests}} |Export-CSV C:\test.txt
My Entry will match the Output on the Screen
{}
So why does this work? To specify a calculated property we need to create a hash table; that’s what the @{} syntax does for us. Inside the curly braces we specify the two elements of our hashtable: the property Name (in this case, OutStandingDumpsterRequest) and the property Expression (that is, the script block we’re going to use to calculate the property value). The Name property is easy enough to specify; we simply assign a string value to the Name, like so
n = "OutstandingDumpsterRequests"
And, believe it or not, the Expression property (which is separated from the name by a semicolon)isn’t much harder to configure; the only difference is that Expression gets assigned a script block rather than a string value:
e={$_.OutstandingDumpsterRequests}
Thus this outputs the Data into the CSV
@{ n = "OutstandingDumpsterRequests";e={$_.OutstandingDumpsterRequests}}
Does NOT export the data for Outstanding DumsterRequest….
[PS] C:\scripts>Get-MailboxDatabaseCopyStatus e2k10DB01 | Select "Identity","Name","DatabaseName","Status","MailboxServer","ActiveDatabaseCopy","ActivationSuspended","ActionInitiator","ErrorMessage","ErrorEventId","ExtendedErrorInfo","SuspendComment","SinglePageRestore","ContentIndexState","ContentIndexErrorMessage","CopyQueueLength","ReplayQueueLength","LatestAvailableLogTime","LastCopyNotificationedLogTime","LastCopiedLogTime","LastInspectedLogTime","LastReplayedLogTime","LastLogGenerated","LastLogCopyNotified","LastLogCopied","LastLogInspected","LastLogReplayed","LogsReplayedSinceInstanceStart","LogsCopiedSinceInstanceStart","LatestFullBackupTime","LatestIncrementalBackupTime","LatestDifferentialBackupTime","LatestCopyBackupTime","SnapshotBackup","SnapshotLatestFullBackup","SnapshotLatestIncrementalBackup","SnapshotLatestDifferentialBackup","SnapshotLatestCopyBackup","LogReplayQueueIncreasing","LogCopyQueueIncreasing","OutstandingDumpsterRequests","OutgoingConnections","IncomingLogCopyingNetwork","SeedingNetwork","ActiveCopy"| Export-CSV test.txt
But this DOES
[PS] C:\scripts>Get-MailboxDatabaseCopyStatus e2k10DB01 | Select "Identity","Name","DatabaseName","Status","MailboxServer","ActiveDatabaseCopy","ActivationSuspended","ActionInitiator","ErrorMessage","ErrorEventId","ExtendedErrorInfo","SuspendComment","SinglePageRestore","ContentIndexState","ContentIndexErrorMessage","CopyQueueLength","ReplayQueueLength","LatestAvailableLogTime","LastCopyNotificationedLogTime","LastCopiedLogTime","LastInspectedLogTime","LastReplayedLogTime","LastLogGenerated","LastLogCopyNotified","LastLogCopied","LastLogInspected","LastLogReplayed","LogsReplayedSinceInstanceStart","LogsCopiedSinceInstanceStart","LatestFullBackupTime","LatestIncrementalBackupTime","LatestDifferentialBackupTime","LatestCopyBackupTime","SnapshotBackup","SnapshotLatestFullBackup","SnapshotLatestIncrementalBackup","SnapshotLatestDifferentialBackup","SnapshotLatestCopyBackup","LogReplayQueueIncreasing","LogCopyQueueIncreasing",@{ n = "OutstandingDumpsterRequests";e=$_.OutstandingDumpterRequests}},"OutgoingConnections","IncomingLogCopyingNetwork","SeedingNetwork","ActiveCopy" | Export-CSV test.txt
Note: You may have to do this to several properties but it should work!
My customer decided that they needed to block OWA externally but leave it open internally. Why? OWA does pose a security risk having e-mail open to the internet. Yes, passwords, firewalls, etc all provide levels of protection, but it is still an opening for someone to get in through. They use OWA internally for those who do not have a full Outlook client, so we have to leave that portion open. They presently have Exchange 2003, but will be moving to 2010 relatively soon. The difficulty here comes from mobile devices that still need access to the Internet, so we could not just turn off the whole website in IIS as ActiveSync leverages that service.
First, there are a few ways to accomplish this. The best way would be to use ISA/TMG to filter the OWA requests before they ever reached the front end servers.
Exchange Services Publishing Deployment Optionshttp://technet.microsoft.com/en-us/library/dd861446.aspx
Publishing Exchange with Forefronthttp://technet.microsoft.com/en-us/library/ee921443.aspx
Everyone runs UAG or has a advanced firewall to do this, right? No? Well then, let’s move on. The second option would be to block requests from the load balancers. Unfortunately, we needed internal access as well, so this would not really be a solid option. That left us with changing something inside IIS on the FE.
For Exchange 2003, we could add the external VIP of the router to the list of blocked IPs inside of IIS on the FE box. Thus, any requests coming into the Windows IIS would receive a blocked IP error, and this would block access. We chose this route because it was simple (we did not need to get the network team involved), easily testable, and leaves it inside a Microsoft supported environment. The downside is that we had to make the change to every front end box that faced the external interface, which was six.
Granting or Denying Access to a Computer (IIS 6)http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/128d26dd-decb-42f9-8efb-30724d1a2f29.mspx?mfr=true
Now, this ONLY works if you have segregated FE/BE servers. If you have an all-in-one, this will NOT work because the FE has to proxy to the BE. The BE, which uses the same IIS configuration of FE, would block the IP as well.
One thing we also did was to give the users “this service is no longer available, please contact the help desk.” This would (hopefully) tell the users that OWA is gone and they can no longer use it. Users also received notifications during the week, but they may have been on vacation or similar, or, like me, just not read the email.
Creating Custom Error Messageshttp://support.microsoft.com/kb/814869
Looking forward, in 2007 and 2010, there are easier ways. I would suggest creating a new website with a unique IP in IIS and only adding ActiveSync to that website using a cmdlet. That would give us a website hosted on the box that served the ActiveSync devices but nothing else, leaving the OWA open for internal access. The firewall would point to this website/IP on the CAS. We could also create a virtual directory under there for /OWA and /Exchange which would serve up the generic ““this service is no longer available, please contact the help desk” message as the default webpage. This makes it easy to mange, monitor, and control traffic to. You could also do the same in 2003 with a new website with a ActiveSync virtual directory, but in 2003, this is a little more complicated because of the lack of powershell to create the site for you.
How to Create an Exchange ActiveSync Virtual Directoryhttp://msdn.microsoft.com/en-us/library/aa998812(EXCHG.80).aspx
Overview
In the ongoing administrator versus user fights, message size limits always seems to come up. Why? Users feel they need to attach that PowerPoint slide deck with movies and sound that is well over 100MB and send it to everyone in the organization. Technically, yes, Exchange and Outlook can send this. Realistically, this is a really, really bad idea because it will bog down the server while it sends and transaction logs will fill up. So, we implement size limits on the sending of e-mails to prevent users from harming themselves and the server. Unfortunately, this requirement should come from the business unit to the IT department to tell IT how large a message is acceptable. Normally, IT departments decide on what their systems can support and choose a number there. I have seen organizations with 1MB size limits and some up to 30MB. As storage and bandwidth increase, message sizes follow suit. The big question you need to ask is can your organization survive someone accidently sending that 30MB PowerPoint attachment to everyone in the GAL? Plan for the worst and hope for the best.
The concept behind message size limits works in a "reverse funnel" process. The idea is that messages entering the environment that do not meet the size requirements get filtered/rejected first. Typically, you would want the smallest message size in the perimeter of the network, on an Edge server or appliance. That way, the message over the size limit never reaches the Exchange environment where it starts to become more costly to block. This minimizes the unnecessary processing of messages. Now, internally is probably a different story as internal traffic is probably cheaper. Here, message limits need to go on the Hub servers to intercept messages in transit. Different departments can have different limits, such as an art department that send large graphics to one another. Of course, e-mail is not the best way to share documents (that is what SharePoint is for) but we digress. For departments, you will want to configure this on the user level because this is the first step checked in the message size limit process. User limits can override organizational controls, so be careful when setting these.
In Exchange 2010, the default message size is 10MB with a recipient limit of 5,000. The total message size is what matters, and this includes the header, attachments, and content of the message. Exchange can filter by attachment size as well, but more organizations filter by total size. Recipient limits count as unique entries in the TO, CC, or BCC field, so that a distribution list would count as a single recipient. The good news is that Outlook will check for restrictions before sending, so the user will receive an over the limit message before the mail message enters the Exchange environment. This is a good thing because in the early days, a user could attach a 1GB file, send it, wait for it to process, THEN Exchange would send a message saying it was over the limit.
Understanding Message Size Limits
Setting Mailboxes and Public Folders
Working from the mailbox out, this is how to configure size limits for an organization.
1. For mailboxes, perform the following steps:
a. In the console tree, navigate to Recipient Configuration > Mailbox.
b. In the result pane, select the mailbox for which you want to configure message size limits.
c. In the action pane, under the mailbox name, click Properties.
d. In <Mailbox User> Properties, click the Mail Flow Settings tab.
e. Select Message Size Restrictions, and then click Properties.
f. Proceed to Step 3.
2. For mail-enabled public folders, perform the following steps:
a. In the console tree, click Toolbox.
b. In the result pane, click Public Folder Management Console, and then in the action pane, click Open Tool. The Public Folder Management Console appears.
c. In the console tree, expand Default Public Folders, and then click the public folder that you want to configure. If the public folder you want to configure is a top-level public folder, click Default Public Folders.
d. In the result pane, select the public folder for which you want to configure message size limits.
e. In the action pane, under the public folder name, click Properties.
f. In <Public Folder> Properties, click the Mail Flow Settings tab.
g. Select Message Size Restrictions, and then click Properties.
h. Proceed to Step 3.
3. In the Message Size Restrictions dialog box, select the Maximum message size (in KB) check boxes to set the maximum size for messages that can be sent and received by the mailbox or public folder. Use the corresponding text boxes to type the maximum message size allowed in kilobytes (KB). The message size must be from 0 through 2,097,151 KB. If a message larger than the specified size is sent to the mailbox or public folder, the message will be returned to the sender with a descriptive error message. Click OK to return to the Mail Flow Settings tab.
4. Click OK.
Configure Message Size Limits for Mailboxes or Mail-Enabled Public Folders
Setting the Transport
Next step is to configure the Hub transport settings. Fairly easily, these are configurable through the EMC or EMS, depending on whichever you are more comfortable with. This works the same on an Edge server, but if your organization uses something different, then get with the product vendor to determine the correct way to configure the device.
Included in the content below is information about global settings. These affect all the hub transport servers in their configuration. While you cannot change the message size limits per hub server, you can change some aspects such as maximum recipients per message.
Configure Transport Settings Properties
Set-TransportConfig
Outside of Outlook
Message limits come into play in two more areas that lots of companies forget about. Entourage, or Outlook for Mac, uses EWS in Exchange 2010 to send messages. While the users are still affected by the organizational message limits, they have a separate configuration necessary to allow them to send large messages, or anything over the default 10MB. This article is for Exchange 2007, but it is applicable to Exchange 2010. Please note: Entourage HAS to be running the latest version that uses EWS as previous versions run WebDav, which is no longer available in Exchange 2010. This is a free upgrade.
Contact Microsoft for Entourage Upgrade
Allow Entourage to Send Large Attachments
Also, OWA has a separate entry for sending larger than 10MB attachments.
Configure Maximum Message Size in OWA
Finally, should you send a 9MB message in a 10MB environment and receive an error that your message is over the limit, blame message conversion. Essentially, Outlook runs MAPI whereas the Internet runs MIME, so there are conversion penalties for this. It used to be around 30%, as in, your 9MB message is really 12MB, but it has come down in Exchange 2010.
Frequently Asked Questions About MIME and Content Conversion
Recipient Restrictions
Beyond the size of a message, an organization can configure other limits, such as limits on who can send to whom. For example, an organization may want to limit who can send to “All Mail Recipients” as it contains 90,000 mailboxes. Administrators can apply this to distribution lists as well as to mailboxes.
Understanding Recipient Restrictions
Guidance
The Exchange team set the message size limit at 10MB for good reason. Most companies running Exchange 2010 have solid and robust Internet connections as well as the hardware needed to run large messages. The question becomes why should a company increase these limits? Earlier, the purpose of e-mail came up, as in, should a company even use it to send documents. There are a lot of other systems available that are optimized to handle large document stores, such as SharePoint. Exchange does not function well as a document repository, but it does function. Sending a link to a document in a SharePoint site takes up much less space, provides for more accountability, and is overall cheaper than maintaining large Exchange databases.
However, many companies do not use SharePoint or a similar product. Thus, it comes down to Exchange to offer this solution. If a user can send a 20MB attachment, there will be 20MB attachments floating around the Exchange environment. Look at what the organization does and what messages they send to each other. Art departments or engineering firms that send CAD drawings may have solid arguments to raise the limits, but PowerPoint slide decks or simple photos may not. Some tracking log analysis will detail what is actually sent over the environment and help establish the smallest message size possible to fit the organization.
Why do we need another blog? Because our team has some pretty unique experiences we would like to share with the world, so hopefully you can use our knowledge to make your lives better, at least as it realtes to messaging! This blog will contain the collected knowledge of the Messaging Dedicated Support Engineers (DSE) for Microsoft's communications companies. In the messaging team, we work primarily with all versions of Exchange, Exchange ActiveSync (EAS) which includes non-Windows Mobile devices like Droids and iDevices, Blackberries, Enterprise Voice/Lync, Outlook, and integration of these technologies with other Microsoft products, such as Threat Management Gateway/User Access Gateway (TMG/UAG), Forefront Identity Manager (FIM), Active Directory, and others that seem to pop up in our day to day work. Thus, you can expect to read about a wide variety of issues and recommendations about a lot of technologies that interact with Exchange but not always just the back end mail infrastructure.
So, what is a DSE? DSE engineers work as a part of the Premier Field Engineer (PFE) family, a group of specialized engineers work directly with customers. PFE has two teams; transactional and dedicated. Transactional members tend to go from one customer to another as needed, providing some excellent onsite support and guidance to them. DSE engineers, on the other hand, typically have one to four customers who they work directly with on a (you guessed it) dedicated role. We work every day with some of Microsoft's largest customers who run our products. There are DSEs for nearly every Microsoft technology, so we are a big family. We like to focus on proactive work to prevent problems from occurring, such as operational improvements like backups and monitoring, but we are also there for our customers when technology or processes does not always work right.
What can you expect from this blog? Well, inside our Communications team, we have several members who deal with some of the largest communications companies in the world, so we see a lot of issues, technology and otherwise, that we would like to share. Now, issues do not always mean a fire drill or someone messed something up, on the contrary, I use the term to indicate something that could use improvement. So, you could expect to read a blog post about how to improve backups, tweaking authentication settings, undocumented features in PowerShell, and some really cool scripts for report generation. Part of the benefit of the communications industry is that it is very dynamic with the mergers and divestitures, so we asee large company issues as well as what can occur in smaller organizations.
What we will not do is divulge any confidential information about our customers, so please, don’t ask! We will work in personal anecdotes, stories, humor, tragedy, and anything else to make it interesting so it isn’t just your standard stale tech note. You can expect stories about cars, military history, pets, kids, spouses, and living in various regions of the States as well as travel around the world. Yet somehow, we will relate it back to messaging, promise!
We will try and update this blog at least once a month, possibly more depending on what information we want to/can share. We may even invite guest speakers from other portions of Microsoft to weigh in on discussions, such as AD team members or people from the product group.
Thanks again!
Message tracking versions
· Exchange 2003
o Structure is different, still csv but fields are not compatible to Exchange 2007 or Exchange 2010
o Message tracking will stop at last Exchange 2003 Server.
· Exchange 2007
o Message tracking from 2003/2010 will stop. Exchange 2007 tracking will only track on 2007 servers. The tracking fields are different.
· Exchange 2010
o Message tracking from 2003/2007 will stop. Exchange 2010 tracking will only be track on 2010 servers…the tracking fields are different.
Exchange Tracking logs fields / events
Exchange 2003 *See Appendix I
· http://support.microsoft.com/kb/246965
· http://support.microsoft.com/kb/821905
Exchange 2007 *See Appendix II
· http://technet.microsoft.com/en-us/library/cc539064.aspx
· http://technet.microsoft.com/en-us/library/cc539063.aspx
Exchange 2010 *See Appendix III
· This is really a reference to Exchange 2007 since the Exchange 2010 is NOT updated note there are some differences.
· http://technet.microsoft.com/en-us/library/bb124926(EXCHG.80).aspx
How to Track a Message via PowerShell effectively
Get-MessageTrackingLogs
So the best way to track a message is via its Message ID. You can retrieve this from the NDR or you can Search by the Sender / Recipient but note this will get all messages that recipient received or sender sent.
Now here is an issue with Exchange 2010 / Outlook 2010, the message in the Sent Item does not have a Message ID as that is assigned once its hits the Hub. L
So find the Message ID you need the Sender and Recipient Addresses and Subject and or Time will be Nice if they are sending a lot of messages between them…
1. Try with Sender/Recipient/Subject and Time (Give yourself a pretty good range). Now what the GUI does for you is filter on the Receive Event, but you can do it this way as well. Be careful of or event orders…you should sort by TimeStamp as this to the powershel. “|sort –Property TimeStamp” before any “|Fl”
Get-MessageTrackingLog –Sender “Sender@domain.com” –Recipients “Recipient@domain.com” -MessageSubject “Subject of Message” -Start "3/28/2011 8:00AM" -End "3/28/2011 5:00PM"
NOW be careful! In this example this is a Single Message caught. That will not always be the case.
2. Next, you Add the | FL Sender, Recipients, MessageSubject, MessageId
Get-MessageTrackingLog –Sender “Sender@domain.com” –Recipients “Recipient@domain.com” -MessageSubject “Subject of Message” -Start "3/28/2011 8:00AM" -End "3/28/2011 5:00PM" | FL Sender, Recipients, MessageSubject, MessageId
Now look at the MessageID and then we will track the message via MessageID. This is the BEST way to track a message.
3. Now, add the –MessageID “MessageID” and change the |FL * (this gets all fields)
Get-MessageTrackingLog –Sender “Sender@domain.com” –Recipients “Recipient@domain.com” -MessageSubject “Subject of Message” -Start "3/28/2011 8:00AM" -End "3/28/2011 5:00PM" –MessageID “MessageID” | FL *
Hint: PSComputerName is the top of each entry.
4. Ok, now that we got this what does it mean?
a. Since ClientHostName and ServerHostName that is telling me the message was sent from this server to itself. (this was down with a Powershell SMTP Send Script). So typically the ClientHostName will be the Remote Server Submitting the message.
b. Since Source is SMTP, and the Event is Receive. That means the ClientHostName Submitted the message via SMTP to the ServerHostName.
c. EventData I can also tell this was the First hop in the Org.
d. Ok, I receive it what next…
e. Notice the ClientHostName and the ServerHost name are not changed. Client is not the CAS server and the Server is the Mailbox Role Server
f. Since the Source is StoreDriver and Event is Delivery, the message was submitted to the store.
First PowerShell Output….
[PS] C:\>Get-MessageTrackingLog -Sender User19-DB01@TailSpinToys.com -Recipients User1-DB01@TailSpinToys.com -MessageSubject "Origins of Legislation" -Start "4/19/2011 4:43:30 PM" -End "4/19/2011 4:50:30 PM" -MessageID "1cd4eba2-d158-4ea1-81a7-4dbbc659bd13@LAB-E2K10CSHT01.TailSpinToys.com" |fl *
PSComputerName : lab-e2k10csht01.tailspintoys.com
RunspaceId : a241bdf5-c2c6-4c99-8e5a-b395faa5e67a
Timestamp : 4/19/2011 4:45:30 PM
ClientIp : fe80::89dc:2ad8:e3b:c03%13
ClientHostname : LAB-E2k10CSHT01
ServerIp : fe80::89dc:2ad8:e3b:c03%13
ServerHostname : LAB-E2k10CSHT01
SourceContext : 08CDCCED60881B31;2011-04-19T21:45:30.419Z;0
ConnectorId : LAB-E2K10CSHT01\Default LAB-E2K10CSHT01
Source : SMTP
EventId : RECEIVE
InternalMessageId : 270
MessageId : <1cd4eba2-d158-4ea1-81a7-4dbbc659bd13@LAB-E2K10CSHT01.TailSpinToys.com>
Recipients : {User1-DB01@TailSpinToys.com}
RecipientStatus : {}
TotalBytes : 4146
RecipientCount : 1
RelatedRecipientAddress :
Reference :
MessageSubject : Origins of Legislation
Sender : User19-DB01@TailSpinToys.com
ReturnPath : User19-DB01@TailSpinToys.com
MessageInfo : 0aI: NTS:
MessageLatency :
MessageLatencyType : None
EventData : {[FirstForestHop, LAB-E2K10CSHT01.TailSpinToys.com]}
ClientIp :
ServerIp :
ServerHostname : LAB-E2K10MBX02
SourceContext : 08CDCCED60881B32;2011-04-19T21:45:30.575Z;0
ConnectorId :
Source : STOREDRIVER
EventId : DELIVER
TotalBytes : 4318
MessageInfo : 2011-04-19T21:45:30.450Z;SRV=LAB-E2K10CSHT01.TailSpinToys.com:TOTAL=0
MessageLatency : 00:00:00.2970000
MessageLatencyType : EndToEnd
EventData : {[MailboxDatabaseName, e2k10db01]}
Same Example Pulled from Excel to Compare Fields
#Fields:
date-time 2011-04-19T21:45:30.560Z
client-ip fe80::89dc:2ad8:e3b:c03%13
client-hostname LAB-E2k10CSHT01
server-ip fe80::89dc:2ad8:e3b:c03%13
server-hostname LAB-E2k10CSHT01
source-context 08CDCCED60881B31;2011-04-19T21:45:30.419Z;0
connector-id LAB-E2K10CSHT01\Default LAB-E2K10CSHT01
source SMTP
event-id RECEIVE
internal-message-id 270
message-id <1cd4eba2-d158-4ea1-81a7-4dbbc659bd13@LAB-E2K10CSHT01.TailSpinToys.com>
recipient-address User1-DB01@TailSpinToys.com
recipient-status
total-bytes 4146
recipient-count 1
related-recipient
-address
reference
message-subject Origins of Legislation
sender-address User19-DB01@TailSpinToys.com
return-path User19-DB01@TailSpinToys.com
message-info 0aI: NTS:
directionality Originating
tenant-id
original-client-ip fe80::89dc:2ad8:e3b:c03%13
original-server-ip fe80::89dc:2ad8:e3b:c03%13
custom-data S:FirstForestHop=LAB-E2K10CSHT01.TailSpinToys.com
date-time 2011-04-19T21:45:30.747Z
client-ip
server-ip
server-hostname LAB-E2K10MBX02
source-context 08CDCCED60881B32;2011-04-19T21:45:30.575Z;0
connector-id
source STOREDRIVER
event-id DELIVER
total-bytes 4318
message-info 2011-04-19T21:45:30.450Z;SRV=LAB-E2K10CSHT01.TailSpinToys.com:TOTAL=0
original-client-ip
original-server-ip
custom-data S:MailboxDatabaseName=e2k10db01
Compare table: Green only from Logs, Blue only from PwShell
PWShell
Logs
Actual Data
Timestamp
date-time
2011-04-19T21:45:30.560Z
ClientIp
fe80::89dc:2ad8:e3b:c03%13
ClientHostname
client-hostname
LAB-E2k10CSHT01
ServerIp
ServerHostname
server-hostname
SourceContext
source-context
08CDCCED60881B31;2011-04-19T21:45:30.419Z;0
ConnectorId
LAB-E2K10CSHT01\Default LAB-E2K10CSHT01
Source
source
SMTP
EventId
event-id
RECEIVE
InternalMessageId
internal-message-id
270
MessageId
message-id
<1cd4eba2-d158-4ea1-81a7-4dbbc659bd13@LAB-E2K10CSHT01.TailSpinToys.com>
Recipients
recipient-address
User1-DB01@TailSpinToys.com
RecipientStatus
TotalBytes
total-bytes
4146
RecipientCount
recipient-count
1
RelatedRecipientAddress
related-recipient-address
Reference
MessageSubject
message-subject
Origins of Legislation
Sender
sender-address
User19-DB01@TailSpinToys.com
ReturnPath
return-path
MessageInfo
message-info
0aI: NTS:
directionality
Originating
custom-data
MessageLatency
MessageLatencyType
None
EventData
{[FirstForestHop, LAB-E2K10CSHT01.TailSpinToys.com]}
Advanced PowerShell Examples
Get-ExchangeServer | where {$_.isHubTransportServer -eq $true -or $_.isMailboxServer -eq $true} | Get-MessageTrackingLog -MessageId "<messageid>" | Select-Object <commaseparatedfieldnames> | Sort-Object -Property <field>
Get-ExchangeServer | where {$_.isHubTransportServer -eq $true -or $_.isMailboxServer -eq $true} | Get-MessageTrackingLog -MessageId "ba18339e-8151-4ff3-aeea-87ccf5fc9796@contoso.com" | Select-Object Timestamp,ServerHostname,ClientHostname,Source,EventId,Recipients | Sort-Object -Property Timestamp
What does this do? It searches every Exchange Server (Hub and Mailbox) for the Message ID listed, selects specific attributes and then Sorts them…
In this case, it dumps out the Timestamp,ServerHostname,ClientHostname,Source,EventId,Recipients in a nice easy to read format…
[PS] C:\Windows\system32>Get-ExchangeServer | where {$_.isHubTransportServer -eq $true -or $_.isMailboxServer -eq $true}
| Get-MessageTrackingLog -MessageId "1cd4eba2-d158-4ea1-81a7-4dbbc659bd13@LAB-E2K10CSHT01.TailSpinToys.com" | Select-Ob
ject Timestamp,ServerHostname,ClientHostname,Source,EventId,Recipients | Sort-Object -Property Timestamp
[PS] C:\Windows\system32>
Using ConvertTo-MessageLatency.ps1 with Get-MessageTrackingLog!
[PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>Get-MessageTrackingLog -MessageId "1cd4eba2-d158-4ea1-81a7-4
dbbc659bd13@LAB-E2K10CSHT01.TailSpinToys.com" | .\ConvertTo-MessageLatency.ps1
ComponentServerFqdn : LAB-E2K10CSHT01.TailSpinToys.com
ComponentCode : TOTAL
ComponentName : Total Server Latency
ComponentLatency : 00:00:00
[PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>
Appendix I
Exchange 2003
Fields:
Field number
Field name
Description
Date
Date of the event.
2
Time
Greenwich mean time of the event.
3
Client-IP
IP of connecting client.
4
Client-hostname
Hostname of connecting client.
5
Partner-name
Name of the messaging service that the message is handed off to. In Exchange 2000, the service can be: SMTP, X400, MAPI, IMAP4, POP3, STORE. This is essentially the same as Exchange Server 5.5, but in Exchange 2000, there are more possibilities for this field.
6
Server-hostname
Hostname of the server that is making the log entry.
7
Server-IP
IP of the server that is making the log entry.
8
Recipient-address
Message recipient (SMTP or X.400 address).
9
Event-ID
Integer corresponding to the Event ID of the action logged, for example: sent, received, delete, retrieve.
10
MSGID
Message ID.
11
Priority
The priority is represented by -1 if low, 0 if normal, 1 if high
12
Recipient-Report-Status
A number representing the result of an attempt to deliver a report to the recipient: 0 if delivered, 1 if not delivered. This is used only for reports (non-delivery reports [NDRs], delivery receipts [DRs]). On other events, it is blank.
13
Total-bytes
Message size (in bytes).
14
Number-recipients
Total number of recipients.
15
Origination-time
Delivery time (in seconds) representing the time it takes to deliver the message. Determined from the difference between the timestamp and time encoded in Message ID. Only valid for messages within the Exchange organization (all versions); there is no requirement to decode other product message IDs such as Sendmail, and so on.
16
Encryption
For the primary body part: 0 if no encryption, 1 if signed only, 2 if encrypted. This is per message, not per recipient.
17
Service-version
Version of the service making the log entry.
18
Linked-MSGID
If there is a MSG ID from another service, it is given here to link the message across services.
19
Message-subject
The subject of the message, truncated to 256 bytes.
20
Sender-address
Primary address of the originating mailbox, if known. This could be SMTP, X.400, or Distinguished Name (DN), depending on transport
Event-ID in Field 9:
Event Number
Event Type
0
Message transfer in
The message was received from a server, a connector, or a gateway.
Probe transfer in
An X.400 probe was received from a gateway, a link, or a message transfer agent (MTA).
Report transfer in
A delivery receipt or a non-delivery report (NDR) was received from a server, a connector, or a gateway.
Message submission
The message was sent by the client.
Probe submission
An X.400 probe was received from a user.
Probe transfer out
An X.400 probe was sent to a gateway, a link, or an MTA.
Message transfer out
The message was sent to a server, a connector, or a gateway.
Report transfer out
A delivery receipt or an NDR was sent to a server, a connector, or a gateway.
Message delivered
The message was delivered to a mailbox or a public folder.
Report delivered
A delivery receipt or an NDR was delivered to a mailbox.
StartAssocByMTSUser
23
ReleaseAssocByMTSUse
28
Message redirected
The message was sent to mailboxes other than the mailboxes of the recipients.
29
Message rerouted
The message was routed to an alternative path.
31
Downgrading
An X.400 message was downgraded to 1984 format before relay.
33
Report absorption
The number of delivery receipts or of NDRs exceeded a threshold and the reports were deleted.
34
Report generation
A delivery receipt or an NDR was created.
43
Unroutable report discarded
A delivery receipt or an NDR could not be routed and was deleted from the queue.
50
Gateway deleted message
The administrator deleted an X.400 message that was queued for a gateway.
51
Gateway deleted probe
The administrator deleted an X.400 probe that was queued for a gateway.
52
Gateway deleted report
The administrator deleted an X.400 report that was queued for a gateway.
1000
Local delivery
The sender and the recipient are on the same server.
1001
Backbone transfer in
Mail was received from another MAPI system across a connector or across a gateway.
1002
Backbone transfer out
Mail was sent to another MAPI system across a connector or across a gateway.
1003
Gateway transfer out
The message was sent through a gateway.
1004
Gateway transfer in
The message was received from a gateway.
1005
Gateway report transfer in
A delivery receipt or an NDR was received from a gateway.
1006
Gateway report transfer out
A delivery receipt or an NDR was sent through a gateway.
1007
Gateway report generation
A gateway generated an NDR for a message.
1010
SMTP queued outbound
Outgoing mail was queued for delivery by the Internet Mail Service.
1011
SMTP transferred outbound
Outgoing mail was transferred to an Internet recipient.
1012
SMTP received inbound
Incoming mail was received from by the Internet Mail Service.
1013
SMTP transferred
Incoming mail that was received by the Internet Mail Service was transferred to the information store.
1014
SMTP message rerouted
An Internet message is being rerouted or forwarded to the correct location.
1015
SMTP report transferred In
A delivery receipt or an NDR was received by the Internet Mail Service
1016
SMTP report transferred out
A delivery receipt or an NDR was sent to the Internet Mail Service.
1017
SMTP report generated
1018
SMTP report absorbed
The receipt or the NDR could not be delivered and was absorbed. (You cannot send an NDR for an NDR.)
1019
SMTP submit message to AQ
A new message is submitted to Advanced Queuing.
1020
SMTP begin outbound transfer
A message is about to be sent over the wire by SMTP.
1021
SMTP bad mail
The message was transferred to the Badmail folder.
1022
SMTP AQ failure
A fatal Advanced Queuing error occurred. Information about the failure was written to the Event Manager.
1023
SMTP local delivery
A message was successfully delivered by a store drive (logged by Advanced Queue).
1024
SMTP submit message to cat
Advanced Queuing submitted a message to the categorizer.
1025
SMTP begin submit message
A new message was submitted to Advanced Queuing.
1026
SMTP AQ failed message
Advanced Queuing could not process the message. The message caused an NDR to be sent, or the message was put in the Badmail folder.
1027
SMTP submit message to SD
A message was submitted to the store driver by the MTA.
1028
SMTP SD local delivery
The store driver successfully delivered a message (logged by store driver).
1029
SMTP SD gateway delivery
The store driver transferred the message to the MTA.
1030
SMTP NDR all
All recipients were sent an NDR.
1031
SMTP end outbound transfer
The outgoing message was successfully transferred.
1032
SMTP message scheduled to retry categorization
1033
SMTP message categorized and queued for routing
1034
SMTP message routed and queued for remote delivery
1035
SMTP message scheduled to retry routing
1036
SMTP message queued for local delivery
1037
SMTP message scheduled to retry local delivery
1038
SMTP message routed and queued for gateway delivery
1039
SMTP message deleted by Intelligent Message Filtering
1040
SMTP message rejected by Intelligent Message Filtering
1041
SMTP message archived by Intelligent Message Filtering
1042
Message redirected to the alternate recipient
Appendix II
Fields that are marked with an asterisk (*) are never blank.
date-time*
The date and time of the message tracking event. The value is formatted as yyyy-mm-ddhh:mm:ss.fffZ, where yyyy = year, mm = month, dd = day, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z signifies Zulu, which is another way to denote UTC.
The TCP/IP address of the messaging server or messaging client that submitted the message.
The name of the messaging server or messaging client that submitted the message.
The TCP/IP address of the source or destination server running Microsoft Exchange Server.
The name of the destination server.
Extra information associated with the source field.
The name of source or destination Send connector or Receive connector.
source*
The Exchange transport component responsible for the message tracking event. The possible values for this field are as follows:
· ADMIN (for Replay directory submission)
· AGENT
· DSN
· GATEWAY (for Foreign connector submission)
· PICKUP
· ROUTING
· SMTP
· STOREDRIVER
event-id*
The message event type. These events are described fully in the table earlier in this topic. The possible values are BADMAIL, DELIVER, DSN, EXPAND, FAIL, POISONMESSAGE, RECEIVE, REDIRECT, RESOLVE, SEND, SUBMIT, and TRANSFER.
internal-message-id*
A message identifier that is assigned by the Exchange Server 2007 server that is currently processing the message. A specific message's value of internal-message-id is different in the message tracking log of every Exchange Server 2007 server that is involved in the delivery of the message.
The value of the Message-Id: field found in the message's header fields. If the Message-Id: header field does not exist or is blank, an arbitrary value is assigned. This value is constant for the lifetime of the message.
recipient-address*
A message was submitted by a server running Exchange Server 2007 computer that has the Mailbox server role installed to an Exchange 2007 computer that has the Hub Transport server role or Edge Transport server role installed.
The e-mail addresses of the message's recipients. Multiple e-mail addresses are separated by the semicolon character (;).
total-bytes*
The number of recipients in the message.
recipient-count*
This field is used with EXPAND, REDIRECT, and RESOLVE events to display other recipient e-mail addresses associated with the message.
This field contains additional information for specific types of events:
· DSN - The Reference field contains the Internet-Message-Id of the message that caused the DSN.
· SEND - The Reference field contains the Internet-Message-Id of any delivery status notification (DSN) messages.
· TRANSFER - The Reference field contains the Internal-Message-Id of the message that is being forked.
For all other types of events, the Reference field is blank.
The message's subject found in the Subject: header field. The tracking of message subjects is controlled by the MessageTrackingLogSubjectLoggingEnabled parameter in the Set-TransportServer cmdlet for Hub Transport servers and Edge Transport servers, or in the Set-MailboxServer cmdlet for Mailbox servers. By default, message subject tracking is enabled. Message subject logging can be disabled by setting the value of the MessageTrackingLogSubjectLoggingEnabled parameter to $false.
The e-mail address specified in the Sender: header field, or the From: header field if Sender: is not present.
return-path*
The return e-mail address specified by MAIL FROM: in the message envelope. Although this field is never empty, it can have the null sender address value represented as <>.
This field contains the message origination date-time for DELIVER and SEND events. The origination date-time is the time that the message first enters the Exchange organization. The value is formatted as yyyy-mm-ddhh:mm:ss.fffZ, where yyyy = year, mm = month, dd = day, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z signifies Zulu, which is another way to denote UTC.
Table: Event Types Used to Classify Each Message Event
These are the Event-ID field above
Event name
BADMAIL
A message was submitted by the Pickup directory or the Replay directory that cannot be delivered or returned.
DELIVER
A message was delivered to a mailbox.
DSN
A delivery status notification (DSN) was generated.
EXPAND
A distribution group was expanded.
FAIL
A message delivery failed.
POISONMESSAGE
A message is put in the poison message queue or removed from the poison message queue.
SUSPEND
Indicates that replication has been halted for the passive copy. This state prevents the database from advancing, and logs from being copied. Possible values are True and False.
A message was received and committed to the database.
REDIRECT
A message was redirected to an alternative recipient after an Active Directory directory service lookup.
RESOLVE
A message's recipients were resolved to a different e-mail address after an Active Directory lookup.
SEND
A message was sent by Simple Mail Transfer Protocol (SMTP) to a different server.
SUBMIT
A message was submitted by an Exchange Server 2007 computer that has the Mailbox server role installed to an Exchange Server 2007 computer that has the Hub Transport server role or Edge Transport server role installed.
TRANSFER
Recipients were moved to a forked message because of content conversion, message recipient limits, or agents.
Comparing the field names that are used in the message tracking log and the field names that are used by the Get-MessageTrackingLog cmdlet
Field name that is used in the message tracking log
Field name that is used to filter the Get-MessageTrackingLog results
Appendix III
Search filters that are available by using the Get-MessageTrackingLog cmdlet
Search filter
Corresponding field in the message tracking log
End
ResultSize
None. This parameter limits the number of results that are displayed by the search.
Start
I recently was working with a customer in their process to convert their legacy Address Lists from LDAP (used by Exchange 2003) to OPATH (required by Exchange 2007/2010) and ran into an interesting find.
After using the LDAP to OPATH conversion script by Bill Long to generate and review the list, we started updating the Address List filters. The first few went fine...the converted fiter was tested, set, and then verified. The verification was to check that the RecipientFilter returned from the Get-AddressList command matched what we had entered via Set-AddressList. All was going fine, until about five Address Lists into our list when we noticied that the OPATH filter we entered had been changed...there were a TON more parenthesis in the filter than we had used!!!
Filter entered:
((Alias -ne $null) -and (customAttribute1 -eq "Contoso") -and (customAttribute2 -eq "Corporate") -and (((ObjectCategory -like "person") -and (ObjectClass -eq "user") -and -not (Database -ne $null) -and -not (ServerLegacyDN -ne $null)) -or ((ObjectCategory -like "person") -and (ObjectClass -eq "user") -and (recipientType -eq "UserMailbox")) -or ((ObjectCategory -like "person") -and (ObjectClass -eq "contact")) -or (ObjectCategory -like "group") -or (ObjectCategory -like "publicFolder") -or (ObjectCategory -like "msExchDynamicDistributionList")))
Filter returned:
((((((Alias -ne $null) -and (CustomAttribute1 -eq "Contoso"))) -and (CustomAttribute2-eq "Corporate"))) -and (((((((((((((((((ObjectCategory -like "person") -and (ObjectClass -eq "user"))) -and (-not(Database -ne $null)))) -and (-not(ServerLegacyDN -ne $null)))) -or (((((ObjectCategory -like "person") -and (ObjectClass -eq "user"))) -and (RecipientType -eq "UserMailbox"))))) -or (((ObjectCategory -like "person") -and (ObjectClass -eq "contact"))))) -or (ObjectCategory -like "group"))) -or (ObjectCategory -like "publicFolder"))) -or (ObjectCategory -like "msExchDynamicDistributionList"))))
NOTICE THE DIFFERENCE IN THE NUMBER OF PARENTHESIS!!!
The resulting filter worked fine, returning the same results as the originally specified filter, but we wondered if we had run into a bug...it seemed like all those extra parenthesis were NOT needed and might even make the filter inefficient!
After doing some research and going through TechNet articles and our bug database, it turns out this conversion is by design. The issue is that we had MULTIPLE conditions all being evaluated together:
( (Condition1) -and (Condition2) -and (Condition3) )
When the above gets parsed by PowerShell, the resulting filter will be changed and become:
( ( ( Condition1 ) -and ( Condition2) ) -and ( Condition3 ) ) )
This way when evaluated, only 2 conditions are checked at a time. In this case, it validates that Condition1 and Condition2 are both true. Then it moves on and checks that the result of that test and Condition3 are true.
Again, this is NOT a bug but BY DESIGN. It just looks wrong (especially if you have several items like this) as though something just decided to add a bunch of parenthesis for no good reason.