Office 365

Office 365: EX21073 – Investigating

Incident and Reported Details

Incident ID: EX21073

Details:

Current Status: Engineers have completed developing a fix for the issue and are now testing it prior to deployment across the affected environment.

User Experience: This issue does not affect end users.

Customer Impact: Customer impact appears to be limited at this time. Affected tenant administrators are unable to view the Compliance Center page when navigating from the main Office 365 portal when using Chrome or Firefox internet browsers. As a workaround, upon encountering this issue, users may attempt to access the affected portals directly by cutting and pasting the resulting URL into a new tab or window. The affected URL is: https://compliance.protection.outlook.com/

Incident Start Time: Sunday, April 12, 2015, at 3:00 PM UTC

 

Office 365: EX20870 – Restoring service

Incident and Reported Details

Incident ID: EX20870

Details:

Current Status: Engineers have found that a portion of the affected infrastructure did not upgrade to the latest version as was intended. The remaining server capacity is now being updated. Once this is complete, engineers will run additional tests to confirm the update resolves the underlying root cause.

User Experience: Affected users are intermittently unable to connect to voicemail. When attempting to connect, users will hear silence and the call will disconnect.

Customer Impact: A few customers are reporting that they are experiencing this issue. This event is affecting customers with on-premises Edge server deployments utilizing the Exchange Online Unified Messaging (UM) feature.

Incident Start Time: Wednesday, April 1, 2015, at 8:00 PM UTC

Preliminary Root Cause: As we continue to expand Office 365 services and onboard new customers, an issue with the way the infrastructure handles connections has been revealed. Under increased load, the service performed at a suboptimal level handing connection requests, which caused increased latency and disconnects.

Tech Short: Use Dsquery tool to manage group memberships On-Prem to Office 365

 

I had mentioned in a previous post about the inability to self service groups.

Problem: on-premises distribution group is synced to a Microsoft Office 365 organization through Active Directory synchronization, migrated users who are owners of the distribution group can’t manage it in Microsoft Exchange Online

Solution: Use the Exchange Tools (But we no longer have exchange on prem?)

Solution: Use Active Directory Users and Computers

Solution: Dsquery.exe  – Press the Windows Key and R to open the run box and past in the following:

Owners of the group should be able to make changes when needed.

Note:  You will still need to wait for dirsync to complete.

kb2417592

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

 

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.

Office 365: Convert Mailbox to Shared Mailbox after Cutover Migration

When performing a cut-over migration the Exchange attribute indicating that the mailbox was a shared mailbox is lost. To correct this I have done the following steps:

List out all of the shared mailboxes form my on-premises Exchange and export them into a CSV file.

Now prepare the CSV file with the list of user principal names of all mailboxes to be converted. Make sure the column header for the user principal names is “UserPrincipalName”

Now we run the following powershell script to change the mailbox type of all items in the CSV file.

Please note

Running Exchange Online Powershell commands / scripts requires you have had installed the Microsoft Online Service Sign-In Assistant, Windows Powershell, Windows Azure Active Directory Powershell

For more info:

http://www.microsoft.com/en-us/download/details.aspx?id=41950

http://jermsmit.com/azure-active-directory-module-for-windows-powershell-how-to-connect/