|
|
Friday, July 14, 2006 3:22 PM
If you are writing an SMTP agent, you might find it instructive to learn to speak SMTP yourself, both to aid debugging and to get a feel for what is happening "under the hood" when Exchange receives a message from the internet. This is a lot easier than it might sound. Open the Run dialog box (press Window + R) and enter "telnet localhost smtp" (or substitute the name of your Gateway server in place of localhost). This will open a window where you can talk with the server. The server will begin the conversation by sending a banner, such as:
220 mail.contoso.com ready at Thu, 23 Feb 2006 17:46:23 -0800
You may continue the conversation by entering the following commands, one line at a time. Note that there is a blank line in the middle - it's important. Just press enter to send the blank line:
ehlo console
mail from: sender@contoso.com
rcpt to: recipient@contoso.com
data
To: recipient@contoso.com
From: sender@contoso.com
Subject: Test Message
This a test message.
.
quit
The server will respond with a simple text message after the first three commands. After the "data" command, the server will just listen patiently until you enter the "." on a line by itself. When you initially connect to the server, your agent will be created and the OnConnect event will be fired. Additional events are fired are follows:
ehlo console
This fires OnEhloCommand
mail from: sender@contoso.com
This fires OnMailCommand
rcpt to: recipient@contoso.com
This fires an OnRcptCommand. You can repeat this command as many times as you want, specifying a different email address each time.
data
This fires OnDataCommand. The next three lines are not SMTP commands, they are the headers of the message that you are sending.
To: recipient@contoso.com
From: sender@contoso.com
Subject: Test Message
(blank line)
The blank line is important, it separates the headers from the content of the message. When the blank line is received, OnEndOfHeaders fires.
This a test message.
.
The "." on a line by itself indicates the end of the message, and this is when OnEndOfData fires.
quit
This is the polite way to end the conversation. OnDisconnect will fire at this point, but it will also fire if you end the connection impolitely (for example by closing the window).
You can also copy/paste the whole batch of commands - I put them in a text file so I can replay an entire SMTP conversation quickly using only notepad and telnet. This can be really handy for testing.
- Nate Waddoups
Wednesday, July 12, 2006 12:38 PM
What do Microsoft Support Engineers look for in the results of the MPS Reports diagnostic tool?
The Microsoft Product Support Report (aka MPS Reports) is arguably the most used diagnostic gathering tool used by Support Engineers to diagnose and correct server and environmental technical issues. The MPS Reports are meant to be used only by Microsoft personnel (according to the End User Licensing Agreement), but I can discuss with you what we look for in them. The tool runs as a series of batch file commands in a command window. Most support teams have their own version of the tool that can be downloaded here. The Microsoft Knowledge Base Article that discussed it is found here. This discussion with be limited to the Exchange specific version. One important thing to note is that the tool makes no changes to the server other than the addition of the diagnostic, and related files themselves. Ideally, it should be run under an account with Exchange Full Admin and domain Admin privileges to gather the maximum amount of data.
The first thing I look at is the Application and System Event logs (Servername_Application.evt and Servername_System.evt respectively). I use an internal log parser and filtering tool, but there are public tools available that overcome the limitations of the one included in the operating system. A parser tool will allow sorting, excluding, and searching of events not otherwise easily done with the native Event Viewer. The event logs often are the indicators of the nature of a technical problem. They will often tell a story of what occurred during a particular failure. It's advantageous to view them both and compare timelines. For example a failure of Exchange to read or write from storage device as recorded in the application event log will often correlate with the report in the system log of a disk channel hardware problem. The text version of the application and system event logs are included (Servername_Application.txt and Servername_System.txt respectively), so in the event of mismatched DLL files between the source and the viewing computers, I can use them to parse the actual error by searching on a known part of the event using Microsoft Excel or a text editor.
Included with the MPS Report is an XML output file for the Exchange Best Practices Analyzer Tool (Servername_EXCH_exBPA.XML). This tool is invaluable in detecting and offering remedies for many Exchange technical issues. The stand-alone version can be found on http://www.microsoft.com/exchange/analyzers. The version included in the MPS Report is slightly behind the latest, so I'll make sure I'm download the current one from the ExBPA site above. While there, also check out the Exchange Server Performance Troubleshooting analyzer Tool and the Exchange Server Disaster Recovery Analyzer tool. All of the analyzer tools are meant to be run by you, the administrator, for the purpose of diagnosing and providing recommendations so that you may not have to incur a costly and time consuming call Microsoft Support at all. The Exchange Best Practices Analyzer file will not be included if the MPS Report was run on a server that does not have the .Net Framework 1.1 or later installed. It's installed by default on Windows 2003 servers, but not on Windows 2000 Servers. The latest version of .Net Framework can be downloaded via Windows Update.
Exchange depends heavily upon Active Directory and consequentially the Domain Naming Servers' health. If technical issues are present in DNS or the Active Directory, Exchange will often exhibit failures as well. (It's an inside joke that Exchange is the best diagnostic tool.) There are a couple of tools included that will help diagnose those failures. The first is Netdiag. The output of this tool is included in the MPS Report and is named Netdiag.log. This is the same version of Netdiag included with the Windows 200x Support Tools. If Netdiag is run outside of the MPS Report, it produces a netdiag.log in the same directory from which its run. With the netdiag.log file open, I search for the word "fail". Some of the failures are not consequential, such as the IPX, Kerberos (due to a bug in Netdiag) and Retries (although Retries can sometimes be helpful in diagnosing that there is a network problem. Red flags go up if there are failures with locating domain controllers, LDAP or DNS sections of the test. I tell my customers that it's critical to repair any DNS or Active Directory problems before further diagnosing Exchange, as often the remediation of those problem will alleviate the Exchange ones. DCDiag is another sometimes useful tool that generates the Servername_dcdiag file, but only if the Exchange server itself is a domain controller. In most environments, installing Exchange on a Domain Controller is not recommended. See Michael's Blog for more information. The output is included in the MPS Report cab file. It too is the same version included in the Windows 200x Support Tools. If run from the Support tools, it doesn't create a log file by default and must therefore be piped to a text file. When used in the MPS Reports, however, the text file is generated automatically.
Permissions problems often occur in Exchange-related technical issues. For diagnosing those, I use the included Exchdump file (along with the its back end XML file). Upon opening the ExchDumpxxxxx.HTM file, I right click on the warning bar above the main window in Internet Explorer selecting to Allow Blocked Content so the XML file can be accessed, which will contain additional configuration and permissions data when the highlighted portions of the html file are clicked to expand them.
The exact configuration and permission of Exchange related Active Directory objects can be determined with this tool. There is a section called Objects Flagged for Further Investigation. It is common to find some NTDS connectors in the Lost and Found Config Container, for example. They can usually be ignored. Other objects contained in this section I'll want to investigate as they may be duplicates or the results of Active Directory collisions. In some cases deleting objects in the Lost and Found Config Container can alleviate the Exchange related technical issue.
Here is an example of the "Objects flagged for further investigation" section of the report:
Objects flagged for further investigation
-Objects under msExchConfigurationContainer with ACL inheritance disabled: No objects found -Explicit Deny (Everyone group) exists on object msExchOrganizationContainer: CN=Orgname (LDAP://CN=Orgname,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=ad,DC=domain,DC=com) Class: msExchOrganizationContainer Schema: LDAP://schema/msExchOrganizationContainer cn : "Orgname" legacyExchangeDN : "/o=ABC" whenChanged : Wednesday, 04/21/2006 22:14:40 (GMT) ->Click for more details...
->Click for Permissions on object...
-The LostAndFoundConfig container contains the following objects: CN=NTDS Settings (LDAP://CN=NTDS Settings,CN=LostAndFoundConfig,CN=Configuration,DC=ad,DC=domain,DC=com) Child of CN=LostAndFoundConfig Class: nTDSDSA Schema: LDAP://schema/nTDSDSA cn : "NTDS Settings"
->Click for more details...
The Lost and Found Config Container can be viewed with ADSIEdit (also from the Windows 200x Support Tools in the path:
CN=LostAndFoundConfig,CN=Configuration,DC=domainname,DC=com.
It is not recommended to disable permissions inheritance on Exchange objects it unless there is a compelling reason. Disabling inheritance should be done with caution as it can cause problems with the Exchange environment. If I find inheritance disabled on an object I can then check that object with ADSIEdit for the disabling of the inherited permissions (Properties\Security\Advanced).
Two other useful files are the Windows Info (Servername_._Summary.txt) and Exchange Info (Servername_Exch_Info.txt) files. From the Windows info file I can get the Windows build number, the drive location of the operating system and other useful data. The Exchange info file gives me a listing of all the Exchange databases, transaction log locations and other Exchange related drives and paths, as well as the build numbers for Exchange. If the server is a server cluster, information on each Exchange cluster resource will also be included.
The cab file includes the MSINFO file (Servername_MSINFO32.NFO. It's the same output generated if Start > Run > MSINFO32 (Windows 200x version) or WINMSD (NT version) is typed. When I double-click on it, I can get complete hardware, software and application data. The places I usually look at are the Services list and the Loaded Modules list. Between these two listings, I can find detailed information on what's running on the server, whether it's service is started, and the manufacturer of the loaded module. If I see something suspicious, I can follow up with a search on http://support.microsoft.com, or a search on the Internet. A text version is also included, (Servername_winmsd.txt). I can also get more information on processes and device drivers from the Process listing file (Servername_Process.CSV/TXT and Servername_DRIVERS.CSV/TXT). Some performance information for running processes is included in the Servername_PSTAT.TXT file.
Every installation of Exchange or Exchange System Manager creates a file on the root of the c: drive called the Exchange Server Setup Progress.log (called Servername_Exchange Server Setup Progress.log by MPS reports). This file gives a history of installations and updates on the server. There are typically a lot of errors listed in it that are inconsequential, but sometimes I can tell if something went wrong during an install or update that would affect the current operation of my customer's Exchange server. For instance, sometimes a real time anti-virus file scanner prevents some DLLs loading from an update. I should be able to catch that here. I tell my customer's that if possible, shut off anti-virus scanning while installing updates and patches. If the Exchange server is part of a server cluster, updates and patches should be loaded only on the passive nodes. See Microsoft Knowledge Base Article KB328839 for more information.
DR Watson is the module that generates a log file whenever an application faults. Its log file is included here. Once opened in notepad, I ctrl-end to get the cursor to the end of the document and then search up for "exception occurred" (without the quotes) to find the last application exception that occurred. For example, in the Dr. Watson log from my desktop, the last exception was incurred by Network Monitor:
Application exception occurred:
App: C:\WINDOWS\System32\NetmonFull\netmon.exe (pid=5980)
When: 5/27/2006 @ 16:48:09.923
Exception number: c0000005 (access violation)
Outside of MPS Reports, one can locate the Dr. Watson files by running "drwtsn32" from the Run menu.
Servername_BOOT_INI.TXT lists the contents of the boot.ini file. Here it can be confirmed if the /3GB and/or /USERVA=xxxx switches are in place on that file. If they're not, there would have been a warning in both the event log and the Exchange Best Practices Analyzer reports. See Microsoft Knowledge Base Article KB810371 for more information.
Also included and often useful are the cluster log from the node (Servername_CLUSTER.LOG), the cluster registry hive (Servername_CLUSTER_REGISTRY.HIV), the Exchange registry hive (Servername_EXCH_REG.TXT), DSaccess information (Servername_EXCH_dsaccess.TXT), a complete list of installed hotfixes (Servername_HOTFIX.TXT), SMTP bindings (Servername_EXCH_smtpreg.TXT), application setup logs created by the Microsoft Installer (Servername_SETUPACT.LOG, Servername_SETUPAPI.LOG and Servername_SETUPERR.LOG), network information files (Servername_NETINFO.TXT and Servername_MISC.TXT), the Metabase (IIS Configuration database) output to a text file (Servername_Metabase.TXT and Servername_Metabase.xml), IIS information files and registry hives (Servername_IISREG.TXT) and .Net Framework information (Servername_.NETFramework.TXT/CSV).
More files are included (too many to list), but this blog post was meant to touch upon the most often used ones. When working with a customer, I like to be sure to let them know why I'm asking them to perform a particular action. Hopefully this blog post will help toward that goal.
Credits:
Thanks to Dedicated Support Engineer Paul Flaherty for supplying extensive information on the MPS Reports for Exchange and Nino Bilic for the technical review of this document.
- Paul Miner
Thursday, July 06, 2006 10:00 AM
Introduction
I regularly meet with customers and discuss their Exchange Server architecture. Two topics frequently come up so I thought I'd discuss them with everybody and give my perspective on them.
Many customers tell me that they do not impose mailbox and/or message size limits on the vast majority of their user population. This poses a problem because you will never be able to adequately design a storage subsystem or maintain the desired database size limits, let alone meet any service level agreements that may be in place.
Additionally, most of these customers do not have defined, measurable, and actionable Service Level Agreements (SLAs) or Operating Level Agreements (OLAs) in place to manage user expectations (i.e. messaging as a service), and thus cannot measure a real cost/benefit with regards to the user population demands. Ultimately, the lack of mailbox size limits and message size limits can lead to instability in the messaging architecture.
Oh, and I consider an outrageously large limit (to quiet the restless natives) the same as the lack of mailbox and message size limits.
Mailbox Limits
The following areas or issues may occur in your environment if you do not have a proper quota management policy in place:
- Denial of Service Attacks - Without a message and mailbox size limits, a hacker (whether internal or external) can easily implement a denial of service attack by sending messages with large attachments, ultimately using all available resources on the Exchange servers, thereby causing system failure. Implementing message size limits (both internal and external) can reduce the likelihood of this risk.
- Capacity Planning - The lack of quota management effectively limits any type of future capacity planning (e.g. cannot predict future database growth). In particular, if you have an SLA that dictates a backup/restore window you may not be able to meet that goal, due to not being able to control the database size metric.
- Network Utilization - Since the users will have unlimited mailbox sizes, network utilization will increase between client and server if users utilize OSTs or cached mode Outlook clients.
- Single Instance Storage - Single Instance Storage ratios may continue to decrease if reactionary measures are used to combat the lack of quotas (e.g. continually moving mailboxes around the enterprise to head off low disk space, SLA attainment, etc).
- Cost Impact - Due to the growth that will likely ensue without a proper quota management implementation, organizations will find that the cost per mailbox will and continue to increase over time. In addition, most likely additional costs will accrue due to poor management of the solution, in terms of not having proper SLA/OLAs, moving mailboxes to head off capacity disasters, and overloading servers from a performance and capacity standpoint (due to the aforementioned mailbox moves).
- Performance Impact - A lack of quota management will mean that eventually the storage subsystem will not be able to sustain the I/O throughput required. As you increase the mailbox sizes, the number of items will increase and for most users this will mean an increase in the number of items in the key folders (Inbox, Sent Items, Calendar, etc); as the number of items increase, the I/O throughput per mailbox will increase (http://support.microsoft.com/?id=905803). In addition, since the amount of data increases, users may deploy desktop search programs, and when running in online mode, these search programs utilize Exchange server resources (http://support.microsoft.com/?id=905184).
Also remember that mailbox quotas are only part of the solution:
- Users should realize that a mailbox is not a file storage area; the users will require some training on email etiquette that is appropriate in their business. For more information on email etiquette rules, please review http://office.microsoft.com/en-us/FX012055341033.aspx.
- Organizations could provide alternate solutions like SharePoint Portal Servers and Windows SharePoint Services where users can save documents and can collaborate around them by sending links via email as opposed to attaching the documents.
- Archiving solutions can help, but only with proper planning and design. Also, please note that most archival solutions replace the archived content with a stub reference. The stub references still have an impact on the messaging view creation process and affect the performance and scalability of the solution.
To resolve the lack of mailbox size quota management in the short-term, organizations should:
- Identify an appropriate message size limit.
- Identify appropriate size limits; include warning, prohibit send, and prohibit send/receive.
- Identify key personnel that require additional storage capacity, above and beyond the limits defined from above. Create separate SLA/OLAs for these sets of users.
To resolve the lack of mailbox size quota management in the long-term, organizations should:
- Implement defined Service Level Agreements and Operating Level Agreements that measure the messaging solution as a service; e.g. Gold, Silver, Bronze; 99.99% availability, etc that are actionable and measurable.
- Gain support from the business for the budget and resources to support the defined SLA/OLAs.
- Implement the message size limit.
- Implement the mailbox size limit using mailbox database policies.
- Move key personnel onto a dedicated database store and use a separate mailbox database policy to control mailbox size.
Message Size Limits
Microsoft has a best practice of a 10MB limit. Exchange Server 2003 by default sets the global message size limit to 10MB. The Exchange Product Group implemented this code change due to customer feedback and to help protect against denial of service attacks.
Issues that can arise from a lack of internal message size quota policy:
- Denial of Service Attacks - Without or with improper message size limits, a hacker (whether internal or external) can easily implement a denial of service attack by sending messages with large attachments, ultimately using all available resources on the Exchange servers, thereby causing system failure.
- Capacity Planning - Improper quota management effectively limits any type of future capacity planning (e.g. cannot predict future database growth).
- Backup/Restore Windows - Improper quota management will ultimately impact backup restore windows. As the database sizes grow, the backup window will increase. At some point this backup window will interfere with business hours. The same is true for the restore window.
- Virus Scanning - Improper quota management will incur performance penalties on virus scanning of the messages.
- Anti-Spam Measures - Many anti-spam products won't scan the message if they are over a certain size.
- Network Utilization - Network utilization will increase as messages are sent between Exchange servers and between the Exchange organization and the Surf Control relay devices.
To resolve the lack of message size quota management in the short-term, organizations should:
- Organizations should monitor and study the contribution of impact related to such large size limits.
- Organizations should consider alternate products for attachments, so that the overall message size limit can be reduced. For example, Windows SharePoint Services integrates with Office 2003, thereby allowing attachments to be stored on web sites.
- Do not implement message size limits on SMTP Virtual Servers as that will also impact public folder replication. Message Size Limits should only be implemented globally, on connectors, or on the mail-enabled object (http://support.microsoft.com/?id=322679).
To resolve the lack of mailbox size quota management in the long-term, organizations should:
- Organizations should implement another mechanism for file transmission and storage.
- Organizations should reduce the overall message size limit.
- Define SLA/OLA's and gain support from the business for the budget and resources to meet user demands.
- Monitor and measure performance to the defined SLA/OLA's.
The Future
Many of you may say "That's great Ross, but the technology doesn't support us. The users need their data and we can't allow them to delete it because we'll have to restore more, or we can't allow them to go to PST, etc".
Yes I know, with today's technologies it is hard to implement a solution, but it is doable. For example, Microsoft IT implements a strict message and mailbox size limit policy, as well as defined measurable SLA/OLAs for the messaging service. For more information, visit IT Showcase at http://www.microsoft.com/itshowcase.
But beyond Outlook 2003's capabilities of restricting PST access (you do know you can do that, right?), Exchange 2003 doesn't provide any mechanism (beyond the limited Mailbox Manager Policies) to implement life cycle management or long-term archival (our third-party partners help in this area - http://www.microsoft.com/exchange/partners/2003/backup.asp).
But fear not, we are making great strides in Exchange 2007 and Outlook 2007 around email life cycle management (in Exchange 2007 it is known as message record management). In addition, our move to 64-bit, allowed us to make changes to the product to reduce the IOPS/mailbox requirements (see http://msexchangeteam.com/archive/2006/04/07/424645.aspx for more information).
I encourage you all to review the Exchange 2007 Beta 2 demos on Compliance to learn more about what's coming - http://msexchangeteam.com/archive/2006/06/20/428030.aspx.
With these features, I truly expect customers to finally be able to get a handle on the data that exists within their message stores and to finally be able to implement valid message and mailbox size limits.
- Ross Smith IV
Wednesday, July 05, 2006 10:00 AM
In addition to the Mobile Messaging paper that we blogged about, there are two more Messaging related IT Showcase papers available that we did not mention yet:
Messaging Hygiene at Microsoft: How Microsoft IT Defends Against Spam, Viruses, and E-Mail Attacks:
http://www.microsoft.com/technet/itsolutions/msit/security/messaginghygienewp.mspx
"At the time of this writing, the average volume of messages submitted from the Internet to Microsoft IT e-mail gateways ranges between 10 million and 12 million a day. The multilayered approach to e-mail filtering means that multiple mechanisms analyze incoming e-mail, and each of these mechanisms subsequently reduces the amount of spam permitted to pass. The following filtering stages illustrate the effectiveness of e-mail filtering layers in Microsoft IT as of this writing. The percentages are based on average daily volumes. Connection filtering blocks approximately 80 percent of all incoming SMTP messages. These connections come from known spam sources listed in third-party, real-time block lists. Sender and recipient filtering deletes 70 percent of the messages received after connection filtering. After connection filtering, sender filtering and recipient filtering remove almost 95 percent of messages as spam. Intelligent Message Filter rejects 6 percent of the remaining incoming messages as spam."
"Managing this messaging infrastructure is a formidable task. For approximately 92,000 employees, the infrastructure supports 116,000 mailboxes, each with at-least a 200-megabyte (MB) storage limit. Global e-mail flow totals, on average, more than 12 million messages per day; 3 million of those are internal e-mail messages. Each day, approximately 95 percent of incoming e-mail from the Internet is filtered out as spam, virus-infected e-mail, or e-mail addressed to invalid addresses."
Managing Exchange Messaging Services by Using Metrics:
http://www.microsoft.com/technet/itsolutions/msit/deploy/manageexms.mspx
"The Exchange messaging infrastructure at Microsoft is a large messaging environment that consists of:
- 116 servers running Exchange Server 2003 (including passive clustered nodes), of which 63 of the 69 mailbox servers are in clustered configurations running Windows Server 2003.
- Four Exchange sites in regional data centers worldwide.
- Messaging services for approximately 102,000 users.
- More than 118,000 total mailboxes (including system mailboxes).
- 200-megabyte (MB) storage limit for each mailbox.
- More than 10 million messages globally per day. (Approximately 3 million are internal e-mail messages.)
- 20,096 Smartphone devices that access Exchange.
- 5,145 mobile devices running Windows Mobile version 5.0 that access Exchange.
- 2,279 devices not running Windows Mobile but using an Outlook Mobile Access connection.
- 60,482 users connecting to Exchange by Outlook Web Access 2003.
- Approximately 60,000 users connecting to Exchange by remote procedure call (RPC) over Hypertext Transfer Protocol (HTTP) and Outlook 2003."
"In the past, Microsoft IT monitored and managed the Exchange messaging infrastructure at Microsoft as a stand-alone technology, rather than as a service that relies on many other technologies and operational groups. In other words, Microsoft IT monitored and managed individual servers or services running on servers. For example, Microsoft IT measured Exchange availability from solely an operating system basis of how long the Exchange back-end servers were running. This practice provided an incomplete view of actual service availability because users may not be able to access the Exchange servers because of other infrastructure outages or performance-related problems.
Today, Microsoft IT monitors and manages the Exchange messaging infrastructure as an end-to-end business service, based on actual measurements from client computers, a more comprehensive server application availability, message latency measurements, and customer satisfaction surveys. In addition to providing accurate information about performance, this factual, realistic perspective on Exchange messaging services provides IT managers and decision makers with the necessary information to manage the Exchange messaging infrastructure. The shift in management methodologies also enabled Microsoft IT to improve user satisfaction and increase employee productivity."
Hope you find them useful!
- The Exchange Team
Monday, July 03, 2006 11:00 AM
Previous versions of OWA didn't let you look at mail headers. In Exchange 2007, you can. Open a message in OWA by double-clicking on it or hitting Enter, then click on the "Message Details" icon.
The message details will come up in a nice dialog:
That should be quite popular!
- Rahul Dhar
Friday, June 30, 2006 7:21 PM
Today we present to you Karim Batthish, a Program Manager Lead on Exchange team. Karim talks about Exchange Server 2007 Web services and programmibility. Enjoy!
- The Exchange Team
Thursday, June 29, 2006 7:30 PM
In yet another installment of our TechEd 2006 interviews, Becky Benfield, Program Manager Lead of Exchange mailbox team, discusses high availability and disaster recovery features in Exchange 2007. Check out the video here:
- The Exchange Team
Thursday, June 29, 2006 1:34 PM
With Exchange Management Shell available in Exchange Server 2007, you can now do almost every single admin task with an interactive command line (in addition to the traditional GUI) - you can use it to quickly check settings, create reports, check the health of your system or best of all: automate all of your frequent operations. But don't be fooled by that word "automation", things are even simpler than they seem. As it turns out, most common admin tasks can be done via just a single line in the shell. As proof, the Exchange Management Shell team has put up a series of one-liners here:
http://www.microsoft.com/technet/scriptcenter/scripts/message/exch2007/default.mspx.
If you're new to Exchange Management Shell, take a look at these samples:
- Organization Settings
- Outlook Web Access, ActivSync and RPC/HTTP Management
- Recipient Management
- Storage Group, Mailbox Database and Public Folder Management
Once you get the hang of it, try writing one of your own and submit them to the Exchange Server 2007 Scripting Contest to win a trip to the Exchange launch! Details here:
http://www.microsoft.com/technet/scriptcenter/topics/exchange/contest/default.mspx
- The Exchange Team
Thursday, June 29, 2006 1:09 PM
I just noticed that Scott Schnoll posted this on his blog!
This preliminary release of the Exchange 2007 SDK Documentation and Samples provides new and updated documentation and samples for building applications that use Exchange Server 2007 Beta 2. Use the Exchange 2007 SDK Beta 2 to help you develop collaborative enterprise applications with Exchange.
Get it now at http://www.microsoft.com/downloads/details.aspx?FamilyID=8c32d5ee-a071-459e-843d-8ede0a9582b3&DisplayLang=en.
- Nino Bilic
Wednesday, June 28, 2006 5:00 PM
If you want to learn about Exchange Server 2007 enhancements in mobility area, check out this (close to 15 minutes long!) talk with Max Ciccotosto, Program Manager Lead responsible for mobility in Exchange 2007. You can access the video here:
- The Exchange Team
Wednesday, June 28, 2006 1:32 PM
Hi, this is Kevin Allison, and I lead the User Education group within the Microsoft Exchange product organization. I am pleased to announce that the beta documentation for Exchange 2007 has just been posted to the Microsoft Exchange Server TechCenter! http://www.microsoft.com/technet/prodtechnol/exchange/E2k7Help
As Microsoft prepares to release Exchange 2007 Beta 2 for your testing, you may now begin reviewing the beta of the documentation set. You may notice a significant number of changes from our Exchange 2003 docs. This is a direct result of work done based upon your feedback. My goal is to make the documentation and other Exchange-related content as useful as possible to help you be successful with Exchange. As with other content we publish to the Exchange TechCenter, you can readily rate and comment on specific portions of the documentation. We will be publishing updates to the content through release - usually about every six weeks - and beyond.
Going forward we will provide regular updates on the changes we are making to improve the Exchange content story. Please take a look at the beta docs and let us know what you think.
- Kevin Allison
Tuesday, June 27, 2006 1:14 PM
Over last few months, we had multiple questions on how to start an Exchange user group. Glad to see this much interest! So here's the scoop.
The Exchange team has been working with Culminis (an association that supports user groups) to provide resources regarding Exchange for anyone who wishes to start a user group. If you're considering leading or already leading a user group on Exchange, take a look at the Culminis Exchange Support Network and sign up for product group centric resources.
Yup, this process is the same for groups in countries other than US too, so don't be shy!
- The Exchange Team
Monday, June 26, 2006 6:11 PM
When talking about Exchange Server 2007 Unified Messaging (UM), we often get a question: "Just how big will those messages be?"
The size of UM voice messages depends on the size of the attachment that holds the voice data. In turn, the size of the attachment depends on three factors:
(1) the duration of the recording
(2) the audio codec used
(3) the audio storage format
UM uses one of three codecs for creating voice messages: WMA (Windows Media Audio), GSM 06.10 and G.711 PCM Linear. The WMA codec is always stored in Windows Media format (the attachment is a file with a .wma extension). Audio encoded as GSM or PCM is always stored in RIFF/WAVE format (the attachment is a file with a .wav extension).
The graph below shows how the size of the audio depends on the duration, for the three codecs used:
PCM is uncompressed, and therefore occupies the most space at a given duration (just over 160,000 bytes for each 10 seconds of audio). It has the highest audio quality of the three. However, WMA and GSM are both acceptable to the vast majority of listeners.
GSM is compressed (just over 16,000 bytes for each 10 seconds).
WMA is the most highly compressed codec (about 11,000 bytes for each 10 seconds). However, the WMA format has a much larger header section than the WAV format (about 7K, compared to less than 100 bytes). WMA recordings become smaller than GSM recordings for durations of about 15 seconds and above. The average call-answered voice message is about 30 seconds long.
WMA is the default setting. GSM or PCM can be used where interoperability with other platforms is of great importance (the WAV format and GSM codec are widely supported).
- Michael Wilson
Monday, June 26, 2006 2:20 PM
Today we give you about 5 minutes of Jesse Dougherty, where he talks about Exchange 2007 Security and Transport. You can get to the video here:
- The Exchange Team
|
|
|