User property check – help yourself script

User property check – help yourself script

Get-UserProfiles – Get your own user profile report

Ever wanted to check  your profile store in terms of usage or correct data for a specific property in all profiles?

Download this tiny script to accomplish your mission.

.\Get-UserProfiles.ps1 -PropertyConstant [PropertyConstant]

[Download]

Check this site for all OOB Property Constants http://msdn.microsoft.com/en-us/library/microsoft.office.server.userprofiles.propertyconstants_fields.aspx

The script needs to be run – of course on a server that is part of the Farm where your User Profile Service sits on.

 

Changing quota of a site

Changing quota of a site

I wrote a script for all those who want an easy and safe way to change the quota of a site.

[Download]
.\AdjustSiteQuota.ps1 -Identity [$url] -Percentage [1-1000]

Its very simple… just suppy the url and the percentage how the new values for StorageWarningLevel and StorageMaximumLevel should be adjusted.

Iagine if  you want to decrease the quota of a site by 50%, jsut supply 50 as parameter, let me give some examples.

 

I want to increase the site quota for a (mysite http://mysite/personal/themysite) by 20%

Command: .\AdjustSiteQuota.ps1 -Identity "http://mysite/personal/themysite" -Percentage 120

 

I want to decrease the site quota for a (mysite http://mysite/personal/themysite) by 50%

Command: .\AdjustSiteQuota.ps1 -Identity "http://mysite/personal/themysite" -Percentage 50

See the script in action…

Enjoy and comment if you have an idea or found an bug.

SharePoint 2013 Entwicklung mit Visual Studio 2012

SharePoint 2013 Entwicklung mit Visual Studio 2012

Viele alte und neu hinzugekommene SharePoint Entwickler beschäftigen sich mit dem Thema SharePoint 2013 und haben wahrscheinlich schon versucht mit Visual Studio 2012 sich dem Thema zu nähern.

Leider ist das nicht so einfach, da nach der Installation beider Software Produkte, SharePoint 2013 und Visual Studio 2012, in letzterem die SharePoint 2013 Projektvorlagen fehlen und alle SharePoint 2010 Projektvorlagen keine Kompatibilität mit SharePoint 2010 aufweisen – ein Hinweis, dass eine SharePoint 2010 Installation vorausgesetzt wird, vereitelt jeden Versuch.

Um jetzt schon erfolgreich für SharePoint 2013 zu entwickeln, müssen ein paar Komponenten installiert werden. Ich gehe erst einmal davon aus, dass der Server über keine Internet Verbindung verfügt.

Bei der Installation der Komponenten ist die Reihenfolge zu beachten

Nachdem alle Komponenten installiert wurden, kann nun jeder nach Belieben die jeweils passende Visual Studio 2012 Projektvorlage wählen.

Für diejenigen, deren Server ans Internet angebunden ist, gibt es den Web Platform Installer 4.0. http://www.microsoft.com/web/downloads/platform.aspx.

Nach dem Download und dessen Start suchti hr nach office <enter> und wält Microsoft Office Developer Tools for Visual Studio 2012 RTM – Preview aus. Alle benötigen Komponenten werden nun mitinstalliert – wie langweilig 🙂

 

 

Migrieren von Benutzern

Migrieren von Benutzern

Nachdem ein Domänen Benutzer im Active-Directory umbenannt oder dieser in eine andere Domäne migriert wurde, muss man als SharePoint Administrator das Kommando stsadm -o migrateuser oder Move-SPUser ausführen, damit das neue/migrierte Konto die SharePoint Berechtigungen erhält.

Hier ist die Snytax für das veraltete stsadm.exe Kommando

stsadm -o migrateuser -oldlogin -newlogin [-ignoresidhistory] stsadm -o migrateuser -oldlogin HSD\Bob1 -newlogin HS\Bob

Hier ist die entsprechende Syntax für den selben Vorgang, nur mit dem PowerShell Cmdlet und ensprechender Syntax

Move-SPUser [-Identity] -NewAlias [-AssignmentCollection ] [-Confirm []] [-IgnoreSID ] [-WhatIf []]
Move-SPUser -Identity “HSD\Bob1” -NewAlias “HS\Bob”

Wann immer die Fehlermeldung – DS_NAME_ERROR_DOMAIN_ONLY auftaucht, liegt es daran, das der SidHistory check fehlschlägt.

Das Kommando migrateuser/Move-SPUser sucht in der SIDHistory des neuen Accounts den alten Account (Neuer Account->Prüfe ob es einen Eintrag gibt->OLDName->NEWName)

In folgenden Fällen wird das Kommando Fehlschlagen, da kein Eintrag in der SID Historie des neuen Accounts gefunden werden kann.

  • Der Benutzeraccount wurde nicht umbenannt, sondern neu erstellt
  • Der Benutzeraacount wurde in eine andere Domain transferiert

Im ULS sieht die Meldung dann wie folgt aus:

stsadm: An error occurred while translating user name ‘HS\BOB1’ to a Windows account name – (DS_NAME_ERROR_DOMAIN_ONLY) Callstack: at Microsoft.Office.Server.Utilities.WindowsSecurity.TranslateUserName(String name, DS_NAME_FORMAT formatOffered, DS_NAME_FORMAT formatDesired) at Microsoft.Office.Server.UserProfiles.Helpers.GetSidHistory(String strAccountName) at Microsoft.Office.Server.UserProfiles.Helpers.IsSidInSidHistory(String strAccountName, Byte[] bOldSid) at Microsoft.Office.Server.Administration.AccountMigrationManager.MigrateAccount(Guid partitionId, UserProfileApplication userProfileApplication, String strOldAccountName, String strNewAccountName, Boolean bEnforceSidHistory)

Lösung

Glücklicherweise gibt es einen Schalter, der den SidHistory check umgeht.

  • stsadm -o migrateuser -oldlogin HSD\Bob1 -newlogin HS\Bob -ignoresidhistory
  • Move-SPUser -Identity “HSD\Bob1” -NewAlias “HS\Bob” -ignoresidhistory
%d bloggers like this: