locked
Office 365 Monitoring using SCOM 2012 R2 RRS feed

Answers

  • 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_ Wednesday, October 22, 2014 2:09 AM
    Friday, October 10, 2014 3:41 PM

All replies

  • Verify from following:

    1. Firewall disable
    2. Antivirus disable then try again

    Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question, please click "Mark As Answer" Mai Ali | My blog: Technical | Twitter: Mai Ali

    Friday, August 1, 2014 6:12 PM
  • Hi Sengo,

    According to description of the Office Connection State monitor from MP, these alerts are generated in case of network problems or unavailable Office 365 API with causes:

    Causes

    An error state is   caused by having issues with connecting to O365 API EndPoint. It can be   caused by:

    -            Issues with global connection to O365 API EndPoint

    -            Credentials for O365 Subscription's account are not correct

    -            Office 365 Subscription's account is not allowed to getting data from O365 EndPoint API


    Natalya

    Monday, August 4, 2014 12:08 AM
  • 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


    Regards, Yan Li

    Monday, August 4, 2014 8:03 AM
  • 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.

    Wednesday, August 6, 2014 10:05 AM
  • 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.

    Thursday, August 7, 2014 8:04 AM
  • 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 have the same issue and the same question. For this MP you create a Resource Pool and add servers to that Pool. Our servers sit behind a Cisco ASA Firewall. I am also having connection problems. So my question is what ports must be open for the servers in the resource pool to be able to connect to the office API's and what is the destination IP or IP ranges. As the FW team will only allow IP source and specific port or ports to IP destination. What ports must be open??? Please.
    Friday, September 12, 2014 7:34 AM
  • 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..

    Thursday, September 18, 2014 7:55 PM
  • 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 :)


    Natalya

    Wednesday, October 1, 2014 3:03 AM
  • 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 :)


    Natalya

    Hi Natalya,

    Thanks for this post. Indeed my SCOM server is behind a proxy. Let's say my Office 365 account is called "SCOM.O365" - it appears under Administration - Accounts under Basic Authentication, with the "friendly" name of "Office 365 Run As Account_xxxxx". Do you mean I create a second account under "Windows" (it would be Active Directory based) also called "SCOM.O365" that the MP will use for proxy, and the MP will automatically run MonitoringHost.exe with this AD account? 

    thanks!


    Wednesday, October 1, 2014 12:28 PM
  • 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!


    Natalya

    Thursday, October 2, 2014 3:42 AM
  • 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?

    Thursday, October 2, 2014 7:01 PM
  • 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


    Natalya

    Friday, October 3, 2014 1:56 AM
  • 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

    Monday, October 6, 2014 2:40 PM
  • 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

    Tuesday, October 7, 2014 5:30 PM
  • 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

    It only needs to access the proxy, the O365 account I'm using is independent of the AD account. 
    Tuesday, October 7, 2014 5:34 PM
  • 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.


    Natalya

    Tuesday, October 7, 2014 9:55 PM
  • Is there a way of testing the API to O365 is working correctly? The connection is healthy. But yet none of the other widgets in the dashboard are displaying. No errors in the eventlog or SCOM itself.
    Wednesday, October 8, 2014 9:01 AM
  • 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.


    Natalya

    Thursday, October 9, 2014 11:52 PM
  • 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

    Friday, October 10, 2014 9:47 AM
  • 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?

    Friday, October 10, 2014 12:48 PM
  • 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_ Wednesday, October 22, 2014 2:09 AM
    Friday, October 10, 2014 3:41 PM
  • 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.


    Oleg Kapustin - blog: http://ok-sandbox.com

    Thursday, October 16, 2014 11:38 PM
  • Hi Dug,

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

    /stefan

    Thursday, November 27, 2014 11:53 PM
  • Hi Natalya, I have you seen error related to MonitoringHost.exe doesn´t kick off and start properly under the Proxy account ? I have followed the advice from this thread as well, but no success so far. /J
    Friday, November 28, 2014 12:34 PM
  • Thanks for info

    Regards,

    Enis

    Saturday, November 29, 2014 10:34 PM
  • 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. 

    Monday, December 1, 2014 1:06 PM
  • Thanks for the info / Stefan
    Monday, December 1, 2014 8:48 PM
  • 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.

    Thursday, April 2, 2015 3:37 PM
  • Hello CCBOYNO,

    Could you please explain how did add a rule to allow the SCOM servers not to require Authentication on the proxy server?

    Thanks,

    Binoy

    Monday, January 18, 2016 8:47 AM