|
|
Friday, March 19, 2010 9:59 AM
Exchange CXP team has released Update Rollup 3 for Exchange Server 2007 SP2 (KB979784) to the download center. The release of the rollup via Microsoft Update will happen on March 23rd. KBA 979784 lists the fixes included in this rollup. Here are some highlights of the product improvements and critical bug fixes: Forefront users: For those of you running Forefront, be sure you perform these important steps from the command line in the Forefront directory before and after this rollup's installation process. Without these steps, Exchange services for Information Store and Transport will not start back up. You will need to disable ForeFront via "fscutility /disable" before installing the patch and then re-enable after the patch by running "fscutility /enable" to start it up again post installation. Again, you can read the list of issues fixed up in KB979784. Regards, - Chuck Anderson
Thursday, March 18, 2010 10:21 AM
On Tuesday we released an updated ExPDA configuration XML file designed to address the issues raised by you: - Corrected the issue where ExPDA did not report that Exchange 2007 servers without Service Pack 2 were in the environment.
- Corrected an issue that identified Delivery Transport Agent connectors as EDK connectors.
- Corrected several rules that did not have proper titles to match their descriptions.
You have two ways to download the update: - Launch ExPDA. If you had selected to allow for automatic updates on startup, then ExPDA should detect the update and install it*. If you did not select to enable automatic updates, you can select "Updates and Customer Feedback" from the left-hand navigation and click "Check for updates now"*.
- You can manually download the updated configuration file and place it into the %Program Files%\Microsoft\Exchange Server\V14\ExPDA\<language> directory
* In some instances, you may receive "an error occurred while trying to access the web". If you receive this error, try launching ExPDA with elevated credentials (right-click the shortcut and select "Run as administrator"). In addition, certain proxy configurations prevent the BPA engine from downloading updates, so if this does not work, proceed with manually downloading the XML file. Thanks for using ExPDA and reporting these issues! - Ross Smith IV
Wednesday, March 17, 2010 12:11 PM
Now you can keep valuable information at hand with the new Microsoft Office Outlook Mobile Update and Microsoft Exchange Server 2010. The Outlook Mobile Update is available for Windows Mobile 6.1 phones. When your phone is connected to Exchange Server 2010, you are automatically informed if there is an update. If you have a Windows phone running Windows Mobile 6.5, you do not need this update. Top new features - E-mails grouped by conversation: With your e-mails grouped by conversation, you can quickly see all responses and perform common e-mail actions that apply to the entire conversation, such as deleting, replying, flagging, and moving e-mails.
 - Free/busy lookup: Getting in touch with people in your organization is now more effective with calendar availability. Have a quick question that needs to be answered? Quickly check a colleague's schedule to determine if a face-to-face visit in their office or a phone call is possible, or send them an e-mail if their schedule is booked.
 - Sync SMS messages to Exchange: SMS messages now appear inside of Outlook or Outlook Web Access, so you don't need to pull your phone out of your pocket to read and respond when you're sitting at your PC. You can even get your SMS text messages if you forgot your phone at home right from within Outlook or Outlook Web Access.
 - Enhanced voice mail: Exchange Server 2010 Unified Messaging provides voice mail preview, giving you a text version of your voice mail messages so you can read them without having to call and listen to each.
 More Information - Outlook Mobile Update Deployment Guide
- Outlook Mobile update supported on Windows Mobile 6.1 Professional and Standard versions.
- Currently supported languages:
- English
- German
- Chinese
- French
- Dutch
- Japanese
- Italian
- Russian
- Spanish
- Swedish
- Portuguese
- Supported languages coming soon:
- Korean
- Danish
- Finnish
- Norwegian
- Czech
- Polish
- Greek
-- Michael Higashi
Tuesday, March 16, 2010 5:04 PM
We updated the Exchange 2010 Mailbox Server Role Requirements Calculator. Head on over to the Updates Tracking page to see what is changed and/or download the revised version. The main article has also been updated. - Ross Smith IV
Monday, March 15, 2010 3:03 PM
When constructing Transport Rules, it is pretty straight forward to define a set of conditions and then specify the action to take when those conditions are met. It is easy to overlook an optional third component: Exceptions. Several customer questions that I have come across for how to enforce more complex policies were solved through the use of exceptions in their rule constructions. This article will present some example customer scenarios to help illustrate how exceptions can be used in Transport Rules. I won't go into a full overview of what Transport Rules are, or how they are managed (e.g., EMC, ECP, or PowerShell) in this article. If you are unfamiliar with the Exchange 2010 Transport Rules features, you may find it useful to first read the Transport Rule documentation on TechNet. What are transport rule exceptions? Transport rule exceptions look very similar to transport rule conditions. Transport rule conditions are used to identify which messages are to have the transport rule action applied to them; however, exceptions are used to exclude specific messages from the transport rule action. Exceptions are essentially loopholes in the transport rule, overriding the conditions and preventing a transport rule action from being applied to an e-mail message. You can configure multiple exceptions in a given transport rule, and it is important to understand that the logical relationship of these exceptions is such that if any one of the exceptions evaluates as true, then the message bypasses the rule - even if all of the conditions are met. To further explain the logical relationships in a transport rule: Condition 1
AND
Condition 2
AND
Condition 3 | All of these conditions must be TRUE for the action to be performed | Action 1 | This is the action performed on the message | Exception 1
OR
Exception 2
OR
Exception 3 | None of these conditions can be TRUE for the action to be performed. In other words: if any of these conditions are TRUE, then do not perform the action. | To view a full list of predicates that you can use for transport rule exceptions, see Transport Rule Predicates in Exchange 2010 documentation. Below are some example scenarios in which using exceptions are critical to meeting the organization's policy goals. Note that with the rich flexibility of transport rules there is often more than one way to construct a rule - the scenarios below are just examples to highlight the use of exceptions, and in many cases you could use different conditions to accomplish the same or similar goals. Scenario 1: Restrict to the same organizational division In this scenario, Contoso has a group of users that are working on a top secret project, and due to the sensitive nature of this project, these users should not be communicating project data with anyone outside of the project. Members of the secret project team can freely communicate with other members of the top secret project, and with the Human Resources department. Messages sent outside of these allowances must be approved by the team manager before delivery. Note that a company's policy statement may not match one-to-one with the logical components in the transport rule structure, so it may be necessary to restructure the policy statement into a Condition/Action/Exception logic for the transport rule. In the example above, we can recompose the policy statement to say: All messages sent from members of the top secret project team must be moderated by the team manager, except for messages sent to Human Resources or between members of the secret project team. Then to enforce this policy, the Contoso Exchange admin creates this Transport Rule: Conditions | Apply rule to messages
from a member of 'Project X' | Actions | Forward the message to 'Joe Manager' for moderation | Exceptions | Except when the message is sent to a member of 'Human Resources'
OR except when the message is sent between members of 'Project X' and 'Project X' | Scenario 2: Closed perimeter; only allow privileged users or specific external domains In this scenario (also known as the "Closed Campus" scenario), Contoso wishes to lock down their email perimeter to only allow internal communications. Users are not allowed to send or receive messages outside of the organization, unless they are members of a privileged group or the communication is with a specific partner e-mail domain. There are several different ways to do achieve this goal, but the key is still in configuring the Exceptions in a transport rule. For example, if Contoso wants to block all outbound messages except messages to fabrikam.com... Conditions | Apply rule to messages
sent to users that are "Outside the organization" | Actions | Send a rejection notice "You are not permitted to send e-mail to people outside of this organization" to the sender with the status code "5.7.1" | Exceptions | Except when a recipient's address contains "fabrikam.com" | By default all employee messages from Contoso to an external address will be blocked, except for external recipients with fabrikam.com in their email address (for example, "ed.banti@fabrikam.com"). Then, Contoso wants to additionally lift the restriction for a specific group of privileged Contoso users, so they add the following exception to the rule: Exceptions | Except when a recipient's address contains "fabrikam.com"
OR except when the message is from a member of "Privileged Users" | Finally, this scenario will actually need two transport rules to be complete. The rule to control outbound messages is shown above. Another rule to control inbound messages is needed, and would look like this: Closed Perimeter - Inbound Conditions | Apply rule to messages
sent to users that are "Outside the organization" | Actions | Send a rejection notice "You are not permitted to send e-mail to people outside of this organization" to the sender with the status code "5.7.1" | Exceptions | Except when a recipient's address contains "fabrikam.com"
OR except when the message is from a member of "Privileged Users" | Scenario 3: Closed perimeter, with a twist Now, let's twist the previous scenario - let's say that you want to block all outbound external messages unless the sender is in a privileged group AND it is to a specific external domain. You will remember from earlier in this article that multiple exceptions in a single rule are in a logical "OR" relationship, so how do we accomplish this goal? Answer: you need multiple rules that fire in sequence (remember, that transport rules fire in order of their priority value). If you break up enforcement of this policy into two stages, you can ensure that both exceptions have to be matched before letting the message out of the organization. For example: Outbound Rule 1 (priority = 1) Conditions | Apply rule to messages
sent to users that are "Outside the organization" | Actions | Send a rejection notice "You are not permitted to send e-mail to people outside of this organization" to the sender with the status code "5.7.1" | Exceptions | Except when the message is from a member of "Privileged Users"
| Outbound Rule 2 (priority = 2) Conditions | Apply rule to messages
sent to users that are "Outside the organization" | Actions | Send a rejection notice "You are not permitted to send e-mail to people outside of this organization" to the sender with the status code "5.7.1" | Exceptions | Except when a recipient's address contains "fabrikam.com"
| The first rule will only allow outbound messages from members of the Privileged Users group, and the second rule will then only allow the privileged senders to send mail to the fabrikam.com email domain. Other scenarios: The Technet online help for Exchange 2010 has some additional Transport Rules scenario examples, which rely on exceptions. I won't repeat the configuration details here, but I've provided links to the relevant articles below: - Disclaimers: an exception is used to prevent the application of a disclaimer where one already exists.
- Ethical Wall: an exception (in the PowerShell example) is used to allow Executives in restricted groups to communicate with each other.
If you have other example transport rules that you've implemented, in which the use of exceptions were key to meeting your policy goals, please share them with the rest of the community by posting them up in comments to this blog post. Thanks! -- Steve Clagg
Friday, March 12, 2010 1:00 PM
No matter how many lines of code it has, every software application has scalability limits.
Some limits can be caused by limits that are external to the application itself, while others can be inherent within the application. As a software engineering team, it is important for us to understand the scalability limits of the solution as a whole; this includes the limits of both external dependencies and internal code. Not only does this enable us to document and communicate this information to our customers, but it also helps us make better software. It provides us with a deeper understanding of our application within the most demanding environments.
Exchange 2010 is new and different from its predecessors in that, unlike all previous versions of Exchange, Exchange 2010 is the first version designed specifically to run as an on-premises application, as a hosted service in the cloud, and as a combination of both (cross-premise). At 20 million mailboxes and growing, it's more important than ever that our understanding of the limits of Exchange be crisp.
A while ago, we began the process of documenting the scalability limits of both Exchange 2007 SP2 and Exchange 2010. We've looked at all areas: things like organization sizing, rules sizing, IRM-protected messages, secure channels, named properties, load balancing, network latency, and more.
Here's our initial version of Exchange Scale Limitations spreadsheet documenting our findings thus far. There's a lot of great information in there, including issue descriptions, mitigations, and links where appropriate.
We hope you enjoy this first version. Please feel free to send us your comments and feedback.
-- Erin Bookey
Wednesday, March 10, 2010 4:51 PM
Over the years, displaying recipient photographs in the Global Address List (GAL) has been a frequently-requested feature, high on the wish lists of many Exchange folks. Particularly in large organizations or geographically dispersed teams, it's great to be able to put a face to a name for people you've never met or don't frequently have face time with. Employees are commonly photographed when issuing badges/IDs, and many organizations publish the photos on intranets. There have been questions about workarounds or third-party add-ins for Outlook, and you can also find some sample code on MSDN and elsewhere. A few years ago, an IT person wrote ASP code to make employee photos show up on the intranet based on the Employee ID attribute in Active Directory (AD) - which was imported from the company's LDAP directory. A fun project to satisfy the coder alter-ego of the IT person. Luckily, you won't need to turn to your alter-ego to do this. Exchange 2010 and Outlook 2010 make this task a snap, with help from AD. AD includes the Picture attribute (we'll refer to it using its ldapDisplayName: thumbnailPhoto) to store thumbnail photos, and you can easily import photos— not the high-res ones from your 20 megapixel digital camera, but small, less-than-10K-ish ones, using Exchange 2010's Import-RecipientDataProperty cmdlet. The first question most IT folks would want to ask is— What's importing all those photos going to do to the size of my AD database? And how much AD replication traffic will this generate? The attribute is limited to 10K in size, and the cmdlet won't allow you to import a photo that's larger than 10K. The original picture used in this example was 9K, and you can compress it further to a much smaller size - let's say approximately 2K-2.5K, without any noticeable degradation when displayed at the smaller sizes. If you store user certificates in AD, the 10K or smaller size thumbnail pictures are comparable in size. Storing thumbnails for 10,000 users would take close to 100 Mb, and it's data that doesn't change frequently. Note: The recommended thumbnail photo size in pixels is 96x96 pixels. With that out of the way, let's go through the process of adding pictures. A minor schema change First stop, the AD Schema. A minor schema modification is required to flip the thumbnailPhoto attribute to make it replicate to the Global Catalog. - If you haven't registered the Schema MMC snap-in on the server you want to make this change on, go ahead and do so using the following command:
Regsvr32 schmmgmt.dll - Fire up a MMC console (Start -> Run -> MMC) and add the Schema snap-in
- In the Active Directory Schema snap-in, expand the Attributes node, and then locate the thumbnailPhoto attribute. (The Schema snap-in lists attributes by its ldapDisplayName).
- In the Properties page, select Replicate this attribute to the Global Catalog, and click OK.
Figure 1: Modifying the thumbnailPhoto attribute to replicate it to Global Catalog Loading pictures into Active Directory Now you can start uploading pictures to Active Directory using the Import-RecipientDataProperty cmdlet, as shown in this example: Import-RecipientDataProperty -Identity "Bharat Suneja" -Picture -FileData ([Byte[]]$(Get-Content -Path "C:\pictures\BharatSuneja.jpg" -Encoding Byte -ReadCount 0)) To perform a bulk operation you can use Get-Mailbox cmdlet with your choice of filter (or Get-DistributionGroupMember if you want to do this for members of a distribution group), and pipe the mailboxes to a foreach loop. You can also retrieve the user name and path to the thumbnail picture from a CSV/TXT file. Thumbnails in Outlook 2010 Now, let's fire up Outlook 2010 and take a look what that looks like. In the Address Book/GAL properties for the recipient  Figure 2: Thumbnail displayed in a recipient's property pages in the GAL When you receive a message from a user who has the thumbnail populated, it shows up in the message preview.  Figure 3: Thumbnail displayed in a message While composing a message, the thumbnail also shows up when you hover the mouse on the recipient's name.  Figure 4: Recipient's thumbnail displayed on mouse over when composing a message There are other locations in Outlook where photos are displayed. For example, in the Account Settings section in the Backstage Help view. Update from the Outlook team Our friends from the Outlook team have requested us to point out that the new Outlook Social Connector also displays GAL Photos, as well as photos from Contacts folders and from social networks, as shown in this screenshot.  Figure 5: Thumbnail photos displayed in the People Pane in the Outlook Social Connector More details and video in Announcing the Outlook Social Connector on the Outlook team blog. GAL Photos and the Offline Address Book After you've loaded photos in Active Directory, you'll need to update the Offline Address Book (OAB) for Outlook cached mode clients. This example updates the Default Offline Address Book: Update-OfflineAddressBook "Default Offline Address Book" In Exchange 2010, the attributes in an OAB can be customized. This is done using the ConfiguredAttributes property of the OAB (see Set-OfflineAddressBook cmdlet). ConfiguredAttributes is populated with the default set of attributes, and you can modify it to add/remove attributes as required. By default, thumbnailPhoto is included in the OAB as an Indicator attribute. This means the value of the attribute isn't copied to the OAB— instead, it simply indicates the client should get the value from AD. If an Outlook client (including Outlook Anywhere clients connected to Exchange using HTTPS) can access AD, the thumbnail will be downloaded and displayed. When offline, no thumbnail downloads. Another example of an Indicator attribute is the UmSpokenName. You can list all attributes included in the default OAB using the following command: (Get-OfflineAddressBook "Default Offline Address Book").ConfiguredAttributes For true offline use, you could modify the ConfiguredAttributes of an OAB to make thumbnailPhoto a Value attribute. After this is done and the OAB updated, the photos are added to the OAB (yes, all 20,000 photos you just uploaded...). Depending on the number of users and sizes of thumbnail photos uploaded, this would add significant bulk to the OAB. Test this scenario thoroughly in a lab environment— chances are you may not want to provide the GAL photo bliss to offline clients in this manner. To prevent Outlook cached mode clients from displaying thumbnail photos (remember, the photo is not in the OAB— just a pointer to go fetch it from AD), you can remove the thumbnailPhoto attribute from the ConfiguredAttributes property of an OAB using the following command: $attributes = (Get-OfflineAddressBook "Default Offline Address Book").ConfiguredAttributes
$attributes.Remove("thumbnailphoto,Indicator")
Set-OfflineAddressBook "Default Offline Address Book" -ConfiguredAttributes $attributes -Bharat Suneja
Monday, March 08, 2010 1:57 PM
So I just installed RU1 on my brand new Exchange 2010 server and then I issue a Get-Exchangeserver -Identity MyExchangeServer and get the following output for AdminsDisplayVersion and ExchangeVersion: 
Ok that looks a little familiar for some reason. I go to my Exchange 2010 RTM server and issue the same CMDlet and get: 
...The same result! But one server has RU1 installed and the other is RTM. Shouldn't I get a different version number back? Well... no. Exchange 2007 and forward do not reflect the version number either in the value for AdminDisplayVersion, ExchangeVersion, or at this registry key HKLM\SOFTWARE\Microsoft\v8.0\<Role>\ConfiguredVersion as influenced by roll ups. This is a common misconception. The most conclusive way to get the version of your exchange server, rollup and all, is to check the file version of ExSetup.exe in the BIN folder. Here is Exchange 2010 RU1 version: 
And here is Exchange 2010 RTM: 
Another way of getting this information is to run the following PowerShell one-liner: GCM exsetup |%{$_.Fileversioninfo} The below output is from an exchange 2010 server running RU1: 
Here is an exchange 2010 RTM server: 
You can then correlate the version number you find with those listed here, here or on the actual rollup update download pages. Hope this post reduces some confusion out there! - Tom Kern
Friday, March 05, 2010 11:58 AM
Exchange CXP team has released Update Rollup 2 for Exchange Server 2010 RTM (KB 979611) to the download center.
KB 979611 lists all the fixes included in this rollup. Here are some of the product improvements and critical bug fixes we'd like to call out starting with a couple of IMAP improvements:
- KB 977633 This fixes IMAP4 clients ability to log on to their mailboxes if the mailboxes are located on Exchange 2003 backend servers and if the clients are connecting via Exchange 2010 CAS servers.
- KB 979480 IMAPid was not working correctly after moving a lot of users from one Exchange 2010 server to another*. IMAP4 users complained about the inbox not being updated any more. Old messages were still visible, but messages which were received after the mailbox move were not visible. The problem affected different IMAP Clients. The problem did not affect MAPI clients and OWA. Now it is fixed up.
*(Specifically this occurred in the situation with same DAG, now local storage instead of iSCSI storage, all servers are Exchange 2010 with Update Rollup 1 installed on Windows Server 2008 R2).
- KB 979431 When user migrated from Exchange Server 2003 to Exchange Server 2010, and that user connected via POP3, the POP3 service crashed. This was fixed up so it will not crash.
- KB 979563 Push Notifications didn't work because Exchange Server 2010 was not sending SOAPAction header in the notify callback. This caused Exchange to receive a HTTP 500 response from the notification client and the webservice failed. Push notifications should now properly send that SOAP header.
- KB 980261 We fixed passive page patching when diagnostic tracing code was needed for forensic analysis that was generating a -1022 error case.
- KB 980262 Source side log copier errors are more gracefully handled when the log has a bad block and the read fails.
- KB 979566 Activesync proxy was failing for linked mailboxes in a CAS to CAS proxy scenario where the users token is serialized and sent in the request. When attempting to create the client security context from the SID, a AuthZException was thrown because we did not have access to the token information of the linked account, so now for this it no longer throws exceptions.
Only the English Rollup?
Customers may not install the rollup because they may feel that this should only be installed on an English Exchange Server. This was true for Exchange 2007 and is not true for Exchange 2010. When installing this rollup, the UI will be English and the “Add/Remove Programs” text will be English. We are expecting to release the other rollup installation language strings with the next rollup. We are finishing UI validation.
Known Issue
With Update Rollup 2 for Exchange Server 2010 RTM, we introduced a new parameter for the Set-ClientAccessServer cmdlet, CleanUpInvalidAlternateServiceAccountCredentials. Unfornately, the parameter cannot be used at this time. However the Set-ClientAccessServer cmdlet still functions with all other available parameters.
The cmdlet functions but not the parameter because of how RBAC works at the Organization\Enterprise level. The change functions as expected, except for this one issue. This issue blocks some functionality offered by this particular fix. We have a work around and we are currently performing testing and ensuring that we document it correctly. It will require running “Install-CannedRbacRoles” on one server after the rollup is installed. Once replication happens across the AD, the parameter will be available for use for the servers that have the rollup installed.
KB 979611 has more details about this release and a complete list of all fixes included in this rollup.
-Exchange
Thursday, March 04, 2010 11:00 AM
For various reasons, there are times when an administrator does not want a part of the ECP to be accessible by some users and they desire a features' tab or entry point to not be visible at all. The web.config file for the Exchange Control Panel (ECP) contains the requirements a logged in user must meet before the feature tab or configuration item may be displayed in the UI. Here we will step through an example of how to go through the process of determining what you must do to accomplish this task. IMPORTANT: Exchange Control Panel files are not modified to accomplish this — the process only involves changing the user's RBAC Role assignment. SUPPORT NOTE: Modifying the Exchange Control Panel files to remove parts of the UI is not supported. Serious problems may occur if you modify web.config files. The only supported way of removing a feature from the ECP is by modifying the effective rights a user has using RBAC, as documented in this post. In Exchange 2010, Role Based Access Control (RBAC) is the new permissions model that allows you to assign granular permissions based on management roles. To learn more about RBAC, see Understanding Role Based Access Control in Exchange 2010 documentation, and the previous post RBAC and the Triangle of Power. Remove the Delivery Reports tab for a userIn Exchange 2010, the Delivery Reports tab in ECP allows users to retrieve delivery reports for messages sent to or received by them. In this example, the goal is to not display the Delivery Reports tab in ECP so it's not accessible by a user.  Figure 1: The Delivery Reports tab in ECP - To remove the Delivery Reports tab from ECP for a user, we need to determine what's needed for the tab to show. To get this information, we need to check the Web.Config file located in ECP's folder at ":\Program Files\Microsoft\Exchange Server\V14\ClientAccess\ecp\Reporting". ECP uses the authorization section of the Web.Config file to evaluate if the tab should be displayed. If the user is not allowed to run the cmdlet shown, the tab is not displayed. Let's view the Authorization section of the Deliveryreports.slab location path:
<location path="DeliveryReports.slab">
<system.web>
<authorization>
<allow roles="Search-MessageTrackingReport@R:Organization" />
<!-Deny everyone else ->
<deny users="*" />
</authorization>
As shown in the above figure, access to the Search-MessageTrackingReport cmdlet is required to display the Delivery Reports tab. To disable the Delivery Reports tab, we need to determine which RBAC roles can run the Search-MessageTrackingReport cmdlet, so we can remove the permission for the user to run it. This ensures the tab will not be displayed to that user.
To determine which RBAC roles can run the Search-MessageTrackingReport cmdlet, we use the Get-ManagementRole cmdlet:
Get-ManagementRole -cmdlet Search-MessageTrackingReport The result:
Name RoleType
------- --------------
Message Tracking MessageTracking
View-OnlyConfiguration ViewOnlyConfiguration
MyBaseOptions MyBaseOptions Next we must determine which of the above roles the user is a member of and where it would make sense to remove the Search-MessageTrackingReport cmdlet from. For example, we wouldn't want to remove the cmdlet from the ViewOnly Configuration because that is an administrative role. The user is not an administrator, and therefore it's not likely that he/she has been assigned the MessageTracking role. This means that we will have to check to see what roles/assignments the user is a member of: Get-RoleGroup | where {$_.Members -like "*Display UserName*"} | fl name The command doesn't return any results because the user is not a member of any administrator type role. Next, we will check the management role assignments for this user: Get-ManagementRoleAssignment -RoleAssignee UserName Among other items you see the list of roles (note these are user/self configuration roles): Name Role
-------- ---------
MyBaseOptions-Default Role Assignment Policy MyBaseOptions
MyContactInformation-Default Role Assignment Policy MyContactInformation
MyVoiceMail-Default Role Assignment Policy MyVoiceMail
MyDistributionGroupMembership-Default Role Assignment Policy MyDistributionGroupMembership
Custom Default Policy MyDiagnostics It looks like the only one we are interested in here is the "MyBaseOptions" because we already know that the cmdlet we want to block is only available in that role that the user has anything to do with. The user is not an administrator so the other roles are not interesting to us for this scenario. To make sure the user is assigned to the role assignment policy we can verify: Get-Mailbox UserName | fl roleassignmentpolicy RoleAssignmentPolicy: Default Role Assignment Policy Tip: If you want to combine some of the above steps into one line to find out which role contains that cmdlet we are interested in (Search-MessageTrackingReport), you can use the following set of cmdlets:
Get-ManagementRole -Cmdlet Search-MessageTrackingReport | Get-ManagementRoleAssignment -RoleAssignee UserName -Delegating $False | FT Role, RoleAssigneeName
The result:
Role RoleAssigneeName
---- ----------------
MyBaseOptions Default Role Assignment Policy -
Now, we know that we need to create a new Role Assignment Policy for the user and associate it with a new (customized) MyBaseOptions role. We will make a copy of the MyBaseOptions role so we can remove the Search-MessageTrackingReport cmdlet from it. First, we will create a new (end user) Role Assignment Policy called Alternate Assignment Policy, and leave the original policy unchanged (for other users who should still have access to the Delivery Reports tab).: New-RoleAssignmentPolicy "Alternate Assignment Policy" For this new policy, we need to turn on a few of the default options that the Default Policy had. For example, to add the ability for the user to edit their own contact information we add the MyContactInformation role to the policy:
New-ManagementRoleAssignment -Name "MyContactInformation-Alternate Assignment Policy" -policy "Alternate Assignment Policy" - role MyContactInformation
To add the ability for the user to manage their own distribution group membership, we add the MyDistributionGroupMembership role to the policy:
New-ManagementRoleAssignment -Name "MyDistributionGroupMembership-Alternate Assignment Policy" -policy "Alternate Assignment Policy" - role MyDistributionGroupMembership -
Now we need to create a copy of the MyBaseOptions role so we can remove the Search-MessageTrackingReport cmdlet from it and then assign it to the new Role Assignment Policy. We can give it any name, preferably something with a good description.: New-ManagementRole "MyBaseOptionsWithoutMessageTracking" -Parent MyBaseOptions - We remove the Search-MessageTrackingReport cmdlet from the "MyBaseOptionsWithoutMessageTracking" role:
Remove-ManagementRoleEntry "MyBaseOptionsWithoutMessageTracking\Search-MessageTrackingReport" - Next, we assign the newly created MyBaseOptionsWithoutMessageTracking role to the Role Assignment Policy:
New-ManagementRoleAssignment -Name "MyBaseOptionsWithoutMessageTracking-Alternate Assignment Policy" -policy "Alternate Assignment Policy" - role MyBaseOptionsWithoutMessageTracking - Then, we assign the Role Assignment Policy to the user:
Set-mailbox mod1user1 -RoleAssignmentPolicy "Alternate Assignment Policy" This can also be performed in the ECP, as shown in figure 2. 
Figure 2: Assigning the Role Assignment Policy to the user in ECP
Done! Now we can test the user experience. As shown in figure 3, when UserName logs on, the Delivery Reports tab isn't visible.  Figure 3: The Delivery Reports tab is removed for the user After the Delivery Reports tab is removed, if your user tries to track a message from within Outlook Web App or Outlook, he/she will receive the following error:  Figure 4: Error when user tries to track a message
-Perry Newman
Saturday, February 27, 2010 8:06 AM
The latest release of Microsoft Exchange can help you achieve better business outcomes while controlling the costs of deployment, administration, and compliance. Exchange 2010 delivers a wide range of deployment options, integrated information leakage protection, and advanced compliance capabilities. Check out our free webcasts and podcasts, and then try Exchange 2010 for yourself by taking one of our virtual labs or labcasts. - TechNet Webcast: Microsoft Exchange Server 2010 Management and Operations (Level 200)
Thursday, March 11, 2010
11:00 A.M.-12:30 P.M. Pacific Time
- TechNet Webcast: Microsoft Exchange Server 2010 Unified Messaging (Level 300)
Tuesday, March 16, 2010
11:00 A.M.-12:30 P.M. Pacific Time
- TechNet Webcast: Calendar Sharing and Federation in Microsoft Exchange Server 2010 (Level 300)
Thursday, March 18, 2010
11:00 A.M.-12:30 P.M. Pacific Time
- TechNet Webcast: Deploying and Managing Microsoft Exchange Server 2010 Transport Servers (Level 200)
Tuesday, March 23, 2010
11:00 A.M.-12:30 P.M. Pacific Time
- TechNet Webcast: Microsoft Exchange Server 2010 Storage Architecture (Level 300)
Thursday, March 25, 2010
11:00 A.M.-12:30 P.M. Pacific Time
Wednesday, February 24, 2010 12:33 PM
Today I am pleased to announce the release of the Exchange Server Pre-Deployment Analyzer (ExPDA). You can use the Exchange Pre-Deployment Analyzer to perform an overall topology readiness scan of your environment. When you run the Exchange Pre-Deployment Analyzer, it provides a detailed report that will alert you if there are any issues within your organization, which could prevent you from deploying Exchange 2010. For example, the Exchange Pre-Deployment Analyzer will notify you if you haven't deployed the minimum required Exchange service pack on all your existing Exchange servers. The checks performed by ExPDA are similar to the pre-requisite checks implemented (via Exchange Best Practices Analyzer) in the Exchange 2010 Setup program; in fact ExPDA is based off the Exchange Best Practices Analyzer (ExBPA) engine. However, unlike Exchange 2010 setup, this tool focuses only on overall topology readiness and not the ability to run Exchange 2010 on the local computer. The scan also performs a deep analysis of each existing Exchange 2003/2007 server to verify that it has the necessary updates and configuration in-place to support Exchange 2010. The end report is structured as follows: - Critical - A configuration problem that will prevent Exchange 2010 from being deployed in the organization. For example, the Active Directory Forest is not operating in Windows Server 2003 Forest Functional Mode or higher.
- Warning - A configuration item that may prevent customers having the best possible experience with Exchange 2010. A warning may also reflect some functionality that is not available in Exchange 2010.
ExPDA is another component in our vision to provide a seamless upgrade experience that reduces the complexities in deploying Exchange 2010. To start planning your upgrade, please utilize the Exchange Deployment Assistant. The Deployment Assistant allows a customer to create Exchange 2010 on-premises deployment instructions that are customized to their environment. The Assistant asks a small set of questions, and based on the answers, it provides a finite set of instructions that are designed to get a customer up and running on Exchange 2010. Running the Exchange Server Pre-Deployment Analyzer is now a recommended step within the pre-requisites section of the Deployment Assistant. You can download ExPDA at http://www.microsoft.com/downloads/details.aspx?FamilyID=88b304e7-9912-4cb0-8ead-7479dab1abf2&displaylang=en. ExPDA is supported on Windows 7, Windows Vista with Service Pack 2, Windows Server 2008 with Service Pack 2, Windows Server 2008 R2, and Windows Server 2003 with Service Pack 2. Q&A - Does this tool replace the Exchange Deployment Assistant?
No, ExPDA is merely an additional tool that can be used as a step within the upgrade experience. The Exchange Deployment Assistant will walk you through all aspects of the upgrade, namely how to coexist properly with Exchange 2010 and legacy versions of Exchange, whereas, ExPDA is one step within that process and ensures that the environment is ready to have the first Exchange 2010 server deployed. - I ran the scan and have questions about the results. What should I do?
If you'd like to read more about the requirements of Exchange 2010, please see the Planning for Exchange 2010 section on TechNet. - I ran the scan and received unexpected results. If I think there's a bug, who can I contact?
If you need assistance, please visit the Exchange Server Deployment Forum or you can send mail to exbpafb AT Microsoft DOT com. - Is this new functionality available in all languages?
No. ExPDA is only available as a U.S. English version. - I'd like to know if my organization is capable of running Exchange 2007. Can I use ExPDA to check this?
No, ExPDA only verifies if an organization is ready to have the first Exchange 2010 server installed. If you need to determine whether your organization is ready to have Exchange 2007 deployed, you can utilize ExBPA v2.8 and the latest Exchange 2007 ExBPA.Readiness.xml: - Install ExBPA 2.8 and the last ExBPA 2.8 Update.
- Download the latest Exchange 2007 service pack rollup. At the time of this writing this is SP2 RU2.
- Extract the rollup binaries using this command: msiexec /a filepath to MSI file /qb TARGETDIR=filepath to target folder
- Copy the ExBPA.Readiness.xml to the \en folder.
- Launch ExBPA.
- Where can I look at the list of checks made in this new scan?
If you're familiar with the BPA XML files, the new check is wholly contained within the ExBPA.Readiness.xml file located within %Program Files%\Microsoft\Exchange Server\V14\ExPDA\en folder. - Reporting the number of Active Directory trees, domains, sites, admin groups, routing groups, Exchange 5.5 servers, Exchange 2000 servers, Exchange 2003 servers, total mailboxes, Windows 2000 Active Directory servers, Windows Server Active Directory servers, Windows Server Active Directory servers. Report how many Active Directory domain/sites have Exchange servers installed.
- Verifying that the Schema Master is Windows 2003 SP1 or later.
- Identifying Active Directory domains that are not in native mode.
- Identifying Active Directory sites that do not have a global catalog server running Windows 2003 SP1 or later.
- Verifying that there are zero Active Directory Connector servers in existence.
- Identifying any SMTP site links in existence.
- Verifying that the Exchange organization is in native mode.
- Identifying any non-standard proxy address generators.
- Identifying whether you have any ambiguously defined email addresses in your recipient policies.
- Identifying any non-MAPI public folder hierarchies (a.k.a. AppTLH's) in use.
- Identifying Routing Groups that span Active Directory sites.
- Identifying any Active Directory sites that span Routing Groups.
- Identifying any Routing Group Connectors that have specialized settings (activation, max size, accept/reject lists, restrict message type/priority).
- Identifying any SMTP Connectors that support non-SMTP address spaces.
- Identifying any SMTP Connectors that use inline domain-wildcarding for address spaces (e.g. *foo.com instead of *.foo.com).
- Identifying any X.400 Connectors in the topology.
- Identifying any EDK-based Connectors in the topology (excluding Notes).
- Verifying that any servers running Exchange 2003 have SP2 or later.
- Verifying that any servers running Exchange 2007 have SP2 or later.
- Identifying any SMTP virtual servers that are not using port 25 for incoming/outgoing.
- Verifying that all Exchange 2003 servers have SuppressStateChanges set.
- Identifying any Exchange 2003 servers that have active NNTP newsfeeds.
- Identifying any Exchange 2003 servers that use the Event Scripting service.
- Identifying any Exchange 2003 servers that have the ExIFS (a.k.a. M:) drive enabled.
- Identifying any parts of Active Directory that have Access Control Entry inheritance disabled.
Thanks for your continued support. Feel free to post feedback in comments of this blog post, or visit the Exchange Server Deployment Forum. - Ross Smith IV
Monday, February 22, 2010 7:49 AM
In Exchange Server 2010, there is no more single instance storage (SIS). To help understand why SIS is gone, let's review a brief history of Exchange. During the development of Exchange 4.0, we had two primary goals in mind, and SIS was borne out of these goals: - Ensure that messages were delivered as fast and as efficient as possible.
- Reduce the amount of disk space required to store messages, as disk capacity was premium.
Exchange 4.0 (and, to a certain extent, Exchange 5.0 and Exchange 5.5) was really designed as a departmental solution. Back then, users were typically placed on an Exchange server based on their organization structure (often, the entire company was on the same server). Since there was only one mailbox database, we maximized our use of SIS for both message delivery (only store the body and attachments once) and space efficiency. The only time we created another copy within the store was when the user modified their individual instance. For almost 19 years, the internal Exchange database table structure has remained relatively the same: 
Then came Exchange 2000. In Exchange 2000, we evolved considerably - we moved to SMTP for server-to-server connectivity, we added storage groups, and we increased the maximum number of databases per server. The result was a shift away from a departmental usage of Exchange to enterprise usage of Exchange. Moreover, the move to 20 databases reduced SIS effects on space efficiency, as the likelihood that multiple recipients were on the same database decreased. Similarly, message delivery was improved by our optimizations in transport, so transport no longer benefited as much from SIS either. With Exchange 2003, consolidation of servers took off in earnest due to features like Cached Exchange Mode. Again the move away from departmental usage continued. Many customers moved away from distributing mailboxes based on their organization structure to randomization of the user population across all databases in the organization. Once again, the space efficiency effects of SIS were further reduced. In Exchange 2007, we increased the number of databases you could deploy, which again reduced the space efficiency of SIS. We further optimized transport delivery and completely removed the need for SIS from a transport perspective. Finally, we made changes to the information store that removed the ability to single instance message bodies (but allowed single instancing of attachments). The result was that SIS no longer provided any real space savings - typically only about 0-20%. One of our main goals for Exchange 2010 was to provide very large mailboxes at a low cost. Disk capacity is no longer a premium; disk space is very inexpensive and IT shops can take advantage of larger, cheaper disks to reduce their overall cost. In order to leverage those larger capacity disks, you also need to increase mailbox sizes (and remove PSTs and leverage the personal archive and records management capabilities) so that you can ensure that you are designing your storage to be both IO efficient and capacity efficient. During the development of Exchange 2010, we realized that having a table structure optimized for SIS was holding us back from making the storage innovations that were necessary to achieve our goals. In order to improve the store and ESE, to change our IO profile (from many, small, random IOs to larger, fewer, more sequential IOs), and to resolve our inefficiencies around item count, we had to change the store schema. Specifically, we moved away from a per-database table structure to a per-mailbox table structure: 
This architecture, along with other changes to the ESE and store engines (lazy view updates, space hints, page size increase, b+ tree defrag, etc.), netted us not only a 70% reduction in IO over Exchange 2007, but also substantially increased our ability to store more items in critical path folders. As a result of the new architecture and the other changes to the store and ESE, we had to deal with an unintended side effect. While these changes greatly improved our IO efficiency, they made our space efficiency worse. In fact, on average they increased the size of the Exchange database by about 20% over Exchange 2007. To overcome this bloating effect, we implemented a targeted compression mechanism (using either 7-bit or XPRESS, which is the Microsoft implementation of the LZ77 algorithm) that specifically compresses message headers and bodies that are either text or HTML-based (attachments are not compressed as typically they exist in their most compressed state already). The result of this work is that we see database sizes on par with Exchange 2007. The below graph shows a comparison of database sizes for Exchange 2007 and Exchange 2010 with different types of message data: 
As you can see, Exchange 2007 databases that contained 100% Rich Text Format (RTF) content was our baseline goal when implementing database compression in Exchange 2010. What we found is that with a mix of messaging data (77% HTML, 15% RTF, 8% Text, with an average message size of 50KB) that our compression algorithms are on par with Exchange 2007 database sizes. In other words, we mitigated most of the bloat caused by the lack of SIS. Is compression the answer to replacing single instancing all together? The answer to that question is that it really does depend. There are certain scenarios where SIS may be viable: - Environments that only send Rich-Text Format messages. The compression algorithms in Exchange 2010 do not compress RTF message blobs because they already exist in their most compressible form.
- Sending large attachments to many users. For example, sending a large (30 MB+) attachment to 20 users. Even if there were only 5 recipients out of the 20 on the same database, in Exchange 2003 that meant the 30MB attachment was stored once instead of 5 times on that database. In Exchange 2010, that attachment is stored 5 times (150 MB for that database) and isn't compressed. But depending on your storage architecture, the capacity to handle this should be there. Also, your retention requirements will help here, by forcing the removal of the data after a certain period of time.
- Business or organizational archives that are used to maintain immutable copies of messaging data benefit from single instancing because the system only has to keep one copy of the data, which is useful when you need to maintain that data indefinitely for compliance purposes.
If you go back through our guidance over the past 10 years, you will never find a single reference to using SIS around capacity planning. We might mention it has an impact in terms of the database size, but that's it. All of our guidance has always dictated designing the storage without SIS in mind. And for those that are thinking about thin provisioning, SIS isn't a reason to do thin provisioning, nor is SIS a means to calculate your space requirements. Thin provisioning requires an operational maturity that can react quickly to changes in the messaging environment, as well as, a deep understanding of the how the user population behaves and grows over time to sufficiently allocate the right amount of storage upfront. In summary, Exchange 2010 changes the messaging landscape. The architectural changes we have implemented enable the commoditization of email - providing very large mailboxes at a low cost. Disk capacity is no longer a premium. Disk space is cheap and IT shops can take advantage of larger, cheaper disks to reduce their overall cost. With Exchange 2010 you can deploy a highly available system with a degree of storage efficiency without SIS at a fraction of the cost that was required with previous versions of Exchange. So, there you have it. SIS is gone. - Ross Smith IV
Wednesday, February 17, 2010 8:48 AM
Please go to our Mailbox Server Role Storage Requirements Calculator updates tracking page to see what is in this new version! A blog post explaining the calculator (updated for this new version) is here. Comments welcome! - Ross Smith IV
Tuesday, February 16, 2010 3:04 PM
In Exchange 2010, users can easily create call answering rules to have a call answered based on the specified conditions. Users can create rules to answer calls from specified callers or Contacts in a certain way, handle calls differently based on their availability (Free/Busy status) or time of day. The call answering rule will only be triggered when all the associated conditions are met. In this post, I will cover: - The different classes of conditions supported in UM 2010
- How does UM go about evaluating a given set of call answering rules
This article assumes that you have read my previous post Call Answering Rules (Part I) - Creating your first Call Answering Rule. The Call Answering Rule form The diagram below shows you the Call Answering Rule form. In particular: - Condition(s) which have already been added to the rule is located on the left (in green). You can remove them by clicking on the symbol beside the condition.
- Condition(s) which you can further add to this rule is located on the right (in red). To start adding new condition, simplify click on the condition desired.
 Figure 1: The call answering rule form Different classes of conditions There are 4 different classes of conditions supported by UM 2010, namely: - Caller identity
- Time-of-the-day
- Calendar free/busy status
- When my automated email reply is turned on
-
Caller IdentityUsers can use different call answering rules for different callers. For example, if you receive a call from an important customer's phone number, you can answer it differently. To answer calls based on caller identity, users can add a caller-ID condition to a call answering rule such that the rule will only be triggered if the calling party matches one of those specified. To configure this condition:
- Click on "If the caller is." condition to bring up the following UI control.
Figure 2: Call answering rule based on caller
- Specify 1 or more phone numbers, pick Contacts from the GAL or your Contacts folder, or specify the entire Contacts folder.
- Click on "Apply" to close the UI control.
-
Time of DayUsers can add a time-of-the-day condition to a call answering rule such that the rule will only be triggered if the time of the call matches the time period specified. For example, during working hours, calls can be answered using the "Follow-Me" action, or routed straight to voicemail during after-hours. To configure this condition: - Click on If it is during this period. condition to bring up the following UI control:
Figure 3: Call answering rule based on time of day
- Specify a period, either working hours, non-working hours or custom hours.
- Click on Apply to close the UI control.
-
Calendar Free/Busy status Users can specify a condition for a call answering rule based on their availability (calendar Free/Busy status). To do so: - Click on If my schedule shows that my status is. condition to bring up the following UI control:
Figure 4: Call answering rule based on Free/Busy Status
- Pick one or more Free/Busy status which you want this rule to fire. In the example provided, I have specified that the call answering rule to be triggered if my calendar shows that I am either Busy or Away.
- Click on Apply to close the UI control.
-
When my automated email reply is turned on Users can specify that a call answering rule only be fired when their automatic email reply is turned on. To do so, simply click on "If Automatic Replies are turned on" condition.
Call Answering Rules and conditions It is possible to associate the same call answering rule with multiple conditions. All the conditions must be met in order for the call answering rule to be trigger. You can also create call answering rules without specifying any condition. When such a rule is encountered, it will be triggered as though all its conditions are met. Multiple Call Answering Rules You can create one or more call answering rules. You can also associate each call answering rule with one or more conditions. The diagram below illustrates an example with 3 call answering rules configured. You can enable/disable or reorder the rules. 
Figure 5: Multiple call answering rules
As illustrated in the flow diagram below, for each call answering call received: - No call answering rules configured: If you do not have any call answering rules configured, UM will offer the caller to leave a voice message.
- One or more call answering rules configured: If there are one or more call answering rules configured, UM will evaluate these rules in a top-down fashion. The first rule, whose conditions are met, will be fired.
- After evaluating all the rules, if UM is unable to find a rule whose conditions are met, UM will offer the caller to leave a voice message.
Figure 6: How UM call answering rules are evaluated
Call answering rules are an Exchange 2010 feature, and only available to UM-enabled users with a mailbox on an Exchange 2010 Mailbox server. -Chun Yong Chua
|
|
|