Well, I started by running the following power shell script but this does the job only for Content Databases apparently.
$snapin = Get-PSSnapin | Where-Object {$_.Name -eq
'Microsoft.SharePoint.Powershell'}
if ($snapin -eq $null) {
Write-Host "Loading SharePoint Powershell Snapin"
Add-PSSnapin "Microsoft.SharePoint.Powershell"
}
Get-SPDatabase | Where{$_.Exists -eq $false} | ForEach {$_.Delete()}
Got this error
Exception calling "Delete" with "0" argument(s): "An object in the SharePoint a
dministrative framework, "WebAnalyticsWarehouseDatabase Name=WebAnalyticsServiceApplication_ReportingDB", could not be deleted because other objects depend on it. Update all of these dependants to point to null or different objects and retry this operation. The dependant objec
ts are as follows: WebAnalyticsServiceApplication Name=Web Analytics Service Application"
There was some suggestion to delete the GUID from the configuration database using this but that leaves your environment in unsupportable state as this command has to be executed under the guidance / by MS Support Engineers some say so
Get-spdatabase |fl > C:\SPDatabase.txt
stsadm -o deleteconfigurationobject -id *GUID*
I didn't want to leave the environment in unstable state I think no one does :).
For me the ultimate resolution was to delete the Web Analytics Service Application without the staging and reporting databases. I did disable the timer jobs before deleting the Web Analytics Service Application without the databases.
Health Analysis Job (Daily, Web Analytics Data Processing Service, Any Server)
Health Analysis Job (Daily, Web Analytics Web Service, Any Server)
Microsoft SharePoint Foundation Usage Data Processing
Microsoft SharePoint Foundation Usage Data Import
Microsoft SharePoint Foundation Site Inventory Usage Collection
Issue resolved. This worked for me in my environment.
Now re-created the Web Analytics Service Application and associated the same with the old Web Analytics Staging and Reporting databases. I think the best way is to troubleshoot issues like this is sometimes you have to do things clean in fact more often.
$snapin = Get-PSSnapin | Where-Object {$_.Name -eq
'Microsoft.SharePoint.Powershell'}
if ($snapin -eq $null) {
Write-Host "Loading SharePoint Powershell Snapin"
Add-PSSnapin "Microsoft.SharePoint.Powershell"
}
Get-SPDatabase | Where{$_.Exists -eq $false} | ForEach {$_.Delete()}
Got this error
Exception calling "Delete" with "0" argument(s): "An object in the SharePoint a
dministrative framework, "WebAnalyticsWarehouseDatabase Name=WebAnalyticsServiceApplication_ReportingDB", could not be deleted because other objects depend on it. Update all of these dependants to point to null or different objects and retry this operation. The dependant objec
ts are as follows: WebAnalyticsServiceApplication Name=Web Analytics Service Application"
There was some suggestion to delete the GUID from the configuration database using this but that leaves your environment in unsupportable state as this command has to be executed under the guidance / by MS Support Engineers some say so
Get-spdatabase |fl > C:\SPDatabase.txt
stsadm -o deleteconfigurationobject -id *GUID*
I didn't want to leave the environment in unstable state I think no one does :).
For me the ultimate resolution was to delete the Web Analytics Service Application without the staging and reporting databases. I did disable the timer jobs before deleting the Web Analytics Service Application without the databases.
Health Analysis Job (Daily, Web Analytics Data Processing Service, Any Server)
Health Analysis Job (Daily, Web Analytics Web Service, Any Server)
Microsoft SharePoint Foundation Usage Data Processing
Microsoft SharePoint Foundation Usage Data Import
Microsoft SharePoint Foundation Site Inventory Usage Collection
Issue resolved. This worked for me in my environment.
Now re-created the Web Analytics Service Application and associated the same with the old Web Analytics Staging and Reporting databases. I think the best way is to troubleshoot issues like this is sometimes you have to do things clean in fact more often.
No comments:
Post a Comment