Es geht nicht ohne: PowerShell und SharePoint

Es geht doch nichts über Rituale. Ich bin also gerade auf einem SharePoint-Server als Farm-Admin eingeloggt und wollte ein wenig powershellen. Und da kommt die Meldung:

Auf die lokale Farm kann nicht zugegriffen werden. Cmdlets mit `FeatureDependencyId`sind nicht registriet.

Wer kennt die Meldung nicht. Und warum ist die da: Sicherheit. Nur Farm-Admin reicht halt für die PowerShell nicht (Ach so: natürlich habe ich meine PowerShell schon mit erhöhten Rechten gestartet, das ist doch klar).

Was ist nun also das Problem? Der Benutzer ist zwar Farm-Admin, kann aber von der Shell nicht direkt auf die Datenbanken von SharePoint zugreifen. Somit kann ich die meisten PowerShell Befehle (für SharePoint) nicht durchführen. Wenn ich nun also doch mal ein Get-SPWebApplication “foo” mache, dann bekomme ich die Meldung

Auf die lokale Farm kann nicht zugegriffen werden. Vergewissern Sie sich,. dass die lokale Farm ordnungsgemäß konfiguriert sowie aktuell verfügbar ist und Sie über ausreichende Berechtigungen verfügen, um auf die Datenbank zugreifen zu können, bevor Sie es erneut versuchen.

Aha – das steht’s ja schon. Ich kann nicht auf die Datenbank zugreifen. Um das Zu ändern gibt es den Befehl Add-SPShellAdmin. Nur dumm, dass ich den als jemand ausführen muss, der über entsprechende Berechtigungen verfügt (also der schon Shell-Admin ist).

Na gut, dann muss dafür mal eben kurz der spFarm herhalten. Also eben eine CMD als spFarm gestartet mit

runas /user:spFarm cmd

und dann eine PowerShell starten. Hierbei muss diese aber elevated gestartet werden, und dass vom Prompt aus. Das geht eigentlich auch ganz einfach

@powershell Start-Process -Verb "runas" powershell

So, nun habe ich also eine PowerShell als spFarm mit erhöhten Rechten. Der Rest ist einfach

Add-PSSnapin Microsoft.SharePoint.PowerShell
Add-SPShellAdmin busitec\eiben

Wenn ich nun wieder hingehe und eine SharePoint Verwaltungsshell (mit erhöhten Rechten) starte, dann kann ich auch per PowerShell auf die Farm zugreifen.

Voila!

SPRRPC006 – SPC2014 Special Tag 3 Impressionen

Tag 3 der SPC 2014 ist rum und wir haben unsere Eindrücke der Sessions und der Stimmung mal für Euch zusammengefasst.

Themen:

  • Search und Content Optimization
  • Making SharePoint rock
  • Yammer zieht überall ein
  • Deep Dive Power BI und Data Management Gateway
  • Windows Azure Active Directory Services
  • AMD WebContentManagement im großen Stil

Continue reading

SPRRPC005 – SPC2014 – Special Tag 2 Impressionen

Tag 2 der SPC 2014 ist rum und wir haben unsere Eindrücke der Sessions und der Stimmung mal für Euch zusammengefasst.

Themen:

  • Real World Admin Scenarios
  • Power BI
  • SQL Server Performance Optimierung
  • External Networks mit Yammer
  • InfoPath is dead, Access is back. Welcome SharePoint Forms! Oder so…

Continue reading

SPRRPC004 – SPC2014 Special Tag 1 Impressionen

Tag 1 der SPC 2014 ist rum und wir haben unsere Eindrücke der Sessions und der Stimmung mal für Euch zusammengefasst.

Themen:

  • Office 365 und SharePoint Online – Zahlen und Fakten
  • SharePoint 2013 on Premise und Hybrid
  • Office Graph und Projekt “Oslo”

Continue reading

SPRRPC003 – SPC2014 Special – Keynote

Wie versprochen, das Podcast Special aus Las Vegas, direkt von der SharePoint Conference 2014. Auf SharePoint Podcast bereits online mit Kommentaren von Michael Greth, hier für alle UserGroup Mitglieder nochmal zum Nachhören.

Themen:

  • Bill Clinton
  • Oslo / Office Graph
  • Office 365 Video Portal
  • SharePoint OnPremise
  • Contextual Apps
  • Android SDK / Any Device Strategie
  • Platform Updates
  • Neue Releases 2014
  • IT-Pro Infos

Continue reading

SPRRPC002 – Nachlese SPUGCOL Relaunch

Am 18. Februar 2014 haben wir bei DELL in Köln die UserGroup Köln nach langer Pause neu gelauncht. Eine wirklich tolle Veranstaltung, die sehr gut besucht war. Hier nun die Nachlese im Audioformat.

Als „UserGroup to Go“ sind unter anderem enthalten:

  • Kurze Zusammenfassung der Vorträge
  • Interview mit Christian Groß von Solutions2Share
  • Interview mit Nicki Borell von Experts Inside

Continue reading

Ein paar Fragen an das Active Directory

Beim Betrieb einer SharePoint-Farm ist man auf die korrekte Pflege von Accounts im Active Directory angewiesen. Gerade im Zusammenhang mit Kerberos ist es wichtig, dass alle Einstellungen im Active Directory richtig eingetragen werden, damit die Authentifizierung auch ohne Probleme funktioniert.

Als SharePoint-Farm Administrator hat man dazu allerdings nicht immer ohne weiteres Zugriff auf das Active Directory, zumindest nicht auf die Management-Tools. Nun stellt sich also die Frage, wie kann ich feststellen, welche Service-Principles alle für einen Account im Active Directory registriert wurden. Wenn ich Zugriff auf einen Domain-Controller hätte, dann würde ich ganz einfach SETSPN verwenden.

C:\>SETSPN spIntranetWA
Registered ServicePrincipalNames for CN=spIntranetWA,OU=Dienstkonten,OU=HeadQuarter,DC=acme,DC=local:
    HTTP/sp01.acme.local
    HTTP/intranet.acme.local

Aber SETSPN kann ich nur direkt auf einem Domain Controller ausführen, da komme ich als SharePoint Farm-Admin also nicht drauf. Was nun?

Wie bei allen Administrativen gibt es eine Ultimative Antwort: PowerShell!

Die Lösung ist so einfach, ich traue mich die ja schon kaum zu posten. Mit folgendem Befehl kann ich alle Einträge im Active Directory suchen, deren Account-Name “spIntranetWA” ist:

C:\> ([adsisearcher]"samaccountname=spIntranetWA").FindAll()

Path                                                        Properties
----                                                        ----------
LDAP://CN=spIntranetWA,OU=Dienstkonten,OU=HeadQuarter,... {logoncount, codepage, objectcategory, usnchanged...}

Damit habe ich schon mal ein paar Informationen.

Das funktioniert natürlich von jedem Arbeitsplatz mit PowerShell. Im Gegensatz zu den Active-Directory cmdlets verwende ich hier den ADSISearcher (dabei handelt es sich um ein Alias für die DirectorySearcher-Klasse aus dem .Net Framework). Das ist eine der genialen Dinge der PowerShell – ich kann mal eben so was aus dem .Net Framework verwenden. Um nun Objekte im Active-Directory zu suchen kann man dem ADSISearcher LDAP-Abfragen übergeben.

Insbesondere die Properties sind hierbei interessant. Die kann man sich auch etwas genauer ansehen.

C:\> $accounts = ([adsisearcher]"samaccountname=spIntranetWA").FindAll()
C:\> $accounts.properties

Name                           Value
----                           -----
logoncount                     {323}
codepage                       {0}
objectcategory                 {CN=Person,CN=Schema,CN=Configuration,DC=acme,DC=local}
usnchanged                     {15699245}
instancetype                   {4}
name                           {spIntranetWA}
pwdlastset                     {128843629222870406}
serviceprincipalname           {HTTP/sp01.acme.local, HTTP/intranet.acme.local}
objectclass                    {top, person, organizationalPerson, user}
samaccounttype                 {805306368}
lastlogontimestamp             {130265658248173942}
usncreated                     {19523}
dscorepropagationdata          {21.06.2013 13:56:40, 21.06.2013 12:28:23, 20.07.2012 09:54:16, 01.01.1601 18:16:33}
whencreated                    {16.04.2009 13:42:02}
adspath                        {LDAP://CN=spIntranetWA,OU=Dienstkonten,OU=HeadQuarter,DC=acme,DC=local}
useraccountcontrol             {590336}
cn                             {spIntranetWA}
countrycode                    {0}
primarygroupid                 {513}
whenchanged                    {18.10.2013 10:30:24}
lastlogon                      {130270479005600192}
distinguishedname              {CN=spIntranetWA,OU=Dienstkonten,OU=HeadQuarter,DC=acme,DC=local}
samaccountname                 {spIntranetWA}
objectsid                      {1 5 0 0 0 0 0 5 21 0 0 0 130 139 166 40 17 195 95 115 138 167 50 63 245 22 0 0}
displayname                    {spIntranetWA}
objectguid                     {217 8 220 57 70 168 118 76 178 20 180 160 198 219 146 67}
accountexpires                 {9223372036854775807}
userprincipalname              {spIntranetWA@acme.local}

Hier kann man auch den ServicePrincipleName ablesen. Der Rest ist dann nur noch ein wenig  PowerShell gefummel, um das ganze dann auch tabellarisch angezeigt zu bekommen.

C:\> ([adsisearcher]"samaccountname=sp*").FindAll()|select @{name='cn'; expression = {$_.properties['cn']}}, @{name="spn"; expression={$_.properties["ServicePrincipalName"]}}

cn                      spn
--                      ---
spCrawl
spDBAccount
spExtranetWA
spFarm
spInternetWA
spIntranetWA            {HTTP/sp01.acme.local, HTTP/intranet.acme.local}
spMySites
spSearch
spSPService

Lokalisierung in Office365

Und mal wieder eine (Erfolgs)Geschichte aus Office365 … also ich habe da so eine Mysite unter busitec-my.sharepoint.com. Die Mysite wurde ursprünglich in Englisch angelegt, und anschließend habe ich die Sprache auf „Deutsch“ umgestellt.

site_setting_locale

Wenn ich nun einen Blog anlege, dann ist der zunächst auf Englisch; kein Problem. Also Sprache auf Deutsch umstellen. Sieht ja alles Super aus – alles läuft; oder etwa nicht? Wenn ich nun in “Beiträge verwalten” gehe und mir alle Beiträge der Liste anzeigen lasse und dann einen einzelnen Beitrag anklicke …

post_error

Wow! Was ist denn das? Eine Fehlermeldung, und das bei O365? Wie kann denn das … und viel Interessanter ist ja noch, wenn ich den Beitrag direkt von der Startseite aus aufrufe, dann geht’s?!

OK – die Erklärung ist dann doch ganz schnell gefunden. Wenn ich den Beitrag von der Startseite aus aufrufe, dann sieht die URL wie folgt aus:

https://busitec-my.sharepoint.com/personal/eiben_busitec_de/Blog/Lists/Posts/Post.aspx?ID=1

Wenn ich aber über die Liste der Beiträge gehe und dann auf den Titel klicke wird diese URL aufgerufen:

https://busitec-my.sharepoint.com/personal/eiben_busitec_de/Blog/_layouts/15/listform.aspx?PageType=4&ListId=%7B36A2AAFB%2D5143%2D403F%2DA325%2DA7610CDE8EA6%7D&ID=1&ContentTypeID=0x01100007A0E26C347C5F4899398346B0DAF58B

…die dann einen Redirect auslöst auf:

https://busitec-my.sharepoint.com/personal/eiben_busitec_de/Blog/Lists/Beitraege/Post.aspx?List=36a2aafb%2D5143%2D403f%2Da325%2Da7610cde8ea6&ID=1&Source=https%3A%2F%2Fbusitec%2Dmy%2Esharepoint%2Ecom%2Fpersonal%2Feiben%5Fbusitec%5Fde%2FBlog%2FLists%2FPosts%2FAllPosts%2Easpx&ContentTypeId=0x01100007A0E26C347C5F4899398346B0DAF58B

Hier wird also die URL lokalisiert Smile ist zwar nett von SharePoint, dass er so viel wie möglich lokalisieren will – aber bitte doch nicht die URL. Denn eine Liste Beitraege gibt es nicht. Die würde es nur dann geben, wenn beim Anlegen der Site auch “Deutsch” ausgewählt gewesen wäre. Dann würde SharePoint die Namen der Listen an die Sprache anpassen.

Interessant ist IMHO, dass das listform.aspx (welches für den Redirect zuständig ist) nicht erkennt wie die Liste mit der ID 36A2AAFB-5143-403F-A325-A7610CDE8EA6 wirklich heißt.

Nachdem ich ja nun schon vor 3 Wochen einen Fehler in Nintex beim Auflösen von Gruppennamen und letzte und diese Woche einen Fehler in ShareGate beim kopieren von HTML-Inhalten gefunden habe, werde ich diesen Fehler auch mal versuchen an Microsoft zu melden – immer muss man alles selber machen.

Satya Nadella – Microsoft CEO

Es hat einige Monate gedauert, aber nun wissen wir bescheid. Satya Nadella ist seit gestern der neue CEO von Microsoft und damit der Nachfolger von Bill Gates und Steve Ballmer. Die wichtigsten offiziellen Infos dazu findet man in den Microsoft Company News und im TechNet Blog.

Satya Nadella

Besonder hinweisen möchte ich auf 3 Videos:

Partner Webcast:

 

Ein kurzes Interview mit Satya Nadella in den Company News:

 

Satya Nadella spricht zu Microsoft Angestellten im Studio B:

In ein paar Tagen lasse ich mich vielleicht auch zu einem Kommentar hierzu hinreissen… 🙂 …dann sicher per Podcast.

Wie geht´s weiter mit InfoPath?

Das Gerücht geht ja schon länger, dass wir uns in der nächsten Iteration des SharePoints leider von InfoPath verabschieden müssen. Das Feature wird „Deprecated“ und nicht mehr weiterentwickelt, bzw. nicht mehr Teil eines nächsten Releases sein.

Im  Office Blog gab es letzte Woche ein Post vom Office Team, das zumindest ein bißchen mehr Klarheit gebracht hat. Ein bißchen… 🙂

Wird uns so nicht mehr lange erhalten sein...

Wird uns so nicht mehr lange erhalten sein…

Die wichtigsten Aussagen sind:

  • Im Rahmen der SPC 2014 wird es eine Session geben, die einen Ausblick auf die Roadmap bezüglich Forms in SharePoint geben soll.
  • Wie lange dürfen wir es denn noch benutzen?
    How long will InfoPath be supported?

    • The InfoPath 2013 client will be supported through April 2023.
    • InfoPath Forms Services for SharePoint Server 2013 will be supported until April 2023.
    • InfoPath Forms Services in Office 365 will be supported until further notice.

    Das sagt nichts dazu aus, ob eine Lösung wenigstens die nächste Version noch ohne Migration überlebt. Klarer wird da schon folgendes Statement:

  • Will there be a migration tool or process for the next generation of forms technology?
    We’ll provide more details on migration scenarios and guidance in Q4 of CY 2014.
    Alles klar, es scheint darauf hinauszulaufen, dass ohne Migration nix mehr geht.
  • Zu Office 365 fällt folgendes Statement:
    The InfoPath Forms Services technology within Office 365 will be maintained and it will function until further notice.Hmmmm…..

Fazit: Es bleibt spannend. Microsoft wird uns möglicherweise 2015 etwas neues liefern. Im O365 wird es weiteren Support geben, allerdings keine Aussage, wie lange und in welcher Form. Der Client stirbt auf jeden Fall. Sind wir jetzt schlauer als vorher? Nein…. 🙁