Tuesday, March 25, 2008
[MOSS2007] "Database Default Locations" ignored by SharePoint 2007
While installing a new environment today, I changed the "Database Default Locations" setting in SQL Server 2005 to make sure the database files and log files were created on a certain location. Testing by creating a database manually in the SQL Management Studio worked, but when I ran the SharePoint Configuration Wizard the databases were created in the old location.
CAUSE
After some troubleshooting I found out that SharePoint somehow retrieves the old setting until SQL Server 2005 has been restarted (reboot of the server or restart of the services). Why this is I have no clue.
RESOLUTION
Just restart SQL Server 2005 and try again. The new databases are now created in the correct place.
Wednesday, March 19, 2008
Usefull and Free SharePoint Tools (Part 1)
DAVCopy
When you need to copy a lot of data to SharePoint (for example from a file share), doing this manually is:
- A lot of work
- Not easy to do, especially when you need to upload a directory structure. You have to use the explorer view
- Not really IT like (script what you can script, better lazy than tired :-)
Browsing through the Internet I ran into a tool called DAVCopy. This tool can upload files and directories to SharePoint, with the same functionality as XCopy. For example /E for subdirectories including empty ones.
The tool has some shortcomings though:
- As most of you probably already know, SharePoint doesn't accept certain characters in filenames (http://blogs.msdn.com/joelo/archive/2007/06/27/file-name-length-size-and-invalid-character-restrictions-and-recommendations.aspx). Just like copying with the Explorer view, DAVCopy just tries to upload the files without checking any illegal characters. A good thing is that DAVCopy logs the error and skips the illegal file.
To get around this issue I created my own filename checker script, which corrects all illegal characters before running DAVCopy. - The logging of the tool is very limited. It can only write logging to the console. A nice logging to a text file and especially a good summary will be a great improvement!
Link: DAVCopy
SharePoint 2007 Shared Services Provider User Profile Property Replicator
On a lot of projects we are using a development/test/acceptance/production strategy. Each environment must have its own settings. When migrating a solution to a new environment, all required settings need to be migrated as well. One of these settings are the custom User Profile Properties. A solution I recently deployed required these properties to be present before it started to work.
Creating these properties manually is not only time consuming, but also susceptable to errors. The User Profile Property Replicator tool is able to export and import these properties using XML files. I created an export of all properties in my development environment, changed the XML file to just include my custom properties and used this file to create the properties on all other environments. Quick, easy and without errors!
The only thing that can be improved is changing properties. When importing a property that already exists, the tool skips this property. I would like to see that the tool would update the property instead of skipping it. This is especially usefull when using big choice lists!
Link: MOSS Profile Replicate
Sharepoint Shared Services Search Provider Property Creation
Just like the tool above, this tool is able to export and import properties to/from XML files. Only this tool can export and import crawled properties, managed properties, content sources and search scopes.
A solution I had to deploy was relying on crawled and managed properties. To be able to map crawled properties to managed properties, the indexer first needed to discover these crawled properties in documents or content types. Using this tool I was able to export all managed and crawled properties from my development environment, change the exported XML files and import these properties into other environment. Again quick, easy and without errors!
Link: MOSS Provider Property Creation
SharePoint 2007 Shared Services Provider User Profile Importer
SharePoint is able to import settings from a external source (Active Directory, BDC source, etc) and map these values to certain profile fields. The external source is then leading for that property. But for some fields, you might not have an external source available but do want the field populated. Using the Profile Importer you can. Just create a XML input file and a XML mapping file (map the used XML tags in the input file to User Profile Property field) and off you go.
After creating my own User Profile Property, I would like to have certain values populated for certain users. Unfortunately these values were not in the Active Directory, so I could not sync them from AD. Using the Profile Importer tool I am able to populate the values I want into the fields I want for the users I want. All and all a great tool!
Link: MOSS Profile Import
SharePoint Solution Installer
As of SharePoint 2007 all custom components can be deployed using the Solution Deployment framework. Developer just have to place their solutions into a wsp package, which can then be imported into SharePoint 2007 and deployed to all servers.
Importing and removing wsp files into SharePoint 2007 must be done using the stsadm command, after which the solutions can be deployed from the Central Admin. The steps become difficult when you try to deploy a new version of a wsp file:
- Retract the old version from the Central Admin
- Use stsadm to remove the old version from solution deployment
- Use stsadm to add the new version to solution deployment
- Deploy the new version from the Central Admin
In other words switching between tools a lot. There must be an easier way!
And with the SharePoint Solution Installer there is! The tool first checks if SharePoint is installed, then if you have sufficient permissions to perform a deployment, if the Administration and Timer services are running and if the solution is already installed. If this is not the case, you can choose the web application to which the solution must be deployed. If it is installed, you can select to remove or repair (!!!!) the solution. In case of a repair, the tool automatically performs the four steps above automatically.
Installing wsp files made easy!!
Friday, January 11, 2008
SSL cannot find private key
Last week I generated a certificate request in IIS and requested an SSL certificate. Today I tried to install the recieved certificate, but after "Processing the request" the certificate was damaged. I was able to locate it in the Certificates MMC, but while trying to export the certificate the wizard came with the message "A private key cannot be found".
When I tried to apply the certificate to a IIS web site, the web site couldn't be reached using https. No error messages were reported.
TROUBLESHOOTING STEPS
I found the Microsoft SSL Diag tool on the Microsoft site and used this tool to troubleshoot. It came back with the error ""You have a private key that corresponds to this certificate but CryptAcquireCertificatePrivateKey failed"".
CAUSE
The above issue was caused by the fact that permissions on files in the following directory were incorrect:C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeysThis directory contains files with the server's private keys. Due to the incorrect permissions, was the server unable to read the certificate private keys.
RESOLUTION
I reapplied the security settings of the directory to all files by opening the properties of the directory, select the security tab, click the Advanced button, select the "Replace permission entries on all child objects with entries show here that apply to child objects" and click OK.
The server was now able to read the private key files and therefore able to use the certificate.
Wednesday, December 12, 2007
[MOSS/WSSv3] MOSS and WSSv3 Service Pack 1 released!
"For information on what's included in the service pack view the Announcing WSS 3.0 and MOSS SP1 article from TechNet. This information will be important from both a business and technical perspective to support installing SP1. The KB "Description of Windows SharePoint Services 3.0 Service Pack 1 and of Windows SharePoint Services Language Pack 3.0 Service Pack 1" in addition is a must read. It includes a link to a list of fixes included in WSS SP1. For Office SharePoint Server 2007 SP1 another KB has been posted with a downloadable Office Servers list of fixes."
Note: For SharePoint Server 2007 environments, WSS 3.0 SP1 should be installed before SharePoint Server 2007 SP1.
Download WSS 3.0 SP1
SP1 existing deployments:
Windows SharePoint Services 3.0 SP1, 32-bit edition and 64-bit edition
Windows SharePoint Services Language Pack 3.0 SP1, 32-bit edition, 64-bit edition
Download Office SharePoint Server 2007 SP1 (includes SP1 for Project Server, Forms Server, and Groove)
Office SharePoint Server 2007 SP1 32-bit edition and 64-bit edition
Office SharePoint Server 2007 Language Pack 3.0 SP1 32-bit edition, 64-bit edition
Download SharePoint Designer 2007 SP1
SharePoint Designer SP1
SharePoint Designer Language Pack SP1
Source: http://blogs.msdn.com/sharepoint/archive/2007/12/11/announcing-the-release-of-wss-3-0-sp1-and-office-sharepoint-server-2007-sp1.aspx
Monday, December 10, 2007
[MOSS/WSSv3] Antivirus exclusions in SharePoint 2007
The System process on the server was using this CPU time and using Process Explorer I was able to track the usage to the tmxpflt.sys thread. This file was part of the TrendMicro OfficeScan product, so the CPU usage was an AV issue. I searched the Internet for antivirus exclusions for SharePoint 2007, but wasn't able to find any exclusion information for SharePoint 2007. This ment I had to do the troubleshooting myself.
After some more troubleshooting I found out that:
- The Windows SharePoint Services Timer service started a job every minute which caused the issue. When I stopped this service, the CPU didn't spike at all.
- The Windows SharePoint Services Administration service was running the job. When I stopped this service when the CPU was high, the usage immediately dropped.
- The Windows SharePoint Services Administration service was writing some logging in the file WSS_AdminService.log, which was located in the directory C:\Documents and Settings\Default User\Local Settings\Temp.
- The WSS_AdminService.log file was about 65MB. TrendMicro OfficeScan scanned the file before the Administration service was able to write in it. With 65MB, this took some time and processing power.
After deleting the log file, the CPU usage didn't spike at all, so I excluded the C:\Documents and Settings\Default User\Local Settings\Temp directory which solved all issues!
So one exclusion for your Antivirus software when using SharePoint 2007: C:\Documents and Settings\Default User\Local Settings\Temp
Wednesday, December 05, 2007
[MOSS/WSSv3] Moving sites between content databases
On his blog, Todd Klindt describes how to use the operation:
"On multiple occasions as a SharePoint administrator I have needed to move a Site Collection from one Content Database to another one. In the past this process was very painful and very manual. In this blog post I will show you how to move Site Collections between Content Databases with a single STSADM command using the "mergedbs" operation that was introduced in KB934525."
[MOSS/WSSv3] WSS Logs grow fast after installing patch
On the Microsoft site I ran into article KB941789 which described a solution. After performing the steps, the log stops growing fast.
Thursday, November 29, 2007
[MOSS] New version of the MOSS Installation Guide
- Installation of Public Update of October 9th
- Default configuration steps of MOSS
- Some extra steps to correct issues with the Public Update
The new version can be downloaded here
Please let me know if you have any updates/questions about the guide by posting a comment!
Have fun installing!!
Wednesday, November 21, 2007
[MOSS/WSSv3] Bug in SharePoint Public Hotfix of October 9th
Recently I have installed the MOSS and WSS public hotfix of October 9th (WSS 3.0 - KB934525, MOSS 2007 KB937832) on several environments. After the installation I noticed that DCOM errors were added to the eventlogs. I troubleshooted the issues and it turns out that the WSS and MOSS patches are resetting the permissions on the OSearch and SPSearch DCOM objects.
Before installing the hotfixes the security settings on both objects were:
- Administrators
- <MOSS Configuration Database account>
- <MOSS Search account>
- SYSTEM
- WSS_ADMIN_WPG
- WSS_WPG
All account had "Local Activation" and "Local Launch" permissions.
After installing the WSS patch the security settings on the SPSearch DCOM object were reset to default settings.
After installing the MOSS patch the security settings on the SPSearch DCOM object were reset to default settings.
- Administrators
- LOCAL SERVICE
- SYSTEM
Fortunatelly this was solved easily by adding the WSS_ADMIN_WPG and WSS_WPG groups to the OSearch and SPSearch object and granting them "Local Activation" and "Local Launch" permissions.
How to determine the DCOM settings??
- Start > Run
- dcomcnfg
- Component Services > Computers > My Computer >DCOM Config
- Select object OSearch or SPSearch
- Right click > Properties
- Select tab Security
- Click Edit at "Launch and Activation Permissions"
Monday, November 19, 2007
[iFilter] Adobe released a work around for the PDF iFilter in x64
This is a great oppurtunity for folks who have a 64-bit installation of Microsoft Office Sharepoint Server 2007 and want to index pdf documents, but do not want to spend money on a 64-bit FOXIT IFilter."
Source: Filter Central