MOSS-Exchange

In a SQL 2014 Availability Group, all the databases on the secondary replica were showing Not Synchronizing. All the tricks to resume synchronizing failed. I tried to add another database and synchronize that one. It failed. The root cause was the DNS record for the SQL server disappeared. Solution was ipconfig /registerdns from an elevated command prompt.

My Office Web Apps (Office Online Server--OOS--in my case) server stopped rendering Office Docs with an error: Sorry, there was a problem and we can't open this document. If this happens again, try opening the document in Microsoft Word. The error also included a session ID. I was able to find the session ID in the ULS logs but it didn't seem to help as the error was quite generic. I had a load balanced pair. It made troubleshooting less than ideal. Nothing I did to try and resolve it made any difference. Configuring OOS or reconfiguring is really super simple and requires only a few minutes of downtime. It's so quick to rebuild OOS or OWA by following these steps in this link: https://blogs.technet.microsoft.com/office_web_apps_server_2013_support_blog/2013/12/20/office-web-apps-2013-rebuild-your-farm-in-a-few-easy-steps/ Open PowerShell and let's fix it! Remove-OfficeWebAppsMachine on both OOS servers. Reboot after the command completes. Next I ran this ...

My Search service paused for External Request, In Central Admin Search Administration page in Administrative Status it read "paused for External Request" I tried all the tricks to get it to resume, but it was because the search service was stuck on starting. Running this STSADM command jarred it loose: stsadm -o provisionservice -action start -servicename osearch15 -servicetype "Microsoft.Office.Server.Search.Administration.SearchService, Microsoft.Office.Server.Search, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

I got a report of People search failing in SharePoint. Sure enough, every one of my environments (dev/test/sandboxes/prod) exhibited an issue in the event log ID 1314: The start address sps3s://myserver:8080 cannot be crawled. Context: Application 'Search_Service_Application', Catalog 'Portal_Content' Details: Class not registered (0x80040154) It turns out Microsoft released a .NET patch in July 2018 that introduced this issue. I failed to test people searching when passing this patch through my environments! You can find the fix here: https://support.microsoft.com/en-ae/help/4345913/access-denied-errors-after-installing-july-2018-security-rollup-update

I have a multiple condition approval SharePoint Designer workflow that was giving an error when users tried to open the task in Outlook: Outlook cannot open a new form. To open the file, access to the following form template is required: <<path to InfoPath approval form>> I tracked down an error in the ULS logs: Unhandled exception thrown while handling resource page request for /sites/path rosoft.Office.InfoPath.Server.Util.InfoPathLocalizedException: The following location is in a different site collection : path/Approval_x0028_4_x0029_.xsn. Access to locations on different site collections is blocked for security reasons. For more information, contact your site administrator. at Microsoft.Office.InfoPath.Server.Controls.ResourcePage.HandleTemplateFile(HttpContext context) at Microsoft.Office.InfoPath.Server.Controls.ResourcePage.<>c__DisplayClass2.<ProcessRequestInternal>b__0() at Microsoft.Office.Server.Diagnostics.FirstChanceHan...

I was trying to update some settings on a SharePoint site where I was a Site Collection Administrator. I could read everything but could make no updates! What is going on? The site was locked as read-only. You can access "quotas and locks" in Central Admin for on-premise or use PowerShell.

I had to retire an old SharePoint 2013 on-premise farm following a successful migration project. Since this wasn't a wholesale migration, there was a small level of uncertainty whether we moved all the relevant content over. I removed locked all the sites in the farm as read-only and parsed the IIS logs to monitor access. When I was satisfied that I had redirected all the users to the new locations, I removed access to all sites and will leave it like that for a couple months before retiring the servers. This works much better than shutting down the servers. If you've ever had to turn on a server that has been offline for an extended period you have no doubt experienced domain membership issues, patching compliance issues, outdated anti-virus signatures, etc. If someone needs access to content in their My Site or something, I can unlock it by using the PowerShell command: set-spsite -identity https://mysite/username -LockState "Unlock" Unlock all sites in a f...