SharePoint Online URLs / Site Names Not Showing Correctly
I was looking into why we have no data through our O365 SaaS monitoring resource, and discovered that you cannot use a Linux collector to collect data from O365 because it requires powershell.
Despite not collecting any data, up until that point it had at least parsed all our SharePoint Online sites by the site URL (i.e. "https://tenant.sharepointonline.com/sites/SITENAME"). So it was easy to search for sties we cared about....and easy to look at top 10 report, etc. (except that our data was missing due to using a Linux collector).
Once I reconfigured the resource to use one of our Windows collectors it started getting data (sweet!), except now all our SharePoint Online sites are listed as GUIDs....!?!? What the heck? Do I just need to wait for this to fix itself? I did a "active discovery" as well as "force data source rematch" and no luck.
<< these used to be URLs that were easily readable/searchable.....
ricksharma
·1 year agoMaybe because of SharePoint sites migration to another tenant. Because I have encountered the similar issue when I have performed SharePoint Migration to combine two SharePoint sites. You should the settings of the site. Also cross check the name of the sites.
John_Lockie
OP4 years agoDid a little digging and found this....looks like Microsoft decided to pseudonymize user-level info starting 9/1/21. They announced this on 8/30/21 (LOL!).
https://techcommunity.microsoft.com/t5/microsoft-365-blog/privacy-changes-to-microsoft-365-usage-analytics/ba-p/2694137
John_Lockie
OP4 years agoOk - that fixed it. I think Microsoft may have changed something automatically at some point.
FIX: go to admin.microsoft.com, sign in as global admin, go Settings > Org Settings > Reports
Uncheck the box "Display concealed user, group, and site names in all reports
This fixed the names in LM as well.
John_Lockie
OP4 years agoSo yes, Microsoft has changed something. LogicMonitor is using the Reporting module in GraphAPI to "getSharePointSiteUsageDetails" which is served by the Usage Reporting data in Microsoft 365 admin center. Even that data is completely masked on purpose. I have a feelign Microsoft changed this. So now you have to explicity tell your tenant to allow this type of data to be visible within reports. Info here: https://docs.microsoft.com/en-US/microsoft-365/admin/activity-reports/activity-reports?view=o365-worldwide#show-user-details-in-the-reports
I am trying this now and will report back....
John_Lockie
OP4 years agoYeah I spoke to support today - this is very much not good. Makes the entire monitoring tool for SharePoint useless.
Support said: "This is the response we see from Microsoft showing the GUID as the name rather than the site. We pull this data from a CSV generated within the O365 environment, so if the names in that CSV are the GUIDs we would expect them to show up here as GUIDs"
What's very interesting is that it used to work just fine. Initially we were able to poll the data, and then we accidently changed collectors to use one of our Linux collectors and didn't realize that broke it. We set the collector back and then it suddenly updated all our sharepoint sites with these GUIDs ?
Mike Moniz
·4 years agoActually we use that DataSource too and I see the same issue. So I looked at the code and it's just calling the getSharePointSiteUsageDetail (7 day) GraphAPI and retrieving some raw CSV data. The report data looks screwed up to me though. Like all the Site IDs are "00000000-0000-0000-0000-000000000000" and the URLs, Owner Display Name and Owner Principal Name are long HEX codes. I don't have admin to O365 to check directly but I'm wondering if something is broken in the report and how long it's been like that.
Mike Moniz
·4 years agoAs a general troubleshooting test I suggest you look at the DataSource (Office365_Reports_SharepointOnlineSiteUsage) in Settings > LogicModules > DataSources, then use the Test Active Discovery button. Check what it shows for instances there and if the names look correct. If it shows correctly there then I would just delete all the instances then get Active Discovery to rebuild it. Note that this will cause you to lose any historical data for sharepoint site usage, but since it sounds like it never worked until just now, so I assume that is ok to do. If the test still shows GUIDs then you might need to dig into the powershell code or work with LM support if it's not by design.