For the second time in the recent past, I’ve run into unexpected date results from SharePoint. The first time it happened with the FAST search engine and yesterday I encountered it on a second project while dealing with a simple list.
Basically, when a user submits a date in a SharePoint Date and Time field (think list field), SharePoint stores it in UTC. If SharePoint handles the rendering of that date then users never notice what happens behind the scene. However, if we have to do something with that SharePoint DateTime field (like synchronize to a database) and we ask for the date back in code, we are given back a string with the date in the UTC ISO 8601 format.
//properties.AfterProperties["StartDate"].ToString()
//"2012-01-01T00:00:00Z"
The “Z” is the UTC designator.
If you simply parse the string (like I did) into a new DateTime variable without realizing the UTC format you end up with a date converted into local time:
//DateTime.Parse(properties.AfterProperties["StartDate"].ToString()).ToString()
//"12/31/2011 4:00:00 PM"
The explicit ToLocalTime() equivalent:
//DateTime.Parse(properties.AfterProperties["StartDate"].ToString()).ToLocalTime().ToString()
//"12/31/2011 4:00:00 PM"
So, if we actually need to do something with the “1/1/2012” date the user submitted, we need to convert the results back into UTC.
The conversion required to get back the date the user submitted in the SharePoint list user interface:
//DateTime.Parse(properties.AfterProperties["StartDate"].ToString()).ToUniversalTime().ToString()
//"1/1/2012 12:00:00 AM"
While attempting to delete a large set of documents from an email enabled SharePoint 2010 document library using Explorer View, I was greeted with a dialog titled "Source Path Too Long" and the following details:
The source file name(s) are larger than is supported bythe file system. Try moving to a location which has a shorter path name, or try renaming to shorter name(s) before attempting this operation.
LONG-FILE-NAME-GOES-HERE.....
Type: EML File
Size: 215 KB
Date modified: 10/30/2012 8:07 AM
SKIP CANCEL
Do this for all current items (349 found)
Although the web interface was capable of deleting the files that was just going to take to long.
The workaround was to map the document library as drive. Once the drive was mapped the same attempt to delete a large set of documents succeeded.
If you have activated SharePoint Server Publishing Infrastructure feature on the site collection level, when you try to create a new sub-site on SharePoint 2010, there are only two site templates available by default: Publishing Site with Workflow and Enterprise Wiki. Where are the other site templates?
In SharePoint 2010, you have to ‘enable’ the other site templates first. To do so, go to Site Settings –> ‘Page layouts and site templates’ under ‘Look and Feel’ section. On the ‘Page Layout and Site Template Settings’ page, you can specify which site templates will be available for creating subsites in this site collection (eg. Blog, Records Center)
Many months ago we upgraded a web server used to host WSS sites. Before the server was upgraded from Windows 2003 to Windows 2008, all the original server functions and WSS sites were moved to a virtual machine. Recently it became necessary to move the WSS sites off the virtual machine and back to the original server where MOSS 2007 had been installed and running as a separate farm.
These are the steps we used to move the WSS web applications between two different SharePoint server farms:
- Collect all necessary configuration information for each web application on source farm
- Name of the content database
- Copy of the web.config
- Managed Path configuration
- Any other configuration points that may needed to be rebuild the web application…
- Delete the web application on the source farm
- No - content database delete
- Yes – IIS web site delete
- Create a new web application on the target farm
- In our case http:// for the default zone
- Name the content database something you will recognize ie. WSS_CONTENT_Delete
- Give the farm account on the target farm permissions to the original content database in SQL Server
- public and dbo
- If there is a GUID in the content database name, it can be renamed in SQL Server at this point
- Remove the new content database associated with the new web application creation on the target server. This is in the Central Administration | Application Management | SharePoint Web Application Management | Content Databases. Make a note of the content database name if the the default name was used.
- Change the Alternate Access Mappings (AAM) in Operations | Global Configuration | Alternate Access Mappings
- Add the original content database to the new web application via STSADM. We used STSADM instead of the GUI because the GUI instructed us to due to possible timeouts.
- stsadm –o addcontentdb –url http://THE_URL –databasename THE_DATABASE_NAME –databaseserver THE_DATABASE_SERVER_NAME
- Apply any additional configuration
- Change any firewall rules
- Check access to the new web application
- Delete the new content database from step 3 and 6 from SQL Server
Note: In this particular case, both farms shared the same database server so we had no need to move the physical databases.
It has been a while since we installed the Adobe PDF IFilter for MOSS 2007 or Search Server 2008. This is in part because Foxit Software (http://www.foxitsoftware.com) released a 64-bit PDF IFilter for SharePoint before Adobe did and because clients have been gravitating towards 64-bit SharePoint Server Farms for a while now. In any case, I had to revisit the installation for a new client and came across a couple of things I thought would be good to share.
First, the IFilter installation document found here:
http://www.adobe.com/special/acrobat/configuring_pdf_ifilter_for_ms_sharepoint_2007.pdf
instructs you to verify that the PDF settings are correct in the registry. Specifically, the value of this key:
\\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf
should be {E8978DA6-047F-4E3D-9C78-CDBE46041603}.
The installation in this case supplied another GUID so I assumed it was correct and the documentation was outdated. However, after the crawl executed it was clear something was wrong. The crawl logs stated that although items were crawled, “the filtering process could not process this item. This might be because you do not have the latest file filter for this type of item. Install the corresponding filter”.
Tip: Change the GUID in the .pdf registry setting to the GUID in the documentation.
After having done this, resetting the content indexes and restarting the crawl the PDF content was indexed as expected.
Second, in case you are looking for the 17x17 pdf icon that I think should be installed in the 12 hive TEMPLATE\IMAGES but isn’t, you can download it here:
http://www.adobe.com/misc/linking.html
Look for it near the bottom of the page.
If you’ve worked with SQL Server prior to the 2005 release you’ve seen the Service Manager. It was a taskbar tool that let you quickly stop and start SQL Server Instances and Services without having to load the SQL Server Enterprise Manager or the Services MMC. Honestly, I hadn’t used it in ages but this morning I wanted to find and stop all SQL Server instances on a development server in order to save on memory usage and host a Virtual Machine. At that point I remembered that it didn’t exist in the SQL Server 2005 or 2008 versions.
Fortunately, there is a replacement on CodePlex located here: http://sql2005srvcmngr.codeplex.com/
One of our clients requested our assistance after MOSS a infrastructure update failed. As a result, our client’s intranet site collection had now completely lost both its search box and the Search Center site was now hidden. Although it was possible to navigate to the Search Center site through the “View All Site Content” link, an error occurred when displaying search results. Of course, the error was a standard SharePoint error message that didn’t explain what was really happening. In addition, the Farm’s Search Settings page in the Central Administration SSP also threw an “Unexpected Error”.
After changing the appropriate web.config files to reveal more information and recreating the errors it became clear what the errors were:
On the search results page the error was System.IndexOutOfRangeException: DisplayInAdminUI.
On the search settings the error was ‘S2LeftNav_Administration’ was not found.
After searching around it became apparent that the issue would either be resolved by re-running the SharePoint Configuration Wizard or by recreating the SSP.
I didn’t want to do the second so I gave the first a try and this *did* correct both errors.
Today, while working on some unit tests I encountered an issue I had not encountered before. After setting up a testing fixture and a base test(s) on a project, the test(s) failed to load in the NUnit GUI Test Runner.
An NUnit dialog stated:
Not a Test Assembly
The assembly was not built with any known testing framework
At first the thought was that the issue might be with the version of NUnit framework. Perhaps it was a mismatch with the GUI Runner version? This was not the case. This was a new install on a server that had never had the NUnit framework installed.
A second thought was that there might be an issue with the decorations of the unit test class but this was disproven when I opened the assembly using Reflector. The unit test class and test methods did exist in the assembly. And this was the assembly I was trying to open with the GUI Runner. So why couldn't NUnit "see" the unit tests?
After speaking with a co-worker we realized that the issue was that there was a second assembly in the GAC that was causing the conflict. This project was part of a bigger solution and this solution installed the assembly into the GAC. It became clearer that the issue was the GAC version when I checked the Tools | Test Assemblies in the GUI Runner. There was indeed a reference (Path:) to the assembly in the GAC. After uninstalling the assembly from the GAC the GUI Runner was able to load the test(s).
Recently while working on a client SharePoint project I encountered the following error code and message while executing a CAML update statement against a list:
<Results xmlns=\"http://schemas.microsoft.com/sharepoint/soap/\">
<Result ID=\"1,Update\">
<ErrorCode>0x81020014</ErrorCode>
<ErrorText>One or more field types are not installed properly. Go to the list settings page to delete these fields.</ErrorText>
<z:row ... xmlns:z=\"#RowsetSchema\" /></Result>
</Results>
Frankly, the error message wasn't very helpful and I didn't see the issue right away but then I saw it -- I had used the wrong internal column name. The actual internal name in this case had a trailing 1 at the end of it. After using the correct name there was no need to "delete these fields" since the fields were indeed properly installed. It would have been more helpful if the message had said something like "the column you are trying updated doesn't exist", or "check your column names".
Hopefully this helps someone else or perhaps just me in the future.
Every so often I find it necessary to force a SharePoint web part page into edit or design mode using query string parameters. Originally posted on one of our internal development blogs, I decided to share this because it does come in handy from time to time.
SharePoint Query String Parameters
| Query String Parameter | Values |
| DisplayMode | Design or Edit |
| ToolPaneView | 2 |
| Mode | Edit |
| ControlMode | Edit |
| Contents | 1 |
Helpful JavaScript
JavaScript:MSOLayout_ToggleLayoutMode()
JavaScript:MSOTlPn_ShowToolPane('2')
These come from Todd Bleeker’s blog: http://www.mindsharpblogs.com/todd/archive/2005/02/11/285.aspx