Friday, August 22, 2014

Troubleshooting Steps : The Proxy address "MBX:0" is already being used by org/users/username

Issue : Error received when for few user tried to change the "Set as Reply" 

The Proxy address "MBX:0" is already being used by "org/users/username". Please choose another proxy address

Resolution :  From the ADSIEdit.msc, remove the Problematic address from the Attribute "ProxyAddress"

Users had been migrated from Exchange 2003 to Exchange 2010, while moving mailbox Exchange stamps mailbox for processing with MBX:0 and MBX:1 likewise

Tuesday, August 5, 2014

Cross Forest Migration

Tools

1.  Microsoft Identity Lifecycle Manager (ILM) 2007 Feature Pack 1 (FP1) 
2. MIIS
3. FIM, other 3rd party dirsync tool, etc

2. Scripts

(a) This example configures the Availability service to retrieve per-user free/busy information on a Mailbox server in the target forest.
Get-MailboxServer | Add-ADPermission -Accessrights Extendedright -Extendedrights "ms-Exch-
EPI-Token-Serialization" -User "<Remote Forest Domain>\Mailbox servers"

Add-AvailabilityAddressSpace -Forestname ContosoForest.com -AccessMethod PerUserFB -UseServiceAccount:$true

(b) To configure bidirectional cross-forest availability, repeat these steps in the target forest.

If you choose to configure cross-forest availability with trust, and also choose to use a service account (instead of specifying organization-wide or per-user credentials), you must extend permissions as shown in the example in the "Use the Shell to configure trusted cross-forest availability with a service account" section. Performing that procedure in the target forest gives Mailbox servers in the source forest permission to serialize the original user context.
(c) This example configures trusted cross-forest availability with a service account.
Get-MailboxServer| Add-ADPermission -Accessrights Extendedright -Extendedright "ms-Exch-EPI-Token-Serialization" -User "<Remote Forest Domain>\Exchange servers"

This example sets the organization-wide account on the availability configuration object to configure the access level for free/busy information in the target forest
Set-AvailabilityConfig -OrgWideAccount "Contoso.com\User"

This example adds the Availability address space configuration object for the source forest.
$a = Get-Credential (Enter the credentials for organization-wide user in Contoso.com domain)
Add-AvailabilityAddressspace -Forestname Contoso.com -Accessmethod OrgWideFB -Credential:$a


From Microsoft Technet : http://technet.microsoft.com/en-us/library/bb125182(v=exchg.150).aspx
from Blog :http://blogs.technet.com/b/ucedsg/archive/2010/04/22/how-does-federated-calendar-sharing-work-in-exchange-2010.aspx
Four things needed to get you started:
1) Obtain a X.509 certificate from a Trusted Root CA (GoDaddy, Entrust, etc) for use with Microsoft Federation Gateway (MFG) for signing and encrypting delegation tokens.  (more here). Here is a list of Trusted Root CAs that MFG is aware of here.
2) Create a Federation Trust using cmdlet with the MFG (more here):
New-FederationTrust
3) Provide domain ownership by creating a DNS TXT record similar to (more here):
Contoso.com IN TXT AppId = 1C2
4) Add your SMTP domains (other Exchange Orgs) and add Federated domains to trust calendar information with (other org must accept) using cmdlet (more here):
Set-FederatedOrganizationIdentifier  - to enable your SMTP domains for federation sharing with the MFG
Add-FederatedDomain – to add other External Orgs to share calendar information with