Martin Hipfinger

es gibt öfters die situation, in der man die acl einer liste genauso setzen möchte, wie sie bereits bei einer anderen gesetzt ist – da wäre es doch fein, wenn man diese einfach kopieren könnte… genau dies ist mit dem tool sharepoint security cloner sehr einfach möglich.

wer stsadm verwenden muss, lieber einer gui als die command line hat, der sollte sich stsadmWin 2007 ansehen – ich selbst habe es nicht wirklich getestet, schaut aber nicht so schlecht aus:

STSADM Windows GUI

bei triplewood gibt es ein webpart im beta stadium zum download, welches auf silverlight basiert – das webpart ansich erfüllt (aus meiner sicht) keinen wirklich sinnvollen zweck – lässt aber hoffen, dass diesem bald weiteres folgen wird.

zumindest der breite einsatz von ajax wäre aus meiner sicht im sharepoint mehr als wünschenswert – silverlight (imho generell mit einem weit größeren potential als flash) kommt da in meiner wunschliste erst weit später; schon allein auch deshalb, weil man somit ein browser plugin als voraussetzung hat

schon lange vor dem sp1 für wss bzw moss gab es das hotfix package 937901, nach dessen installation eine “external storage api” zur verfügung steht.

doch wer glaubt, dass nach der installation irgendwo eine option zu finden ist, ob man die datenbank oder doch lieber irgendein filesystem zur ablage der dokumente verwenden möchte, der irrt leider gewaltig: out of the box gibt es diese funktionalität schlicht nicht, man kann weiterhin nur die datenbank verwenden.

auch microsoft gibt zu, dass der sql server nicht die beste wahl ist, um solche datenmengen abzulegen und schreibt dazu im wss 3.0 sdk unter “Overview of External BLOB Storage in Windows SharePoint Services“:

The problem, however, is that SQL Server is not the best option for storing unstructured binary data streams because unstructured binary data does not expose itself to the rich SQL query environment. In fact, store and retrieve operations for BLOB data in SQL Server are little more than simple get and put statements. Therefore, because BLOB data is not able to leverage one of SQL Server’s most useful features, its query engine, its value as a BLOB store is limited.

… microsoft bietet dazu allerdings keine fertige lösung, sondern mit dem fix nur eine api – sozusagen eine einladung an 3rd party hersteller hier eine lösung zu liefern. leider ist mir kein anbieter bekannt, der hier eine lösung hätte – wodurch ein nachteil des moss weiterhin bestehen bleibt: die dokumente können nur in der datenbank abgelegt werden (der einzige vorteil dieser lösung ist, dass man mit einem einfachen restore der datenbank einen konsistenten datenbestand hat)…

mit bginfo kann man allerhand wichtige informationen am desktop hintergrund darstellen – mit dem ebenfalls kostenlosen tool TSBACKDROP gibt es diese funktionalität in ähnlicher form nun auch für terminalserver und citrix sessions.

die informationen über die verbindung sollten den anwendern imho immer auf irgendeine art und weise zur verfügung gestellt werden, damit diesen das einmelden von vernünftigen störungen am helpdesk erleichtert wird – und hier kann dieses tool helfen.

… scheint so, als würde einer meiner größten kritikpunkte – die suche – bald geschichte sein: microsoft wird wohl “fast” kaufen und die technologie in sharepoint integrieren! obwohl ich “fast” bisher nicht kannte, scheint es auf jeden fall ein absoluter gewinn zu sein…
ms macht mal wieder keine halben sachen und stürzt sich mit vollem einsatz auf das thema 😉

wie werden eigentlich die informationen aus dem bdc auf feld-ebene gespeichert? schauen wir uns das anhand eines beispieles an:

nehmen wir an, wir haben folgenden bdc:
application: QueryDemoData
entity: Demo_Entity_ID
systeminstance: Demo_LobSystemInstance

dieser bdc wird in einem blog bei den posts verwendet – und zwar in der column namens “DemoID”. primär wird das gleichnamige bdc feld “DemoID” angezeigt, weiters noch “field two”.

schauen wir uns nun einen post mit der powershell an – holen wir uns zuerst den post mit der id nummer 2:

$SiteName = “http://mosstest/”
$WebName = “/blog/”
$ListName = “Posts”
$mossSite = new-object Microsoft.SharePoint.SPSite($SiteName);
$mossWeb = $MossSite.AllWebs[$WebName];
$mossList = $MossWeb.Lists[$ListName];
$item = $mossList.GetItemById(2)

und schauen uns einmal an, welche felder dieses item zu bieten hat:

$item.Fields | format-table InternalName

neben vielen anderen sind für uns nur folgende wichtig:

DemoID
Demo_Entity_DemoID_ID
Demo_x003a__x0020_field_x002

und im ersten schritt das feld “DemoID”:

$field = $item.Fields.GetFieldByInternalName(“DemoID”)

dieses feld hat den typ “BusinessData”, was man auch mittels

$field.TypeAsString

kontrollieren kann. der primäre bdc feldname ist “DEMOID”, und auch die systeminstance und entity ist vorhanden:

$field.BdcFieldName
$field.SystemInstanceName
$field.EntityName

bleiben nur noch die zusätzlichen felder – hier “FIELDTWO” (der zugehörige wert wird nach dem query in dem feld “Demo_x003a__x0020_field_x002” gespeichert):

$field.GetSecondaryFieldsNames()

und die kontrolle, ob es zugehörige actions gibt:

$field.HasActions

das fast wichtigste feld ist allerdings “Demo_Entity_DemoID_ID” – schauen wir uns den inhalt an:

$item.GetFormattedValue(“Demo_Entity_DemoID_ID”)

der inhalt ist z.b. “__bk43003600f600f600c6009700f6005700b600e600f600770036003200” – es handelt sich um eine encodede version des in diesem post verwendeten identifier keywords; mir ist allerdings keine möglichkeit bekannt, wir man den string in der powershell decoden oder gar ein neues keyword (um über die powershell neue documente mit befülltem bdc erstellen zu können) encoden könnte…

dazu muss man c# bemühen:

folgende references einbinden:
– Microsoft.Office.Server
– Microsoft.Sharepoint
– Microsoft.Sharepoint.Portal

und dann brauchen wir:
using Microsoft.Office.Server.ApplicationRegistry.Administration;
using Microsoft.Office.Server.ApplicationRegistry.Infrastructure;

und schon können wir encoden und decoden:
EntityInstanceIdEncoder.EncodeEntityInstanceId(new object[] { “coolyouknowc#” })
EntityInstanceIdEncoder.DecodeEntityInstanceId(“__bk43003600f600f600c6009700f6005700b600e600f600770036003200” )

“viele änderungen benötigen einen iisreset um übernommen zu werden” – stimmt das?

nicht immer! meistens reicht es völlig aus, nur die application pools und nicht gleich den ganzen iis zu recyclen – und das geht so:

cscript.exe %windir%\system32\iisapp.vbs /a “your application pool” /r

der vorteil: das geht wesentlich schneller als ein iisreset, ist diesem also vorzuziehen!

will man mit der powershell in einer wiki ein dokument hinzufügen, so kann man dies nicht Microsoft.SharePoint.SPListItem Add() erledigen, weil es sich bei der wiki ja um eine document library handelt (die wiki seiten sind nichts anderes als aspx dokumente!) – daher schlägt folgendes fehl:

# vars

$SiteName = “http://mosstest/”
$WebName = “/Wiki/”
$ListName = “Wiki Pages”

# connect to sharepoint and open the wiki list

$mossSite = new-object Microsoft.SharePoint.SPSite($SiteName);
$mossWeb = $MossSite.AllWebs[$WebName];
$mossList = $MossWeb.Lists[$ListName];

“Got List…”

# try to add a new item

$item = $mossList.Items.Add()
$item.Update();

Exception calling “Update” with “0” argument(s): “To add an item to a document library, use SPFileCollection.Add()”
At line:1 char:13
+ $item.Update( <<<< );

die fehlermeldung ist eigentlich eindeutig; wie macht man es nun richtig? so:

# vars

$SiteName = “http://mosstest/”
$WebName = “/Wiki/”
$ListName = “Wiki Pages”

# connect to sharepoint and open the wiki list

$mossSite = new-object Microsoft.SharePoint.SPSite($SiteName);
$mossWeb = $MossSite.AllWebs[$WebName];
$mossList = $MossWeb.Lists[$ListName];

“Got List…”

# try to add a new item

[byte[]]$mydata = “hipslu was here”.ToCharArray(); # dummydata
$newFile = $mossList.RootFolder.Files.Add(“newwikientry.aspx”, $mydata);

allerdings wird in diesem beispiel natürlich keine richtige wiki seite erstellt – für einen ernsthafen einsatz muss die variable $mydata einen entsprechend sinnvollen inhalt haben (oder man kopiert den wiki eintrag von woanders her)

um die powershell verwenden zu können, sind folgende vorbereitungen notwendig:
download und installieren der powershell auf einem server, auf dem auch moss installiert ist
– öffnen der powershell und absetzen des folgenden befehls:

set-executionpolicy RemoteSigned

dies ist optional und bewirkt, dass lokale scripts nicht signiert sein müssen
– absetzen der beiden folgenden befehle:

[System.Reflection.Assembly]::Load(”Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”)
[System.Reflection.Assembly]::Load(”Microsoft.SharePoint.Portal, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”)

der output sollte wie folgt aussehen:

GAC Version Location
— ——- ——–
True v2.0.50727 C:\WINDOWS\assembly\GAC_MSIL\Microsoft.SharePoint\12.0.0.0__71e9bce111e9429c\Microsoft.SharePo…

GAC Version Location
— ——- ——–
True v2.0.50727 C:\WINDOWS\assembly\GAC_MSIL\Microsoft.SharePoint.Portal\12.0.0.0__71e9bce111e9429c\Microsoft….

… um das nicht jedes mal eingeben zu müssen, erstellt man unter “C:\Documents and Settings\username\My Documents\” ein neues verzeichnis names “WindowsPowerShell” und darin eine datei namens “Microsoft.PowerShell_profile.ps1” – in diese datei fügt man nun diese beiden zeilen ein.

das war bereits alles! in den folgenden posts werde ich beispiele zeigen, was man nun mit der powershell so alles machen kann.