MySpace for Outlook enables you to view activity updates for friends and colleagues in the People Pane, synchronize your MySpace contact list to your Outlook contacts, and get one-click access to profiles.

See the press release on the MySpace Web site for more information, or go to the download page to get the provider.

Remember, if your computer is running the Outlook 2010 Beta, you must update the Outlook Social Connector before installing. See the instructions in our last post for more details on updating the Outlook Social Connector.

Thanks!

Michael Affronti

Outlook Program Manager

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

There are four options available to customize conversations:
· Show Messages from Other Folders
· Show Senders above the Subject
· Always Expand Conversations
· Use Classic Indented View.

To see these features, on the View tab, in the Arrangement group, click Conversations.

Show Messages from Other Folders

By default, Show Messages from Other Folders is turned on. Let’s imagine that you are viewing a conversation in your Inbox. You want to see the reply you last sent, which is in your Sent Items folder. Because Show Messages from Other Folders is turned on, sent messages appear in the conversation you are viewing in the Inbox. To see the sent message, click the conversation, and then fully expand it to show messages from the other folders.

Your message and the name of the folder— Sent Items — appears. You can open the message, or act on the message directly, such as applying a category or flag, without navigating to the Sent Items folder, and then opening the message.

Show Senders above the Subject

Do you like focusing on the people who send you messages more than the subject of the mail they sent? By selecting the Show Senders above the Subject option, the senders and subjects are switched. This makes it easier to locate messages based on sender instead of the subject.

Always Expand Conversations

When you first select a conversation, the latest messages in the conversation are shown in the List View so you can quickly get up to speed. However, to see all the messages in a conversation simultaneously, you can use the Always Expand Conversations options. All individual messages appear instead of the latest message in a conversation thread.

Use Classic Indented View

If you used previous versions of Outlook, this option is familiar to you. Click Classic Indented View and then your replies are indented under the messages you replied to. If you used conversations in previous versions, this option is automatically turned on when you upgrade to Outlook 2010.

We hope you enjoy using Conversation view and tailoring it to your needs!

Derek Brown, Outlook Software Design Engineer in Test
Jenny Liu, Outlook Program Manager
Josh Meisels, Outlook Program Manager

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:

1. 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.
2. 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).
3. 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.
4. 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.
5. KB 980261 We fixed passive page patching when diagnostic tracing code was needed for forensic analysis that was generating a -1022 error case.
6. KB 980262 Source side log copier errors are more gracefully handled when the log has a bad block and the read fails.
7. 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

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 user

1. 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

2. 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

3. 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

4. We remove the Search-MessageTrackingReport cmdlet from the "MyBaseOptionsWithoutMessageTracking" role:

   Remove-ManagementRoleEntry "MyBaseOptionsWithoutMessageTracking\Search-MessageTrackingReport"

5. 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

6. 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.

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:

-Perry Newman