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!

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 …

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. 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!

Herr Obesser wird uns die Integration und Interaktion von Mindmanager mit SharePoint vorstellen.

MindManager 9 als visuelles Front-End für SharePoint mit MindManager Explorer für SharePoint:

• Visualisieren von SharePoint Inhalten mit MindMaps
• Aggregieren von SharePoint Informationen Listen-, Site- und Serverübergreifend in MindManager Maps.
• Mit MindManager-Maps individuelle (ad Hoc) Ansichten auf SharePoint Inhalte erstellen

Mit MapShare MindManager in SharePoint integrieren

• MindManager Maps (*.mmap, *.xmmap) in SharePoint-Bibliotheken mit dem MindManager Viewer im Browser öffnen
• Spezifische Maps mit dem Viewer-Web-Part auf SharePoint-Seiten direkt einbinden.

Wo:

Wann: Di, 23.11.2010, 18:30

http://www.google.com/maps?q=H%C3%B6gerdamm+39+,+20097+,+Hamburg,+Deutschland&ie=UTF8&hq=&hnear=H%C3%B6gerdamm+39,+Hamburg+20097+Hamburg,+Deutschland&ll=53.5469,10.0132&spn=0.004411,0.018196&z=16

You have to operate a SharePoint web application and you would like to delegate Full Control permissions to your operating team.

You create a new security group in your domain (let’s say “SharePoint Operators”) and you want to let this group operate as SharePoint\system.

You create a new user policy and add your “SharePoint Operators” domain group as user, set Full Control and “Account operates as System”

The you get the following error:

Only user accounts belonging to the "All" zone can be designated as System.

This error is misleading here, it want’s to tell you: This does not work with domain security groups, only with single domain users. So you have to add every user of your domain group “SharePoint Operators” separately.

This will work but creates a separate policy for every single user you add here.

Seitdem mein Rechner aber 8 GB RAM hat und die VMs mit mehr als 4GB RAM laufen .. Blue Screen bei jedem Resume.

Geholfen hat:

VMWare Workstation im XP Compatibility Mode und als Administrator starten.

I simply set up a folder directly on the SharePoint WFE. This folder also has a subfolder called “Management”.

I also created a managed account in SharePoint called “sp_fileserver” as a content access account for crawling this folder.

sp_fileserver has only read permissions. Additionally the security group “Software Development” has read/write permissions on this folder and it’s subfolder.

I created a new content source

and set up a crawl rule with sp_fileserver as the content access account.

I started a full crawl and members of the AD security group “Software Development” can search this file directory successfully.

So far so good.

Now I changed the user permission of the subfolder “Management”. I deleted all user permissions for “Software Development. After a fresh incremental crawl members of this group no longer got search results from this subfolder. This was to expect.

Next scenario.

An Active Directory  security group “Management” has read write permissions on subfolder “Management” but no permissions at all on the parent folder. What will happen?

Result: Members of the management group get results from subfolder “Management” but none from it’s parent folder to which they have no access. But they cannot open the files in folder “Management” because the don’t have access to the parent folder.

Same is when you have special permissions on a single file. Let’s say user Luise has permissions to a single file in the “Management” folder but no permissions to the folder itself. On the file system she cannot reach her file. But … in SharePoint Search she get’s a result for her file. Nothing won with that, when she clicks the link in the search results listing nothing will happen. The file won’t open.

As you can see there can be a little difference in what you see in your file servers search results in SharePoint and to what you have real access to.