Office 365

Office 365: Self Service of Distribution Groups

The ability to self service the creation of distributions groups has been a feature for quite some time in my Exchange experiences.  Now that I am in Office 365 / Exchange Online this functionally is no longer available for synced groups. This now forces the enlistment of the support department to facilitate all mortification for the end user.

Looking into this to get an understanding as to why this is, I’ve learned that if you’re an Office 365 Exchange Online customer and currently utilizing Directory Synchronization (DirSync) between an on-premise Active Directory and Office 365’s Azure Active Directory you will face such incidents as the objects on the Office 365 are in read only mode and are updated via the synchronization that has been put in place

You are even given a a little message when you attempt to make modification to groups:  The action ‘Update-DistributionGroupMember’, ‘Identity,Members’, can’t be performed on the object ‘Group Name’ because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

Now aware of this limitation that exist around group modification due to them being read only how do I work like this? I have the following two ideas to work with.

One: 

One method is to go old school and use the Use the ‘Find Users, Contacts and Groups’ tool to allow group modification. However there is an issue regarding the fact that the computer used needs to be a member of the domain and at the time of change also connected to the on premise domain network (internal or via vpn).

Note: After changes have been made the condition of waiting for Directory Synchronization (DirSync) to complete its sync cycle must take place.  This can take up to 3 hours time.

 

Two:

The Second method is to change all Directory Synchronization (DirSync) Distribution Group Objects to the Azure Active Directory and make the On-Clound

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