With SharePoint 2010 the amount of databases on your SQL server has grown quite a bit. By default most of these databases have their recovery model set to ‘FULL’. After some time you will discover you’re running out of space.
The problem
Most likely the problem lies with the transaction logs of your databases. With the recovery model set to ‘FULL’ the will keep storing every transaction until you make a backup. Chances are you don’t configure a backup plan for you development environment as most development databases don’t need a backup as your sources will be stored in a source control system.
The (manual) solution
To solve this problem you can change the recovery model of each database by hand. For this you can open SQL Server Management Studio (SMSS), open the properties screen for a database and navigate to the options tab. There you will find the recovery model option.
Database Properties screen with the Recovery model set to ‘Simple’.
Saving this change will empty your transaction log. But it will not shrink the physical file on disk. To shrink this file you can look at the "Shrink" task.
The context menu’s to shrink the size of the log files.
The (automated) solution
Executing this step for every database manually is quite some work. So you want the easy solution.
The following TSQL script will change the recovery model for every database to ‘simple’ and shrinks the database.
USE [master] GO DECLARE @dbname SYSNAME DECLARE @altercmd NVARCHAR(1000) DECLARE @shrinkcmd NVARCHAR(1000) DECLARE [dbcursor] CURSOR FOR SELECT [name] FROM sysdatabases OPEN [dbcursor] FETCH NEXT FROM [dbcursor] INTO @dbname WHILE @@FETCH_STATUS = 0 BEGIN IF (SELECT DATABASEPROPERTYEX(@dbname, 'RECOVERY')) != 'SIMPLE' AND @dbname != 'tempdb' BEGIN SET @altercmd = 'ALTER DATABASE "' + @dbname + '" SET RECOVERY SIMPLE' EXEC (@altercmd) SET @shrinkcmd = 'DBCC SHRINKDATABASE ("' + @dbname + '")' EXEC (@shrinkcmd) PRINT @dbname END FETCH NEXT FROM [dbcursor] INTO @dbname END CLOSE [dbcursor] DEALLOCATE [dbcursor]
When you have a SharePoint farm and you want to use accounts from another domain you need a partial (one-way) or a full (two-way) trust between those domain.
A full trust is not always desirable and there your problem begins. After setting up the one-way trust you can authenticate with an account from the trusted domain, but the SharePoint People Picker doesn’t show any accounts from this domain.
It has been documented by others before, but as I ran into this recently I’ll give my summary how I fixed this.
This solution is the same for WSS 3.0/SharePoint 2007 as SharePoint 2010.
The problem
When using a one-way trust you don’t see any accounts from the other domain in the people picker.
People picker not showing accounts from the other domain.
The reason
This is an example of how you could use a partial trust.
Example of a one-way trust architecture.
You want to allow employees to authenticate in a development farm, but you don’t want to allow any test or service account from the development domain to authenticate in the company domain.
As the application pool account is based in the development domain it doesn’t have the right to query the company domain.
The solution
Using STSADM we can configure which forests and domains are searched for accounts by setting the peoplepicker-searchadforests property. The best part is that we can supply a username and password for a trusted domain.
SharePoint doesn’t allow you to store this username and password in plain text on the server. So you will have to configure a secure store. If you skip this step, configuring the search account for trusted domains will always fail with the following message.
Cannot retrieve the information for application credential key.
To create a credential key you will have to use the following command.
stsadm -o setapppassword -password <password>
This command has to be executed on every server in the farm.
Now you can configure the forests and domains you want to search using the following command.
stsadm -o setproperty -url <web application url> -pn peoplepicker-searchadforests -pv forest:<source forest>;domain:<trusted domain>,<trusted domain>\<account>,<password>
You can combine any number of forests and domains, but you need to specify at least one. You also need to include all forests and domains in one statement because every time you execute this command it will reset the current settings.
Also note this setting is per web application, and even per zone.
People picker showing accounts from the other domain.





