After de-commissioning some SharePoint servers, you might notice the above error on the remaining WFEs /Application server’s event viewer. There will be quite a few of them. This happens because SharePoint still has a reference to the removed servers’ URI endpoint. The event viewer error message will contain a message beginning with:
An exception occurred while updating addresses for connected app {6783ce5e-c88h-4021-8d5b-12614875cbfa_b79f19ab-1d40-4824-9911-3466cf8b070a}.
Verify if this is in fact what’s going on with your farm!
Open SSMS and run the following query against your Config database:
SELECT ID, Properties
FROM [Objects]
WHERE Name LIKE ‘%6783ce5e-c88h-4021-8d5b-12614875cbfa_b79f19ab-1d40-4824-9911-3466cf8b070a%’
That guid in the where clause is from the error message in event viewer.
Have a look under the Properties result from the query. Check to see if it is making a reference to the server you removed. If it is note the ID in the resultset and open an administrators cmd or posh window and run:
STSADM -o deleteconfigurationobject -id
When you return to Event viewer the messages will have stopped.
Category: SharePoint
Posts related to Microsoft SharePoint
Microsoft.Office.RecordsManagement.Preservation.PreservationJobDefinition
The event description for Event ID 6398 is:
The Execute method of job definition Microsoft.Office.RecordsManagement.Preservation.PreservationJobDefinition (ID a71c3cb6-21e0-46fd-91b5-9d9f0c2170e7) threw an exception. More information is included below.
The search request was unable to connect to the Search Service.
This error shows up in the Application log from the SharePoint Foundation source and typically appears if you don’t have Search running on your SharePoint farm. This is because there is timer job eDiscovery In-Place Hold Processing that runs hourly and leverages the Search Service to do its work. eDiscovery In-Place discovery has been retired and as of July 1, 2020 no new eDiscovery searches can be created in Online only SharePoint installations.
In order to keep this error from showing up simply navigate to Monitoring, click on “Review Job Definition” and disable the above named timer job.
DetachDatabase
This is a brief guide on completely removing a SharePoint 2013 on-premises site from a farm which is using Nintex Workflow. I have used this method successfully in our Test environment. For this to work for you, you will need to be a farm administrator with RDP access to a farm server as well as to central administration. This could also be done in PowerShell. I rarely need to do this and the process isn’t too complicated or time consuming as is so I’ve not scripted it yet.
Before you start consider if there is anything that you’ve been wanting to try out but have held off from doing so because of concerns about unintended side effects of those actions. This might be a good time to do that and then follow the steps below. Once you’ve notified the stakeholders, if any, of your intention to remove the site and you’ve gotten the all clear, head to Central Administration –> Application Management –> Delete a site collection and remove the site collection.
Once deleted go to Application Management –> Databases –> Manage Content Databases. Find the database name and be sure there is a zero in the Current Number of Site Collections column. If there is any positive number there then you obviously don’t want to delete this database. For security purposes I have a 1-to-1 mapping of sites to content databases, both Nintex and SharePoint. After verifying there’s no site collections in the site, click the name of the content database you want to remove and on ‘Manage Database Settings’ page, check the ‘Remove Content Database’ checkbox, dismiss the warning and click OK. The database is detached from the Farm.
Now click ‘Nintex Workflow Management’ in the Quick Launch navigation menu and then click on ‘Database Setup’. Notice that the DB you just detached from the SharePoint farm is still showing up in the list of content databases. If you visit the ‘View Database Mappings’ or ‘Manage Database Mappings’ link at the bottom of that page, both pages will not have a listing for the site you’ve removed. So the purge isn’t really complete. If your intention is to dismount the database from the SQL Server instance so that it’s no longer backed up or to just to keep things logical and clean, you’ll want to be sure it is completely purged from the SharePoint/Nintex ecosystem. You can also deactivate and reactivate the “Nintex Workflow” feature at the site collection level to force Nintex to remap your databases, but this isn’t always possible, even in a test farm.
Go ahead and open the configuration DB for Nintex. The ‘Databases’ table inside of your Nintex config DB still has a listing for the removed site. There is also an entry for it in the ‘Storage’ and ‘ContentDbMapping’ tables. You’ll want these to be gone too. If you do not have RDP access to the SharePoint app server you can use the method above to complete the purge. Otherwise RDP to your SharePoint server. In a multi-server farm configuration I run all commands on an App server rather than a WFE. Run the following:
nwadmin -o DetachDatabase -serverName <server or Alias name> -databaseName <Nintex COntent DB Name>
When I ran this on my test farm I got the following output:
de77705b-f3f6-48b6-9a88-32fbe559855a |Unable to access, site collection may no longer be present.
Content database ‘Nintex_Sen’ is in use. Detaching it will cause workflow history to be lost and workflows in site collections associated with this database to fail.
Are you sure you want to detach this database? (yes / no)
This was a test farm. The first message was obvious since I did in fact remove the site. It likely had workflows running or orphaned workflows that appeared to be running to Nintex. I answered ‘yes’ and the ‘Operation Completed’.
Returning to the Central Admin pages I now saw that on /_admin/NintexWorkflow/DatabaseSettingsView.aspx there was no listing for the content database. It was purged. I went ahead and deleted both the SharePoint and the Nintex DBs from SSMS .
There are other ways to do this and this may not even be the best way but my intention in posting is to shed some light on an NWAdmin command so I hope you found it helpful.