Hide from Address Book in Office 365

We are implementing more and more Office 365 infrastructures for our customers and we had some requests to hide users from Address Book. This should be an easy task, as stated in Microsoft as stated in this TechNet article http://technet.microsoft.com/en-us/exchangelabshelp/gg410928.

If you have an infrastructure where you have implemented ADFS when you run the command:

Set-Mailbox "Mailbox Name" -HiddenFromAddressListsEnabled $true

You will get an error like:

PS C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Online Service s] Set-Mailbox "Mailbox Name" -HiddenFromAddressListsEnabled $true
The operation on mailbox "Mailbox Name" failed because it's out of the current user's write scope. The action 'Set-Mailbox', 'HiddenFromAddressListsEnabled', can't be performed on the object 'Mailbox Name' because the object is being synchronized from your on-premises organization. This action should be performed on th e object in your on-premises organization

If you have an local Exchange installation this task is easy, but if you don't you will notice quick that there is no place to step the required flag.

So, what is the solution? It’s simple, if you follow this procedure:

1. Download Exchange 2010 SP2 from Microsoft web site;
2. Extract it to a folder on a local machine running Windows 2008  (x64) or 2008 R2;
3. Run setup /prepareAD to extend your schema for Exchange 2010. It might be possible that you need to install some features in Windows to be able to run the setup;
4. Using ADSI Editor find the account that you need to hide and set to true the msExchHideFromAddressLists to true (see the picture);












5. Sync the local AD with Office 365.

If you want to revert the Hide from Address Book setting, you have to set the attribute to “Not set”

Exchange 2010 DAG transaction logs are not truncated after VSS Full backup

A couple of months ago we implemented for a customer a hosting solution based on Exchange 2010. The solution has full redundancy for all components including a DAG with geographical redundancy.
Everything was configured accordingly to Microsoft recommendations and worked without any problems.

We configured Windows Server Backup to perform backups using a DAG member that was hosting only active databases. This means that we didn't have to do the Registry modifications as mentioned in TechNet (http://technet.microsoft.com/en-us/library/dd876851.aspx).
The backup was successful but not logs were deleted from the log's folder. In the Event Viewer the only relevant record was:

Information Store (2672) DB1: No log files can be truncated.

Exchange VSS Writer (instance acedea2e-c785-3e33-8257-ac38405e81af:5) has successfully completed the full or incremental backup of replicated database 'DB1'. The log files will be truncated after they have been replayed.

We tried to find a solution and nothing worked and we had to give up for a while in using DAG replication. Microsoft support has extensively investigated the issue for more than two months without success. In the end their suggestion was that between the geographically dispersed members of the DAG there was something that was blocking the traffic.

We discussed with the network infrastructure admin and all the ports seems to be open. The only thing that could block the communication was a Network Intrusion Detection System. This system was blocking SUNRPC and DCERPC protocols. After we disabled this protection and run the backup, all database logs were truncated.

If you encounter this issue, try to disable everything that could potentially block the communications between DAG members.

Unable to authenticate users in Office 365 using ADFS services

Last week we migrated one of our clients to Office 365 including the configuration of ADFS services in order to authenticate the users using local Active Directory credentials. Everything worked as expected for a couple of days until one morning when nobody could authenticate to the service.
We investigated the ADFS server and we found out that the AD FS 2.0 Windows Service was stopped.
We tried to start it without success. At a deeper inspection we discovered that the account that should be used for running this account was deleted from AD.
We created a new account, assigned all the appropriate rights and we managed to start the service. At this point, the external users that were authenticated using the ADFS Proxy server were able to login to the Office 365 services but the internal users were unable to do so.
In the AD FS 2.0/Admin event viewer log there were a lot of events like:

Log Name: AD FS 2.0/AdminSource: AD FS 2.0
Date:          11/8/2011 10:15:12 AM
Event ID: 323Task Category: None
Level: ErrorKeywords: AD FS
User: DOMAIN\ServiceAccount
Computer:     COMPUTER.domain.com
Description:
The Federation Service could not authorize token issuance for the caller 'DOMAIN\ServiceAccount' on behalf of the subject 'user@domain.com
' to the relying party 'urn:federation:MicrosoftOnline'. Please see event 501 with the same instance id for caller identity. Please see event 502 with the same instance id for OnBehalfOf identity, if any.
Additional Data
Instance id: 2ae34f5b-dc27-3ed1-af21-976e28a4e3f5
Exception details:
Microsoft.IdentityServer.Service.IssuancePipeline.OnBehalfOfAuthorizationException: MSIS5009: The impersonation authorization failed for caller identity and delegate for relying party trust https://claimapp1.treyresearch.net. at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.ProcessCoreAsyncResult.End(IAsyncResult ar)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.EndProcessCore(IAsyncResult ar, String requestAction, String responseAction, String trustNamespace)
User Action
Use Windows PowerShell comments for AD FS 2.0 to ensure that the caller is authorized on behalf of the subject to the relying party.

Log Name: AD FS 2.0/AdminSource: AD FS 2.0
Date:          11/8/2011 10:11:02 AM
Event ID: 364Task Category: None
Level: ErrorKeywords: AD FS
User: DOMAIN\ServiceAccount
Computer: COMPUTER.domain.com
Description:
Encountered error during federation passive request.
Additional Data
Exception details:
Microsoft.IdentityServer.Web.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. ---> System.ServiceModel.FaultException: MSIS3126: Access denied. at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClientManager.Issue(Message request, WCFResponseData responseData)
at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst, WCFResponseData responseData)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
--- End of inner exception stack trace ---
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, Uri& replyTo)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, MSISSession& session)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseCoreWithSerializedToken(String signOnToken, WSFederationMessage incomingMessage)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseForProtocolResponse(FederationPassiveContext federationPassiveContext)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponse(SecurityToken securityToken)
System.ServiceModel.FaultException: MSIS3126: Access denied. at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClientManager.Issue(Message request, WCFResponseData responseData)
at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst, WCFResponseData responseData)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)

There were also a lot of events 501 and 502.
We searched the internet for a solution and all we've found was http://social.technet.microsoft.com/wiki/contents/articles/2265.aspx which unfortunately did not work.
The only possible solution that came out was to disable the federation between Office 365 and internal AD infrastructure and re-enable it using a new service account for the AD FS service. To do that we had to follow the procedure:

1. Use PowerShell command Convert-MsolDomainToStandard to convert specified domain from single sign-on  to standard authentication.

If you didn't install the Office 365 cmdlets please follow the instructions from this blog post http://paulroman.pras.ro/2011/11/unable-to-sign-in-to-office-365-with-ad.html.

Run the following commands to disable single sign-on:

$cred = Get-Credential
Connect-MsolService -cred $cred         
convert-MsolDomainToStandard –DomainName domain.com –passwordfile password.txt –SkipUserConversion $false

This will generate temporary passwords for all the users and save them to the password.txt file.

2. Uninstall all ADFS and ADFS Proxy services from all the servers that were members in this process.

3. Following the Microsoft Procedure from http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh125004.aspx reconfigure the ADFS integration with Office 365.

In no more than half an hour the ADFS service was functional again and all the users were able to access Office 365 from internal or external network.