Hi,

• The management pack monitors if the login is successful and validates that the subscription is up and healthy.
• The management pack pulls out services that the subscription is consuming from the services status API and shows state. It pulls out the services that a subscription is consuming and any active issues associated with it (these do not have OM state).

So I would like to suggest you make sure your subscription is up and healthy.

Regards,

Yan Li

I couldn't get our O365 MP to connect with our new monitoring account either (but worked fine with my admin account) and think what fixed it for me was logging in once to O365 with the new monitoring account and changing the password as it was needing to be changed on first login. Everything went green soon after.

• Proposed as answer by John Joyner - MVPMVP, Moderator Wednesday, August 06, 2014 2:02 PM

I got " Connection to EndPoint Service failed" error when i look from health explorer. Looks API Endpoint Issue  pack " https://office365servicehealthcommunications.cloudapp.net/shdtenantcommunications.svc.

is there any ports needs to be open or alllow this URL on proxy.

I got " Connection to EndPoint Service failed" error when i look from health explorer. Looks API Endpoint Issue  pack " https://office365servicehealthcommunications.cloudapp.net/shdtenantcommunications.svc.

is there any ports needs to be open or alllow this URL on proxy.

I am also getting the Connection to EndPoint service failed error. We changed the password of the service account, and verified we could login via O365. 

I'm not sure it's a firewall issue - that URL (https://office365servicehealthcommunications.cloudapp.net/shdtenantcommunications.svc) is reachable from the SCOM server. It just lands at a generic page which says EndPoint not found.

Interestingly if I go back into the Office 365 Panel, then edit the service account - the username and password is blank. I don't know if that means it's not stored at all, or if it assumes you are resetting the account..

Hi,

It's the correct page response "EndPoint not found", if you try to access the  https://office365servicehealthcommunications.cloudapp.net/shdtenantcommunications.svc page.

The blank username and passwords are Ok as well, but be careful to edit your credentials from the subscription page, as they are not changed in this case in the Office365 Run As Account, looks like a bug. Therefore, edit them only through the Accounts menu, or create a new subscription.

The management pack communicates exactly to the mentioned above page only, it's not possible to use IPs, as they could be changed at MS servers side. The host should be whitelisted in case if you have firewalls\proxy. At the same time, depending on your network\proxy\subscription configurations, possible issues could exist because of certificates and authorization at different levels.

In case of proxy - the Office 365 Proxy Run As Account should be configured. It's automatically created during installation of MP, but the account with Internet access should be added there. Take in attention that using the Office365 Run As Account does not work out. Therefore the separate Windows account should be created and used as the Office 365 Proxy Run As Account, even if it's the same as the Office365 Run As Account. When using the proxy account, one of the Monitoringhost.exe processes works under this account. If the proxy account is not configured, this process works under the system account. The proxy account was not documented in Office365 MP manual.

Don't change the default name of created Office 365 Run As accounts, somehow it affects the connection monitor.

Hope it helps :)

Hi,

It's the correct page response "EndPoint not found", if you try to access the  https://office365servicehealthcommunications.cloudapp.net/shdtenantcommunications.svc page.

The blank username and passwords are Ok as well, but be careful to edit your credentials from the subscription page, as they are not changed in this case in the Office365 Run As Account, looks like a bug. Therefore, edit them only through the Accounts menu, or create a new subscription.

The management pack communicates exactly to the mentioned above page only, it's not possible to use IPs, as they could be changed at MS servers side. The host should be whitelisted in case if you have firewalls\proxy. At the same time, depending on your network\proxy\subscription configurations, possible issues could exist because of certificates and authorization at different levels.

In case of proxy - the Office 365 Proxy Run As Account should be configured. It's automatically created during installation of MP, but the account with Internet access should be added there. Take in attention that using the Office365 Run As Account does not work out. Therefore the separate Windows account should be created and used as the Office 365 Proxy Run As Account, even if it's the same as the Office365 Run As Account. When using the proxy account, one of the Monitoringhost.exe processes works under this account. If the proxy account is not configured, this process works under the system account. The proxy account was not documented in Office365 MP manual.

Don't change the default name of created Office 365 Run As accounts, somehow it affects the connection monitor.

Hope it helps :)

Hi Dug from U,

From my best knowledge and plays with Office365 MP, under Run as Configuration\Accounts it should be 2 accounts - one Basic "Office 365 Run As Account_xxxxx" and one is Windows account, which you can name as you want, and it's AD based, as you mentioned.

Under Run as Configuration\Profiles there are 2 profiles created by Office365 MP:

The first one has added "Office 365 Run As Account_xxxxx" account inside. The second one should have your created new Windows account added. Hope it's more clear now. :)

If it does not work out for you - just play with settings, as there are no documentation for that. Monitor processes and network traffic if needed to find a bottleneck, which could be different for your network (firewalls, certificates and their replacement, whitelists, proxy settings - including IE proxy settings and their importing to system level). Good luck!

Ok, it's still not working - but I'm getting closer. I configured the service account under the Proxy secure reference profile. I can now see an additional MonitoringHost.exe running as that user. 

However when I look at a packet capture, I see that it's only trying the remote Microsoft address (at time of writing resolves to 65.52.193.76) and not the proxy address. This is even though my Management Server is configured to use the proxy, and even "netsh winhttp show proxy" reveals the correct server. (and using the MP catalog works properly)

Does the MP itself need to be configured in some way to force it to use the proxy?

Hi Dug,

Try to configure proxy settings in IE for the "proxy" account\login.

As well, you can try "netsh winhttp import proxy source=ie" command

Hi Natalya,

I'm getting closer! I logged in with the AD service account to the SCOM box and did both the IE proxy setting and the netsh command you mentioned. I'm now seeing entries under Active Incidents, Resolved Incidents, and Message Center.

However I don't see anything under Service Status. For the profile Office 365 Subscription Proxy secure account, I'm using the "more secure" method and distributing to the Office 365 Subscription Class *object*. Do I need to distribute it to more than that one object, such as the other Office 365 classes?

Thanks!

Dug

Can I just ask again about the proxy account. Does this windows account need to be able to access 365? Or just be an AD account to auth against the proxy?

Thanks

Can I just ask again about the proxy account. Does this windows account need to be able to access 365? Or just be an AD account to auth against the proxy?

Thanks

Hi Dug,

It should be working with that Office365 object. As a troubleshooting step you can try to play with distribution to different objects\classes.

Hi CCBOYNO,

Hope this post helps you:

http://mytechnat.blogspot.ca/2014/10/notes-for-office-365-management-pack.html

It looks like a bug in this MP, when a connection shows healthy with some settings, but not generating the requests towards O365 URL, also described into the post above.

Thank you Natalya

I have now created a new resource pool and added only the one MS server. I can see a monitoringhost.exe under the proxy AD account being used.

My environment does not use a proxy server and the "netsh winhttp show proxy" and "netsh winhttp import proxy source=ie" returns "Direct access (no proxy server)."

However if I leave the proxy Run As Profile blank. I get a connection error. If I add the O365 Run As account to the proxy profile it stays healthy. But from your blog. That is a bug. In the past I had a AD account Run as account for the Proxy Run As Profile which stayed healthy. But now turns critical. Under Health explorer my the cause is "Status error"

The one last trouble shooting issue I am yet to resolve is that all cookies are banned on the server. Not enabling me to test the connect via IE on the SCOM server.

now cannot

OK after more investigation today. My network does use a proxy server. I have enabled this proxy on the MS servers and the servers now have internet access. I have tested this by using the online MP cat and downloaded a MP. I have also added the service status webpage as a view and connected fine.

I have configured a domain account that is also local admin on the SCOM server as the Proxy Run As account/Profile

I still have the API connection issue message displayed. I have removed the subscription and recreated and rebooted all servers etc. The event log still does not show any issues towards the connection.

Just to clarify. I have the O365 login (Global Admin) as a basic Run As account. The account is distributed to the all management resource pool

This account is configured in Run As Profile Office 365 Subscription Password secure reference and set target of Object that is set at creation of the subscription

I have an AD account configured as a Windows Run As account that is distributed to all management resource pool

This Run as account is configured in the Office 365 Subscription Proxy secure reference and targets the subscription object.

Do I need to place a windows account in the Run As Profile Office 365 Subscription Password secure reference?

Finally got it working. After all that. Discovered the Proxy Server was using a PAC. I had to have a rule to allow the SCOM servers not to require Authentication on the proxy server.

Thanks, hope it helps someone else

• Marked as answer by Yan Li_Microsoft contingent staff, Moderator Wednesday, October 22, 2014 2:09 AM

To be precise: Run As account mapped to Office 365 Subscription Proxy secure reference Run As profile should be:

1. Domain user

2. Should be able to access o365 API end point (https) - required for data collection

3. Should have access to SCOM SDK API (i.e. should be a member of "Operations Manager Operator" SCOM role) - required for alert autoclose rule.

Hi Dug,

Question in the Office 365 Subscription Proxy secure account - did you distribute to more objects / classes to make it work. ?

/stefan

Thanks for info

Regards,

Enis

Hi Dug,

Question in the Office 365 Subscription Proxy secure account - did you distribute to more objects / classes to make it work. ?

/stefan

Hi Stefan,

I never got it fully working - I didn't see any objects other than the alerts, and later the overall status went back to red. I ended up removing the MP, I'll wait to see if it gets updated. 

I'm having a similar issue I think. The subscription health shows up with a Red X (unhealthy.)  My SCOM server is on a private network so requires a proxy to get out to the Internet. The account I have specified in the Office 365 Subscription Proxy secure reference Profile was able to get to office365servicehealthcommunications.cloudapp.net/shdtenantcommunications.svc in Internet Explorer from the server.  The subscription health shows up as unhealthy and the only way I have been able to get it to show up as healthy is having the proxy account log into Windows.  After it logs in, the subscription health goes healthy within 30-45 minutes.  After a restart (whether it be for testing or after patching) the subscription health goes to unhealthy and stays that way for hours or days... until I log into windows with the proxy account.  We use TMG as the proxy, and everything is configured correctly, as it works when the proxy user is actually logged in.  I have started logging on TMG and verified that the hours/days when the proxy user is not logged into Windows there is no attempt to go out to office365servicehealthcommunications.cloudapp.net/shdtenantcommunications.svc, but after I log in with the account I see it in the TMG logs and the monitor turns green.   I have posted a new topic to TechNet forums specific for this issue.  I have posted a new topic to TechNet forums specific for this issue.