Archive for category SharePoint
While running a backup on a SharePoint server, I received the error: “Error: Object SharePoint_Config failed in event OnBackup”
I was running the following STSADM script:
@REM —– BACKUP Farm —–
STSADM -o backup -directory %BACKUPFILEPATHFULL% -backupmethod full -quiet
The full error text from the spbackup file was this:
[5/18/2010 6:35:39 PM]: Verbose: Starting object: Farm.
[5/18/2010 6:35:39 PM]: Progress: [Farm] 50 percent complete.
[5/18/2010 6:35:39 PM]: Verbose: Starting object: SharePoint_Config.
[5/18/2010 6:35:40 PM]: Verbose: [SharePoint_Config] SQL Server Connection String: Data Source=sp-sql-external.sohema.com;Initial Catalog=SharePoint_Config;Integrated Security=True;Enlist=False.
[5/18/2010 6:35:40 PM]: Verbose: [SharePoint_Config] SQL command started at: 5/18/2010 6:35:40 PM. This command may take a while to complete and without notification.
[5/18/2010 6:35:40 PM]: Verbose: [SharePoint_Config] SQL Server Command: BACKUP DATABASE [SharePoint_Config] TO DISK=@db_loc WITH NAME=@db_name, STATS=5, NOINIT, NOSKIP, NOFORMAT, NOREWIND
[5/18/2010 6:35:40 PM]: Verbose: [SharePoint_Config] SQL command timeout is set to 1.00 hours.
[5/18/2010 6:35:40 PM]: Error: Object SharePoint_Config failed in event OnBackup. For more information, see the error log located in the backup directory.
SqlException: Cannot open backup device ‘D:\backup\full\spbr00060000015.bak’. Operating system error 21(The device is not ready.).
BACKUP DATABASE is terminating abnormally.
The problem was that I was not using a UNC path as the backup directory. The backup ran without any errors when I changed the path variable to a valid path:
Within a workflow that I was developing, there was a requirement to notify a group of SharePoint users that a lookup service had failed. This particular activity was within a parallel activity sequence. I chose to use the SendEmail activity to notify the users, but incorrectly set the Correlation Token to a new value. When testing this functionality in the workflow I received an error:
The correct Correlation Token for a SendMail Activity is the “Workflow” token. The reason, which is fairly obvious, is that the SendEmail activity maps to the workflow, not to a task, which would require a Task Token.
While I was building a CAML query for retrieving files from a document library, I used the U2U CAML query tool to construct the query syntax. It worked fine in the tool and returned the proper data, but when I used that query in the code, I found that ALL files were returned and not just the ones I expected.
As it turns out, the U2U CAML Query tool adds the tag <Query> to the query although it should not be included when using it to query items from a SPList. (Note: There are some instances where the Query tag is required, but for this case, it is not)
Here is a sample query:
SPListCollection spBPDLListCollection = spBPDLWeb.Lists;
SPList splist = spBPDLListCollection[documentLibraryName];
SPQuery query = new SPQuery();
// CAML for looking up documents owned by current user
query.Query = “<Where><Contains><FieldRef Name=’Author’ /><Value Type=’User’>”
+ currentDisplayName + “</Value></Contains></Where>“;
// get the items specified with the query
SPListItemCollection items = splist.GetItems(query);
If you are like me, you tend to deal with strange development nuances in the SharePoint environment. One of those nuances is trying to delete a content type that is in use. When I’m developing a solution that requires the creation of content types within the feature, I typically create that content type through code. That will work on the first deployment of the feature since it does not exist yet. On subsequent deployments, you will get an error that either the content type is in use (if you are trying to delete it before adding) or the content type already exists. One thing I do is disable the deletion/creation of the content type if I’m not making any changes to it on subsequent deployments. That will save a bit of development time. The second problem I get every so often is the “content type still in use” error when trying to delete a content type. I find this to happen if I am careless with removing items from a list, especially workflow tasks that are associated with a content type.
I found a decent SQL Script (below) on the interweb that displays all the instances of my content type in the SharePoint databases. In some cases, this will tell me where the “remnant” of the content type is and I can remove it. Other times, it will display something that I already removed and I’m stuck. If that happens, I first blow away the list where the content type was associated. If the list removal doesn’t work, I will delete the site collection and build a new one. (That is a luxury of having my own development VM.) I found that course of action to be quicker than trying to go through the database structure to find where to delete all instances of that content type.
I found that I could create a view that filtered items for myself ([Me]) and for the groups that I was in, but not both through the View editor. By editing the group view in SharePoint Designer, I updated the CAML query to filter both groups and items “assigned to me” and it worked just dandy:
<GroupBy Collapse=”FALSE” GroupLimit=”30″>
Tip #1 – There are two easy ways to tell which build of SQL Server you are running:
Tip #2 – At the time of this posting, this link contains the patches for all SQL Server builds. Found this very helpful when trying to get my SQL Server 2008 ready for SharePoint 2010, which required Cumulative Update 2 for SP1.
While installing and configuring SharePoint Server 2010 in a extranet QA environment, I encountered an exception when running the SharePoint Configuration Wizard, which generates the SharePoint Config database among other things. A dialog displayed an error of type System.ArgumentNullException… Parameter name: errorData:
This wasn’t very helpful, so I checked the SharePoint Log files under the 14 hive. Again, nothing interesting. Finally checked the event log and found a SQL exception error was occurring with SharePoint Foundation. The error text from the event log was as follows:
Unknown SQL Exception 53 occurred. Additional error information from SQL Server is included below.
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server)
It would appear that there was a problem connecting to the database server (SQL Server 2008 SP1) from the server that SharePoint was being installed. Working with the Database and Networking administrator, we found a few things that were not quite up to snuff. It would be nice to say that one or a combination of the fixes that we executed resulted in fixing this problem, but it is not that clear. Safe to say none of these tasks listed below were detrimental to the systems or the network. Here is a run down of those tasks that enabled the configuration wizard to work:
1. Alias – We found that the SQL alias that was defined, which we use in place of the actual SQL server name, was not setup properly in the SQL Server settings. Rather, it was completely missing. We added that back.
2. SID – Ran NewSID on the new SharePoint 2010 server as it was spun up using VMWare tools.
3. DNS – The DNS servers assigned to the SharePoint Server 2010 were two domain controllers for the extranet domain. The two DC’s did not have access to the internet and thus could not resolve DNS queries for external domains (i.e. www.microsoft.com, www.google.com, etc), which means any clients configured to use these servers for DNS resolution would also not be able to access the internet. For this reason, Windows update would not run on the SharePoint 2010 server, against the Microsoft update servers on the internet. The DNS configuration on the SharePoint server was temporarily changed to point to a DNS server which was able to resolve external domains, and Windows updates were run. But we had forgotten to change the DNS configuration back to the original DC. This resulted in the SharePoint 2010 server not authenticating to the domain. Additionally, in this configuration, the server would not have been able to resolve the FQDN of the SQL server.
4. Time – The local time on the database server was off, because it wasn’t authenticating to the extranet domain properly and getting it’s time set by the domain controller.
5. FQDN Server Name – We were entering the database server name in the Wizard without the fully qualified domain name. We added the “.domain.com” to the server name, ran the SharePoint Configuration Wizard and were able to make a connection to the database server, create the databases and complete the configuration.
Shout out to Chris Ryan for his assistance getting this resolved!
To find out the SharePoint 2007 version within Central Admin, navigate to “Central Administration > Operations > Servers in Farm”
For SharePoint 2010, go to Central Administration, under Upgrade and Migration, click Check product and patch installation status to view version numbers
I was presented with an instance of SharePoint (WSS 3.0) that was installed on a single server that utilized SQL Server 2005 Embedded Edition or as it is now called “Windows Internal Database.” This instance of WSS was being used internally be a select group of savvy users to “test” out the functionality of SharePoint before the roll out to the rest of the company.
We had reached a point in the process where we wanted to sunset the test instance and move the content that had been generated over several months to the production server. The next step was to backup the web application containing that content. The backup through Central Admin went fine, but the restore on the production server did not work. The problem was that the service account that was restoring the database in production did not have rights to the instance that was backed up on the single server. My first thought was, fine, I’ll just add the production service account to the security login for that content database on the single server in SQL Management Studio… I’ll just connect to it from there. It was then that I realized this was a “Windows Internal Database.” How do I connect to the database? After a little research, I found that the best way was to install SQL Server Express on the single server and connect to it using a somewhat odd connection string: “\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query” I installed SQL Service Express, added the production service account and gave it dbcreator and securityadmin server roles in SQL Server. The import was successful after that change.