We are happy to announce that Exchange 2010 is Code Complete! Our senior leadership team has signed off on the final code, and it has been sent to our early adopters for one final look before its public release. This Release to Manufacturing (RTM) milestone means we are on our way to general availability and the launch at Tech·Ed Europe 2009 (http://www.microsoft.com/europe/teched/) in early November.
For those of you attending Tech·Ed in Berlin this year, be sure to check out the Unified Communications track, which is packed with technical content on Exchange 2010. And be sure to visit us at the Exchange product booth in the Exhibition Hall and let us know what you think of the product. Crystal Flores, who interviewed some of you on video at Tech·Ed North America earlier this year, will be on-hand in Berlin in a few weeks, armed with a camera and interview questions. A group of us are also marching to Las Vegas for Exchange Connections the same week where our fearless leader Rajesh is giving the keynote.
We hope to see you in Berlin or Vegas, but if you can't join us in person, tune in via the Web (www.thenewefficiency.com) to be part of the launch.
- The Exchange Team
vendredi 23 octobre 2009
jeudi 1 octobre 2009
Service Pack 2 Highlight: Mailbox Access Auditing
In today's installment of "Microsoft Exchange Server 2007 Service Pack 2 Highlight", I bring you a brief overview of how we have made auditing mailbox access easier (in the aforementioned service pack 2 - yes, for Exchange Server 2007).
Auditing access to mailboxes (Who opened what) has always been difficult with Exchange Server. I first made my acquaintance with this code in Exchange 4.0 - and it hasn't changed much - until now. With Service Pack 2 we made a set of changes that will meet the needs of some organizations. Not everyone will be happy with our design decisions. Not everyone will be able to utilize Access Auditing for their needs. Those of you who can use these features, will be pleased to find that Service Pack 2 offers granularity, detail, and clarity for auditing mailbox access.
Decisions, Decisions
To start with, we had to decide what to log. One thing you will notice right away is the thing we decided not to log: Logons. Traditional auditing has involved turning up diagnostic logging on private logons and filtering through a lot of data. The problem with this is that a logon (in and of itself) doesn't really represent anything malicious. If I put Kurt Phillips on the recipient list of a meeting invite with Outlook, you might see my client attempt to logon. Not because I decided to try and read Kurt's mail) but because Outlook wants to check his free/busy. Get out the pitch forks or calmly pass over? It's hard to tell. On the other hand, if I opened user A's inbox - that would be valuable information. So Access Auditing is focused on actual access to data, not mailbox logons.
Success is what counts
We also decided to focus on access success, not failure. If you fail to open an inbox, Access Auditing does not record this. Again, focusing on actual access to actual data.
Location, Location, Location
The biggest change you will notice from Access Auditing is where it places the audit events. It is in essence a set of diagnostic logging categories for the Exchange Information Store. In studying the last five years worth of auditing cases, and every escalation where auditing was used to gather data, we realized that because of the volume of data, customers using private logon diagnostics often had to make a hard choice when confronted with an issue that required diagnostic logging:
1. Have the data necessary to audit access.
2. Have enough room for the other logging to troubleshoot.
Every version of Exchange has used the Application log as its dumping ground since Exchange 4.0. Until now. Exchange 2007, Service Pack 2 creates a new application log: Exchange Auditing. It is not the security log (and we've gotten a bunch of feedback for and against this). It is not the application log. It is the location where Exchange 2007 can output events related to mailbox access (and more.).
So what do we get?
You get a lot of information. All audited events associated with a user logon carry the same sort of information:
Object specific information, information about which NT Account was used, what mailbox was acted upon, and if you are running at least Outlook 2003 SP2, information about the machine the access was made from. You also get a great deal of choice about what is logged. Log only administrators using administrative rights, log only access from one user to another user's mailbox, or log access to any mailbox. The choice is yours to enable the amount of information you need to fit your needs.
Let's look at a sample access event:
Accessing user, mailbox being accessed, windows account, and information about what was accessed. That's not a bad set of data for customers who have to answer who did what and when.
You have the Right to Remain Invisible
One of the most controversial issues will, without a doubt, be the addition of a new extended right. For organizations with trusted service accounts (such as voice mail, brick backup, or device software) these applications generate anywhere from two to eight times as many events as a normal user. These trusted accounts can be granted an extended right that effectively drops them from the audit log.
This is very valuable to customers who use this software.
This is very worrisome to people who must record every access, everywhere, by everyone.
Some customers will not be able to use SP2's extended auditing specifically because of this. For those customers, the existing Windows Auditing plus diagnostic logging will still function.
Making sense of all of this
Auditing mailbox access is actually the last step in a process that begins with understanding what your company's needs and requirements are. You need to understand what data you need, what degree of granularity is required. Then you need to decide how you are going to archive, access, and report on that data. Then you need to understand how to configure and control Exchange to produce the information that meets your needs.
We can't help you with the first problem - there are as many customer requirements for data as there are customers using auditing. Collection is also very specific, and reporting is quite possibly one of the single biggest variants in the whole field. When it comes to configuring and controlling this, CSS Escalation Engineer Mike Lagase and Tom Di Nardo from our CXP team have produced comprehensive documentation on this subject:
Understanding Mailbox Access Auditing with Exchange Server 2007 Service Pack 2
White Paper: Configuration and Mailbox Access Auditing for Exchange 2007 Organizations
This concludes this episode of "Service Pack 2" highlight. Stay tuned for the next one, in which we look at Public Folder Quotas and how we've made changes to make it clear which limits are enabled, what the limits are, and how to reliably control Public Folder quotas.
Auditing access to mailboxes (Who opened what) has always been difficult with Exchange Server. I first made my acquaintance with this code in Exchange 4.0 - and it hasn't changed much - until now. With Service Pack 2 we made a set of changes that will meet the needs of some organizations. Not everyone will be happy with our design decisions. Not everyone will be able to utilize Access Auditing for their needs. Those of you who can use these features, will be pleased to find that Service Pack 2 offers granularity, detail, and clarity for auditing mailbox access.
Decisions, Decisions
To start with, we had to decide what to log. One thing you will notice right away is the thing we decided not to log: Logons. Traditional auditing has involved turning up diagnostic logging on private logons and filtering through a lot of data. The problem with this is that a logon (in and of itself) doesn't really represent anything malicious. If I put Kurt Phillips on the recipient list of a meeting invite with Outlook, you might see my client attempt to logon. Not because I decided to try and read Kurt's mail) but because Outlook wants to check his free/busy. Get out the pitch forks or calmly pass over? It's hard to tell. On the other hand, if I opened user A's inbox - that would be valuable information. So Access Auditing is focused on actual access to data, not mailbox logons.
Success is what counts
We also decided to focus on access success, not failure. If you fail to open an inbox, Access Auditing does not record this. Again, focusing on actual access to actual data.
Location, Location, Location
The biggest change you will notice from Access Auditing is where it places the audit events. It is in essence a set of diagnostic logging categories for the Exchange Information Store. In studying the last five years worth of auditing cases, and every escalation where auditing was used to gather data, we realized that because of the volume of data, customers using private logon diagnostics often had to make a hard choice when confronted with an issue that required diagnostic logging:
1. Have the data necessary to audit access.
2. Have enough room for the other logging to troubleshoot.
Every version of Exchange has used the Application log as its dumping ground since Exchange 4.0. Until now. Exchange 2007, Service Pack 2 creates a new application log: Exchange Auditing. It is not the security log (and we've gotten a bunch of feedback for and against this). It is not the application log. It is the location where Exchange 2007 can output events related to mailbox access (and more.).
So what do we get?
You get a lot of information. All audited events associated with a user logon carry the same sort of information:
Object specific information, information about which NT Account was used, what mailbox was acted upon, and if you are running at least Outlook 2003 SP2, information about the machine the access was made from. You also get a great deal of choice about what is logged. Log only administrators using administrative rights, log only access from one user to another user's mailbox, or log access to any mailbox. The choice is yours to enable the amount of information you need to fit your needs.
Let's look at a sample access event:
Accessing user, mailbox being accessed, windows account, and information about what was accessed. That's not a bad set of data for customers who have to answer who did what and when.
You have the Right to Remain Invisible
One of the most controversial issues will, without a doubt, be the addition of a new extended right. For organizations with trusted service accounts (such as voice mail, brick backup, or device software) these applications generate anywhere from two to eight times as many events as a normal user. These trusted accounts can be granted an extended right that effectively drops them from the audit log.
This is very valuable to customers who use this software.
This is very worrisome to people who must record every access, everywhere, by everyone.
Some customers will not be able to use SP2's extended auditing specifically because of this. For those customers, the existing Windows Auditing plus diagnostic logging will still function.
Making sense of all of this
Auditing mailbox access is actually the last step in a process that begins with understanding what your company's needs and requirements are. You need to understand what data you need, what degree of granularity is required. Then you need to decide how you are going to archive, access, and report on that data. Then you need to understand how to configure and control Exchange to produce the information that meets your needs.
We can't help you with the first problem - there are as many customer requirements for data as there are customers using auditing. Collection is also very specific, and reporting is quite possibly one of the single biggest variants in the whole field. When it comes to configuring and controlling this, CSS Escalation Engineer Mike Lagase and Tom Di Nardo from our CXP team have produced comprehensive documentation on this subject:
Understanding Mailbox Access Auditing with Exchange Server 2007 Service Pack 2
White Paper: Configuration and Mailbox Access Auditing for Exchange 2007 Organizations
This concludes this episode of "Service Pack 2" highlight. Stay tuned for the next one, in which we look at Public Folder Quotas and how we've made changes to make it clear which limits are enabled, what the limits are, and how to reliably control Public Folder quotas.
mercredi 15 avril 2009
Codenamed Exchange 14
Codenamed Exchange 14.
Later today I will post what the cool new features are and yes they are cool.
Microsoft Exchange Server 2010 helps you achieve new levels of reliability and performance by delivering features that help to simplify your administration, protect your communications, and delight your users by meeting their demands for greater business mobility.
Microsoft Exchange® Server 2010 Beta helps IT Professionals achieve new levels of reliability with greater flexibility, enhanced user experiences, and increased protection for business communications.
* Flexible and reliable - Exchange Server 2010 gives you the flexibility to tailor your deployment based on your company's unique needs and a simplified way to keep e-mail continuously available for your users.
* Anywhere access - Exchange Server 2010 helps your users get more done by giving them the freedom to securely access all their communications - e-mail, voice mail, instant messaging, and more - from virtually any platform, Web browser, or device.
* Protection and compliance - Exchange Server 2010 delivers integrated information loss prevention, and compliance tools aimed at helping you simplify the process of protecting your company's communications and meeting regulatory requirements.
This software is intended for evaluation purposes only. You must accept the license terms before you are authorized to use this software. There is no product support for this trial software. You are welcome to participate in the forums to share your trial experiences with others and to ask for advice.
System Requirements
* Supported Operating Systems: Windows Server 2008; Windows Vista 64-bit Editions Service Pack 1
* Operating System for Installing Management Tools: The 64-bit editions of Microsoft® Windows Vista® SP1 or later, or Windows Server® 2008.
* PC - x64 architecture-based computer with Intel processor that supports Intel 64 architecture (formerly known as Intel EM64T) or AMD processor that supports the AMD64 platform
Additional requirements to run Exchange Server 2010 Beta
* Memory - Minimum of 4 gigabytes (GB) of RAM per server plus 5 megabytes (MB) of RAM recommended for each mailbox
* Disk space
o At least 1.2 GB on the drive used for installation
o An additional 500 MB of available disk space for each Unified Messaging (UM) language pack that you plan to install
o 200 MB of available disk space on the system drive
* Drive - DVD-ROM drive, local or network accessible
* File format - Disk partitions formatted as NTFS file systems
* Monitor – Screen resolution 800 x 600 pixels or higher
Exchange Server 2010 Beta Prerequisites
If these required prerequisites are not already installed, the Exchange Server 2010 Beta setup process will prompt and provide links to the installation locations; Internet access will be required if the prerequisites are not already installed or available on a local network.
* Microsoft® .NET Framework 3.5
* Windows PowerShell v2
* Windows Remote Management
Actual requirements will vary based on system configuration and specific features installed. For more detailed system requirements, please refer to the Exchange Server 2010 Technical Documentation Library.
For a list of Windows Server 2008 requirements, visit http://technet.microsoft.com/windowsserver/2008.
The downloadable software is for evaluation purposes only and is not a released product. If you plan to install the software on your primary computer, it is recommended that you back up your existing data prior to installation. Before you install the Microsoft® Exchange Server 2010 Beta, we recommend that you review the summary of system requirements and technical information located in the Exchange Server 2010 Technical Documentation Library.
Expiration Notice
This time-limited, free beta version of Microsoft® Exchange Server 2010 will end 360 days after installation.
To learn more about Microsoft® Exchange Server 2010 visit http://www.microsoft.com/exchange/2010
Exchange Server 2010 - Public Beta 1 now
Reviews
· Microsoft Exchange 2010 Beta Looks Solid from Core to Cloud (and related slideshow Microsoft Exchange Server 2010 Includes Welcome Improvements) – eWeek
· First look: Exchange 2010 beta shines – InfoWorld
News
· Broader Office 14 testing coming by fall - CNet
· Next Exchange features e-mail 'mute' button - CNet
· Microsoft Brands Office 2010, Releases Exchange Beta – PC World / IDG
· Microsoft fends off Google with Web browser-friendly Exchange 2010 - Computerworld
· Microsoft to release Exchange 2010 beta on April 15 - ZDNet
· Microsoft Exchange 2010 to address annoyances & mobility – Seattle PI
· Next version of Microsoft Office coming in 2010 - AP
lundi 30 mars 2009
Update Roll-up 7 for Exchange Server 2007 Service Pack 1 has been released
*Note! Comments have been disabled for this post. To comment on this post, please visit the Exchange Software Updates forum which deals with issues encountered in updates we release for Exchange. We will be monitoring the forums every day to assist you in applying this roll-up. Thanks for keeping your servers updated to the latest and greatest to take full advantage of our cumulative servicing model!
We have released Update Roll-up 7 for Exchange Server 2007 Service Pack 1 (KB 960384) to the download center. The release of the roll-up via Microsoft Update will happen on March 24.
Yes, it has been only 5 weeks since we shipped the last update roll-up on February 10 and usually our gap between roll-ups is about eight weeks. Since the release of update roll-up 6, we have fixed about 50 issues and wanted to go ahead and provide them to customers. How did this happen in a short span of 5 weeks? I am not inflating the figures. Actually, the last roll-up was special since it included the fix for a security issue as described in Microsoft Security Bulletin MS09-003. The test pass for that roll-up lasted much longer since all security related updates released by Microsoft go through a Security Update Validation Program (SUVP). As part of this program, the security updates are made available to a limited group of customers to test before its release on a second Tuesday. More on this program can be found at the MSRC blog here. As a result we had a shorter time available for including fixes in that roll-up. This also ensured a lower risk for the roll-up since the amount of code churn was lower. Of course, all this meant that we had more time on our hands to work on the development and testing for this roll-up and we are now ready a little earlier.
Now for the part which I like! Announcing some of the important fixes included in this roll-up to improve the customer experience:
- First off, we fixed the SCR issue which have caused everyone some pain and which did not get completed in time to be included in the last update roll-up.
KB 961281 Update Roll-up 5 for Exchange Server 2007 Service Pack 1 introduced an issue where you receive an error when attempting to enable SCR on a storage group if the environment has a parent domain -> child domain active directory structure. Tim has blogged about this over here. This is now fixed. Additionally, there are also 2 other SCR related issues which we have been addressed in this roll-up and have been asked for by many customers.
KB 957834 Network shares are deleted and created intermittently by the replication service on an Exchange SCC cluster when SCR is enabled on the Exchange server
KB 958331 Restore-StorageGroupCopy command may fail in an Exchange Server 2007 SCR environment.
- We have also fixed two issues which caused intermittent crashes in the IMAP4 service and resulted in event 4999 being logged in the event logs. The following KBs have more information on the scenarios which are fixed: KB 957504 and KB 960292.
Additionally we have also done a design change to address encapsulation and the way it is handled by Exchange Server 2007. If you would like to read the official version of this design change, you can read KB 956069. Of course for a lighter and funnier perspective on this, I will recommend Jason's blog post released as a run up to this roll-up release.
Oh! And I almost forgot. Thanks to the folks who helped provide service startup logs via the forums when they encountered an issue where some services would be left disabled after patch installation. The logs helped us identify a missed case when starting the MSExchangeTransportLogSearch service which would happen in scenarios where the server has more than one Exchange role installed on it.
KB 960384 has more details about this release and a complete list of all fixes included in this roll-up.
And finally, from the installation perspective, a friendly reminder that the roll-up installer will overwrite any OWA script files if required to ensure proper operation of OWA. So if you have customized the logon.aspx page or other similar OWA pages, you will need to redo any customization after installation of the roll-up. I promise, this is the last time I will remind everyone via the blog.
By the way, we will be disabling comments on this blog post. We have the Exchange Software Updates forum which deals with issues encountered in updates we release for Exchange. We will be monitoring the forums every day to assist you in applying this roll-up. Thanks for keeping your servers updated to the latest and greatest to take full advantage of our cumulative servicing model!
Exchange Server Remote Connectivity Analyzer
Have you ever installed an Exchange server and wanted to verify your Internet facing services were setup and configured properly? Things like Exchange ActiveSync, AutoDiscover, Outlook Anywhere (RPC/HTTP), and inbound email. Sure there are cmdlets included in Exchange 2007 like test-ActivesyncConnectivity and test-OWAConnectivity, but these tests can only be run inside your network and effectively only test your internal network connectivity. Or what if you get a call or an escalation regarding one of these services not working? How do you verify if just this user or everyone has a problem? And if there is a problem, where do you start troubleshooting? Is it a DNS problem? Is it a certificate problem? Is a port not open on the firewall?
Believe it or not, these client connectivity and inbound email scenarios make up a significant portion of the support calls we see at Microsoft. And I'm sure this is the same for our partners and customers. One of my responsibilities is to analyze the top support scenarios in Exchange and to work with the Product Group to develop solutions that mitigate these issues. Instead of looking at these issues individually, I took a step back and thought of a way to address all of these scenarios with a single tool. A couple of years ago, I shared this tool idea with several product group folks, but ultimately they didn't have the time or resources to make my idea a reality. Last year, I asked Brad Hughes (an Escalation Engineer in North Carolina) if he could build a prototype of my idea. Not only did he build a prototype... he built the tool I'm sharing with you today.
I'd like to introduce you to the Exchange Remote Connectivity Analyzer (ExRCA) tool which can be accessed at https://www.TestExchangeConnectivity.com.
In this version, the tool will allow you to remotely test the following client types and services:
Exchange ActiveSync
- Windows Mobile 5, 3rd party devices
- Windows Mobile 6.1+ with AutoDiscover
Outlook Anywhere (aka RPC/HTTP)
- Outlook 2003
- Outlook 2007 with AutoDiscover
Inbound SMTP
The tool will simulate the protocol logic used by the specific client and not only tell you if the scenario was successful, but if it fails, it will tell you exactly where in the process it failed as well as try to guide you to the problem resolution.
Here is a screenshot of the tool after it completes a successful Exchange ActiveSync connection:
There are a lot of technical details captured in each one of these steps and you can see this detail by expanding the "Additional Details" node.
The following screenshot shows a failed inbound SMTP test. In this scenario, an MX record is not found for the domain.
Notice in the screenshot above the "Tell me more about this issue and how to resolve it" link. For many of the failure points, we have links to troubleshooting tips on resolving the issues. This content portion of the tool is a work in progress and is being built by a few Support Engineers. Within these articles, you'll notice a "Community Content" section. (This is the area at the bottom of every topic where you can post a response) Please use this area to suggest other helpful tips for troubleshooting specific failure points. Assistance requests should be posted to the TechNet forums instead.
A few additional notes about the tool:
- Our UI is a work in progress. Neither one of us are UI design experts... but we think you'll be able to navigate around.
- A couple of the tests allow you to "Ignore trusts for SSL". Checking this option only tells the tool to not fail if the certificate you are using is not in the list of Trusted Root Certificates... for example if you were using a certificate from your own Windows CA. This option does not allow the test to be completed over a non-SSL connection. That is, if you do not have a certificate and want to test whether Exchange ActiveSync works over port 80 - this tool cannot perform this validation. (Note: We will not be able to add this feature in the future).
Note: Due to limitations in the RPC API, we are currently unable to ignore the trust requirement for SSL for the RPC over HTTP / Outlook Anywhere tests. We are looking into alternatives for future releases. - We know that the CAPTCHA is often (overly) difficult to read. (CAPTCHA is the challenge/response test in the "Verification" section) We have plans to implement a different flavor in the coming months. We don't think the replacement will be perfect either, but it will be black & white and will also have an audio option.
- We know there are currently navigation issues with the wizard when using the forward and back buttons in the browser; we hope to address these in an upcoming release. For now, avoid using the browser's forward and back buttons while using the tool. If you receive an error when navigating the pages, simply browsing to the URL again https://www.testexchangeconnectivity.com, should reset your session and allow you to continue using the tool.
We're not finished yet. We have plans to add additional tests. For example:
- Outlook Web Access
- IMAP
- POP
- Exchange Web Services
These will hopefully be available in the next few months.
We would love your feedback on this tool. Feel free to leave a comment here or send an email to Brad and me via the "Feedback" link located on the footer of every page of the web site. Also, please send us your 'success stories' after using this tool... we'd love to hear about them.
By the way, you can follow ExRCA on Twitter and also join our ExRCA Facebook group.
Here is a short 6 minute video that describes the Exchange Server Remote Connectivity Analyzer web site with visual images and also gives you a demo of how it works:
jeudi 10 juillet 2008
Password Export Server version 3.1
The Password Export Server version 3.1 (PES v3.1) is a part of the Active Directory Migration Tool (ADMT) v3.1 toolset. You can use PES v3.1 to migrate passwords, when performing account migrations between different Active Directory® Domain Service (AD DS) environments using ADMT v3.1.
PES v3.1 (x64)
PES v3.1 (x86)
PES v3.1 (x64)
PES v3.1 (x86)
Inscription à :
Messages (Atom)
