Office 365

Office 365: Initiate a full password sync using DirSync

Having a need to rapidly sync passwords to Office 365 using Directly Sync (DirSync) I come across the following method that seems to work with minimal effort.  By default the DirSync only kicks off ever 3-5 min’s.

To initiate a full password sync you can do the following:

  1. Open PowerShell, and then type:

     
  2.  Then Type:

     
  3. Press Enter
  4. Load Services.msc
  5. Restart the Forefront Identity Manager Synchronization Service Service. (FIMSynchronizationService)

In your application event logs you should notices multiple events  of 656 (Password Sync Requests) and Even 657 (Password Sync Results) indicating that your full password sync has kicked off.

 

Office 365: Directory Synchronization Isssues

Yes!  In Office 365 at last and now synchronizations are failing

The followin message is shown in the forefront identity manager: stopped-server-down

And with the event id of 655 the following message is shown:

Failed credential provisioning ping.

Error: Microsoft.MetadirectoryServices.ServerDownException: Failed even after 5 retries. Action: ProvisionCredentials, Exception: Unable to communicate with the Windows Azure Active Directory service. Tracking ID: *removed for privacy*

See the event log for more details.. —> Microsoft.Online.Coexistence.ProvisionRetryException: Unable to communicate with the Windows Azure Active Directory service. Tracking ID: *removed for privacy* See the event log for more details. —>

System.ServiceModel.ServerTooBusyException: The HTTP service located at https://adminwebservice.microsoftonline.com/provisioningservice.svc is unavailable. This could be because the service is too busy or because no endpoint was found listening at the specified address. Please ensure that the address is correct and try accessing the service again later. —> System.Net.WebException: The remote server returned an error: (503) Server Unavailable.
at System.Net.HttpWebRequest.GetResponse()
at System.ServiceModel.Channels.HttpChannelFactory1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
--- End of inner exception stack trace ---

Server stack trace:
at System.ServiceModel.Channels.HttpChannelUtilities.ProcessGetResponseWebException(WebException webException, HttpWebRequest request, HttpAbortReason abortReason)
at System.ServiceModel.Channels.HttpChannelFactory
1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Microsoft.Online.Coexistence.Schema.IProvisioningWebService.ProvisionCredentials(SyncCredentialsRequest request)
at Microsoft.Online.Coexistence.ProvisionHelper.InvokeAwsAPI[T](Func1 awsOperation, String opsLabel)
--- End of inner exception stack trace ---
at Microsoft.Online.Coexistence.ProvisionHelper.CommunicationExceptionHandler(CommunicationException ex)
at Microsoft.Online.Coexistence.ProvisionHelper.InvokeAwsAPI[T](Func
1 awsOperation, String opsLabel)
at Microsoft.Azure.ActiveDirectory.Connector.ProvisioningServiceAdapter.<>c__DisplayClassb.<ProvisionCredentials>b__a()
at Microsoft.Azure.ActiveDirectory.Connector.ProvisioningServiceAdapter.ExecuteWithRetry(String actionName, Action action)
— End of inner exception stack trace —
at Microsoft.Azure.ActiveDirectory.Connector.ProvisioningServiceAdapter.ExecuteWithRetry(String actionName, Action action)
at Microsoft.Azure.ActiveDirectory.Connector.ProvisioningServiceAdapter.ProvisionCredentials(SyncCredentialsRequest request)
at Microsoft.Azure.ActiveDirectory.Connector.PasswordChangeNotificationExtension.Ping(String state)

I haven’t changed anything on our end; and from what the Office 365 dash indicates is that there are various ongoing issues.
So far; from an Administration end this hasn’t been the best of experiences.

 

Office 365: MO17808 – Service degradation

Well this may be why I’ve had issues all day

Current Status: Engineers continue to perform tests on the affected networking capacity in order to develop a plan to remediate impact.

User Experience: End users are not directly affected by this issue.

Customer Impact: Customer impact appears to be limited at this time. Any users or mailboxes that are provisioned within Exchange may not synchronize properly to the Office 365 environment. This may result in mail flow or mailbox access issues for those users after DirSync attempts to perform an Active Directory synchronization.

Incident Start Time: Saturday, March 21, 2015

Office365: Using PowerShell to get Office365 license info

Working to apply bulk apply licenses I stumbled upon some useful commands to list the licenses assigned to my Office 365 Account.

The following command will list account Sku ID’s along with the active and consumed units. Best of all list them in a nice grid view

We can also pull the subset of information such as items include with pack we have.

The following command will list included service plans under our package

 

Office 365: Cutover Migration | Lost Delegation on Mailboxes

I am posting this to help any of you who are looking to be proactive in your approach to migrate into Office 365 / Exchange Online Services.

After migrating mailboxes info Office 365, you will noticed that under your recipient’s mailbox delegation all previous access levels have been removed. In fact they never came over with the migration in the first place.

But Why?

Because during the copy of the user account and mailbox data this info is not recorded as the migration tools are not designed to copy such info (at this time) “quoting Microsoft support on this one”

Right now I am in search of a method to script out my users and then import that via power-shell. I will post / share this as soon as I have a working solution.

This post is just to inform any of you searching this out that you may also face this same issue.

 

IMHO

In my humble opinion as a professional who has been working in Office 365 / Exchange Online – You are better off configuring a Hybrid migration path over the all in one cut-over-method. While the Hybrid may take some extra learning and understanding; its the path that will ensure your data is migrated with all attributes.

Another example of things not working properly in a cut-over migration: Office 365: Convert Mailbox to Shared Mailbox after Cutover Migration

 

Again note: that not all permissions are preserved when mailboxes are moved to Office 365 using a cutover migration. For example Send As permissions on mailboxes will be lost and administrators will need to reconfigure this once users are moved across into the cloud.