No matter which disaster recovery solution you decide to implement for your environment, you are likely to incur some data loss.

http://technet.microsoft.com/en-us/library/ff628971.aspx#Section1

This tiny PowerShell Script will help.

function GetLibEmail ($WebApp)
{

    $WebApplication = Get-SPWebApplication $WebApp
    $WebApplication | Get-SPSite | Get-SPWeb  -limit all | ForEach-Object {
            write-host "——-"
            write-host "URL of Webs: " $_.Url
            $lists = $_.lists
            $lists | ForEach-Object {
            if( ($_.CanReceiveEmail) -and ($_.EmailAlias) ){
                write-host "Title of list: " $_.Title
                write-host "Email of list: " $_.EmailAlias
             }
          }  
     }

}

#URL of WebApplication as parameter

ModLibs -WebApp http://projekte.test.local

Jeder IIS Server, der was auf sich hält, macht standardmäßig nachts um 2:43 ein Recycling der ApplicationPools. Damit wird der vom ApplicationPool reservierte Speicher aufgeräumt.

Bei SharePoint ist dies recht nervig, vor allem für die User, die morgens als erste im Büro sind. Der erste Seitenaufruf dauert ewig. Selbst schuld, Frühaufsteher
Aber auch den Lerchen unter den User kann vom Admin geholfen werden. Mit einem Warmup Script, welches dem SharePoint vor dem ersten Kaffee etwas einheizt.

Add-PSSnapin Microsoft.SharePoint.PowerShell;
function Get-WebPage([string]$url)
{
    $wc = new-object net.webclient;
    $wc.credentials = [System.Net.CredentialCache]::DefaultCredentials;
    $pageContents = $wc.DownloadString($url);
    $wc.Dispose();
    return $pageContents;
}
Get-SPAlternateUrl -Zone Default | foreach-object {
    write-host $_.IncomingUrl;
    $html = Get-WebPage -url $_.IncomingUrl;
}

Das Script kann man im Übrigen auch bei JonTheNerd finden 

Damit der Admin nicht mitten in der Nacht aufstehen muss, dieses Script mit dem Windows Task Scheduler steuern.

Eine Zeit eingeben, die NACH dem Recycling liegt.

Das Powershell Script hinzufügen. Im Script darauf achten, das

Add-PSSnapin Microsoft.SharePoint.PowerShell

drinsteht, da die Windows Powershell gestartet wird.

This does not happen in any other lists or libraries on this site. You can translate it back to German with Google Translate anyway

For an administrator who opens the recycle bin on the server itself, no chinese is shown, but only the ID of the item instead the content of the title column.

The items are of Content Type: Element (System). If another new list is created with this content type and an item of this list is deleted all wents fine. See first item in above screenshot.

In this list, Nintex Workflows are setting the permissions. The workflow starts automatically when a new element is created but waits until a field is set to a certain value.

I tested to reconstruct this with a new list and a similar Nintex Workflow. But in a new list the "chinese issue" does not appear, even when a Nintex Workflow is running and waiting.

Any ideas anyone? Google does not help here, nor Bing does.

What happend?

Some users’ display names have been updated in Active Directory. The User Profile Synchronization runs every night on the SharePoint Farm.

All went well. But on a single sitecollection the display name (Preferred name) remains still with the old data. Even in the people picker the old values were shown.

Just on that specific sitecollection.

I tried a full synchronisation, I started all the User Profil Synchronization Jobs I found in Central Administration. Nothing changed.

Then I found the right KB-Article:

http://support.microsoft.com/kb/2012619

It says: only users with at least contributor rights will have their profile data updated on a site due to performance reasons.

This is by design. The only solution ist to give your users at least these contributor rights. If you delete and add the users again their data will also be updated but only this time and not automatically in the future.

“Contribute or live with your old profile data on this website”

But not all dialogs seem to be updated as you can see :

But .. the good news: it IS move to site collection recylce bin. NOT to the users recylce bin.

But … if you are going to delete the root site of your site collection the warnings are correct, except of the one sentence in the first warning;

A bit confusing, just look what you’re goíng to delete and always have a working backup!

Load control template file /_controltemplates/TaxonomyPicker.ascx failed: Could not load type ‘Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker’ from assembly ‘Microsoft.SharePoint.Portal, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’.

Fragt man das Google-Orakel so stellt sich heraus, dass es sich (wohl) um einen Bug handelt. Eine offizielle Bestätigung dessen von Microsoft habe ich leider nicht gefunden.

Um den Fehler aus dem Log zu bekommen ist die empfohlene Lösung, die Datei umzubenennen.

Zu finden unter:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATES

und aus

TaxonomyPicker.ascx

dann

TaxonomyPicker.ascx.old machen.

Achtung: auf dem Server werden die Dateiendungen gerne ausgeblendet (für ein Serverbetriebssystem eine recht dämliche Voreinstellung). Also aufpassen, sonst benennt man die Datei schnell in

TaxonomyPicker.old.ascx um. Und das versucht SharePoint dann doch wieder zu laden und der Fehler taucht wieder auf.

Let’s say you have a site collection based on an English site template on an English SharePoint Server 2010. You create a Team Site and navigate to the standard library “Shared Documents”.

There you want to add one of those neat OOTB Workflows.

Let’s say “Collect Feedback – SharePoint 2010”

To have this you have the “Workflow” Site Collection Feature to be activated, this is active by default.

Then you create another TeamSite, let’s say in German. And there you try to add the same workflow, but … it is gone, there are all gone, except the “Disposition Workflow”.

The reason was: the German Language Pack has been installed AFTER the site collection has been created. So it seems to me, except the “Disposition Approval” workflow, the features for the other localized workflow templates have not been updated.

A quick look into the 14-Hive\Templates shows that the localized features for the missing workflows are present after installing the German Language Pack.

The feature.xml from the German (1031) one looks good, so why does it not show up in the workflow list box on the TeamSite?

This is weird and I have no explanation for this.

A solution was to deactivate and reactivate the site collection feature “Workflows”, but with this all your running workflows are going to nirvana, so this is no way for a productive environment.

An advice is: install all language packs you’ll ever need in the future at the beginning, before any site collections are created. Uh, I know .. not a “real life” advice …

If you deny “Manage Lists” in “List Permissions”

and then want to create a new webiste you get this.

If you clear both checkboxes (grant and deny), it works.

——

If you grant all rights but deny “Add items” on List Permissions

you won’t be able to create new sites bases on Team Site Template:

But new libraries and other site template will work. Ah .. so I have not tested all the templates, only Blog, Document Workspace, Blank Site, Group Work Site.

So, you see it’s not easy to find out which combinations of single permissions will work. If anybody knows a good documentation of reasonable settings, let me know!