SharePoint 2013 – Aufgabenliste verschickt keine E-Mails mehr?!

Seit SharePoint 2013 fehlt in den Einstellungen einer SharePoint Aufgabenliste die Option „Send e-mail when ownership is assigned? (Yes/No).“. Ich vermute einen Bug in der Oberfläche, der eventuell irgendwann wieder rausgepatchet wird. Nichts desto trotz schreibe ich einen kurze Artikel, wie man dieses Phänomen beheben kann.

Es gibt verschiedene Lösungsansätze, die ich hier kurz darstelle. Eins vorweg: Die Option 3 wäre immer meine erste Wahl!

1. Issue-List beinhaltet die Option noch
Also anstelle der Aufgabenliste das o.g. Template nutzen (vgl. Technet ).

2. Das „alte“ Template verwenden:
Über einen URL-Aufruf kann das „alte“ 2010er Template aufgerufen werden. (vgl. TechNet)
http://siteurl/_layouts/15/new.aspx?FeatureID={00BFEA71-A83E-497E-9BA0-7A5C597D0107}&ListTemplate=107

3. Powershell
Aus meiner Sicht die sauberste und beste der drei Alternativen. Benötigt natürlich Zugriff auf den Server, bzw. Zugriff auf einen Administrator. 😉

$web = Get-SPWeb "http://MeineWebseite"
$list = $web.Lists.TryGetList("Tasks")
$list.EnableAssignToEmail = $true
$list.Update()

Schnell mal ActiveDirectory

Gerade in Verbindung mit SharePoint braucht man ja auch häufig ein Active Directory. Also gehört es zur Pflicht-Übung für ein Demo-System auch schnell mal ein AD aufzusetzen.

Das ist im Kern nicht so wirklich schwer – besonders wenn es ja nur zu Demo-Zwecken ist. Aber irgendwie lästig ist es ja doch.

Zuerst muss man das entsprechende Feature in Windows hinzufügen:

Import-Module servermanager
Add-WindowsFeature adds-domain-controller

Anschließend muss dann noch die Domäne angelegt werden. Also hier mal eben die Anlage eines neue AD per Kommandozeile. Einfach auf einem Windows 2008 Server (oder neuer) ausführen:

# Windows Server 2008
 $unattend = "c:\unattend.txt"
if(!(test-path $unattend)) { new-item $unattend -type file }
$content = @(
    "[DCInstall]"
    "ReplicaOrNewDomain=Domain"
    "NewDomain=Forest"
    "NewDomainDNSName=acme.local"
    "ForestLevel=4"
    "DomainNetbiosName=ACME"
    "DomainLevel=4"
    "InstallDNS=Yes"
    "ConfirmGc=Yes"
    "CreateDNSDelegation=No"
    'DatabasePath="C:\Windows\NTDS"'
    'LogPath="C:\Windows\NTDS"'
    'SYSVOLPath="C:\Windows\SYSVOL"'
    'SafeModeAdminPassword="P@ssw0rd1"'
    "RebootOnCompletion=Yes"
    )
$content | out-file $unattend
$dcpromo = "dcpromo /unattend:$unattend"
invoke-expression -command $dcpromo

ggf. müssen die Angaben zur Domäne noch angepasst werden.

Unter Windows Server 2012 geht das etwas kürzer, hier gibt es ein entsprechendes PowerShell cmdlet.

Install-ADDSDomainController -CreateDnsDelegation:$false -DatabasePath 'C:\Windows\NTDS' -DomainName 'acme.local' -InstallDns:$true -LogPath 'C:\Windows\NTDS' -NoGlobalCatalog:$false -SiteName 'Default-First-Site-Name' -SysvolPath 'C:\Windows\SYSVOL' -NoRebootOnCompletion:$true -Force:$true

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

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…. 🙁

Virenscanner für SharePoint 2013

Seit dem Release von SharePoint 2013 ist die Gemengelage nicht immer übersichtlich gewesen, wenn es um den Virenschutz innerhalb von SharePoint ging. Nach der Abkündigung von ForeFront als einfache und umfassende Lösung, gab es zunächst keine Lösung eines großen Herstellers mehr, die für SharePoint 2013 verfügbar war.

Prinzipiell ist das Thema Virenschutz mit SharePoint immer noch erklärungsbedürftig. Bei vielen Kunden treffe ich auf SharePoint Installationen, die lediglich vom üblichen Dateisystem Scanner geschützt sind. Dateisystemscanner erfassen aber lediglich die Dateien auf den Volumes der Systeme, helfen also bei Downloads auf der Konsole oder beim Anstecken eines USB Sticks an den Server. Dokumente und Dateien, die über http in den SharePoint kommen werden von diesen Scannern gar nicht erfasst, da sie direkt in die Datenbanken geschrieben werden. Wenn man in diese Rechnung nun noch Clients aufnimmt, z. B. von externen Teilnehmern, für die man keinen aktuellen und umfassenden Virenschutz sicherstellen kann, dann finden sich in den SharePoint Bibliotheken relativ schnell jede Menge kleine Zeitbomben ein. Es lohnt sich also, auch hier zu investieren.

Oftmals sind die Dateisystem Scanner noch nicht einmal richtig konfiguriert und scannen prinzipiell alles im Realtime Scan, was die Performance von SharePoint erheblich beeinflussen kann. Für den Scanner auf dem SQL Server gilt prinzipiell das gleiche. Auch hier ist der Performance Impact erheblich.

Hier noch einmal die gängigen Einstellungen für „normale Dateisystem Scanner“:

Auf dem SQL Server sollten alle Ordner in denen sich die Datenbank .mdf Dateien, die temporären Dateien .mdf und die Logfiles .ldf Dateien befinden, von den Realtime Scans und automatisierten Scans ausgeschlossen sein. Ebenso die entsprechenden Dateiendungen .mdf und .ldf.

Auf dem SharePoint Server sollten folgende Elemente vom Virenscan ausgeschlossen werden:

  • c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions
  • c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files
  • c:\ProgramData\Microsoft\SharePoint
  • c:\WINDOWS\system32\LogFiles
  • c:\Windows\Syswow64\LogFiles

Für die SharePoint Service Accounts:

  • c:\Users\“ServiceAccount“\AppData\Local\Temp\WebTempDir
  • c:\Users\“search ServiceAccount“\AppData\Local\Temp
  • c:\Users\“ServiceAccount“\AppData\Local\Temp
  • c:\Users\Default\AppData\Local\Temp

Weitergehende Artikel dazu finden sich im TechNet.

Marktübersicht (alphabetisch):

Jetzt ist ein gutes Jahr ins Land gezogen und da bietet es sich an, noch einem einen Blick auf den Markt zu werfen. Welche Hersteller bieten aktuell eine Lösung an, bzw. welche Hersteller haben eine Lösung in Planung?

Avast! File Server Security

Bietet für den Dateisystem Scanner ein Plugin zur Integration in die SharePoint Schnittstelle. Hier der Link zur Website ->

AVG AntiVirus File Server Edition

Bietet „SharePoint Kompatibilität“ bis SP2010. Was auch immer das heißen soll, ob es ein zusätzliches Plugin ist bleibt offen. Also keine SharePoint 2013 Lösung. Hier der Link zur Website ->

Avira

Bietet keine SharePoint Lösung

Bitdefender Security for SharePoint

Ist verfügbar. Leider sind auch hier die deutschsprachigen Informationen veraltet. Hier der Link auf die US-Website ->

ESET Security for Microsoft SharePoint Server

Zum Jahresanfang die erste Beta für SP2013, inzwischen verfügbar. Hier der Link zur Website ->

Kaspersky Security for SharePoint Server

Liefert seit kurzem SharePoint 2013 Support. Die Informationen auf der deutschen Seite sind leider veraltet. Hier der Link auf die US Website ->

McAfee Security for SharePoint

Seit Sommer verfügbar. Die deutschsprachige Seite bietet nur Informationen für Endanwender, daher hier der Link auf das englischsprachige Angebot ->

Sophos Server Security for SharePoint

Bietet leider nur einen Schutz bis SP2010. Ein Statement aus dem Sommer besagte „second half of 2013“. Die ist ja nun fast vorbei.

Symantec Protection for SharePoint Servers

Ist seit dem Sommer verfügbar und unterstützt SP2013 im neuesten Release. Zur Produktseite des Herstellers ->

Trendmicro PortalProtect Sharepoint Security

Kam nach einer kurzen RTM Phase im Juni wurde es im Sommer veröffentlicht. Leider gibt die deutsche Produktseite keine Infos dazu, daher hier der Link auf die US Seite ->

Fazit:

Es gibt eigentlich von fast allen bekannten Herstellern Lösungen um SharePoint umfassend gegen Viren und Malware zu schützen. Wichtig ist neben einem geeigneten Scanner auch die korrekte Konfiguration, dann steht einem sichern SharePoint nichts im Wege.

 

Kein ULS Logging in SharePoint

Es kommt immer mal wieder vor, dass auf einem SharePoint-Server die ULS Logs leer sind. SharePoint erstellt zwar alle 30 Minuten ein neue Logdatei, aber die Dateien haben immer eine Größe von 0 Byte. Wie kann das sein?

Zuerst dachte ich, dass das Loglevel einfach falsch eingestellt ist, und dass keine Ereignisse in das Log geschrieben werden – das war aber in meinem aktuellen Fall nicht so. Was kann es dann sein?

Aus Verzweiflung habe ich einfach mal den SharePoint 2010 Tracing Service neu gestartet – und da kamen auch schon wieder Einträge ins Log. Aber meine Freude war nicht von langer Dauer – nach ein paar Sekunden wurde keine neuen Einträge mehr geschrieben.

Aber da – auf einmal stand die Lösung heraus:

Not enough free disk space available. The tracing service has temporarily stopped outputting usage entries to the usage log file. Usage logging will resume when more than 1124 MB of disk space becomes available.

Mal eben schnell auf die C: Platte geschaut – und da waren nur 600MB freier Speicher; offenbar nicht genug für SharePoint. Nachdem ich also ein paar hundert MB gelöscht hatte ging es auch mit dem Logging wieder weiter:

The tracing service has resumed outputting trace messages to the log file.
The usage logging has resumed.

Cool!

SharePoint 2013 / Office 365 (Beta) & Website Mailbox

Heute habe ich mich wieder mit einer interessanten Neuerung in SharePoint 2013, dieses Mal im Gewand von Office 365, beschäftigt. Konkret geht es um die Website Mailbox. Mit dieser ist es möglich, jeder SharePoint Webseite eine eigene, gemeinsam genutzte Exchange Mailbox zuzuweisen. Administratoren und Mitglieder (dies bezieht sich auf die korrespondierenden SharePoint-Gruppen) der Webseite können dann gemeinsam auf Emails, die an die Mailbox geschickt werden, zugreifen, diese bearbeiten oder beantworten. Die Mailbox könnte zum Beispiel auf einem Projektarbeitsbereich, vielleicht auch als Support-Mechanismus oder Ticketsystem genutzt werden. Continue reading

SharePoint 2013 (Beta) & Continuous Crawling

Ein neues Feature in SharePoint 2013 (oder SharePoint 15 Smiley ) ist das “Continuous Crawling” von Inhaltsquellen der Suche. Die Konfiguration dieses Features geht leicht von der Hand und wird jedem ins Auge gefallen sein, der bereits die SharePoint 15 Suche installiert und konfiguriert hat.

Sobald eine neue Inhaltsquelle eingebunden wird, kann im Bereich “Crawl Schedules” die Option “Enable Continuous Crawls” aktiviert werden.

image Continue reading

SharePoint 2013 (Beta) – Installation & Konfiguration der Search Service Application

Nachdem ich jetzt ein paar Testinstallationen von SharePoint durchgeführt habe, wollte ich kurz meine ersten Erfahrungen festhalten.

Die Installationsroutine von SharePoint 2013 verläuft an sich genauso wie die Installationen von SharePoint 2010. Ebenso hat sich die Oberfläche der Zentraladministration (vom Metro-Style mal abgesehen) nur marginal verändert und die Implementierung der Dienstanwendungen verläuft ebenfalls nahezu analog zu SP2010. Die verantwortlichen Personen wird es freuen, da die Einarbeitung doch deutlich vereinfacht wird. Das heißt allerdings auch, dass die “Problemkinder” (z.B. der Benutzerprofildienst oder die Suchdienstanwendung) weiterhin Kopfschmerzen verursachen können und werden.

Einer meiner ersten Schritte bei der Konfiguration einer SharePoint Infrastruktur ist das Aufsetzen der Suchdienstanwendung. Dies kann, je nach vorhandener Infrastruktur durchaus auch mal länger dauern. Hier gibt es verschiedene Ansätze, die Dienstanwendung zu implementieren: Continue reading

SharePoint August 2012 CU

Die August 2012 CU Pakete für SharePoint 2010 sind mittlerweile verfügbar. Die CUs setzen das Service Pack1 voraus und bringen alle vorherigen CUs gleich mit. Desweiteren gibt es nur noch eine Datei, die ausgeführt werden muss, je nach Installationsszenario.

Folgende Pakete sind verfübar:

SharePoint Foundation 2010 cumulative update package (SharePoint Foundation server-package): August 28, 2012KB Artikel

SharePoint Server 2010 cumulative update package (SharePoint server-package): August 28, 2012KB Artikel

SharePoint Server 2010 with Project Server cumulative update package (SharePoint with Project server-package): August 28, 2012KB Artikel (noch nicht verfügbar)

Wie immer, viel Freude beim Update!!! 🙂

Natürlich erfordert das CU einen Neustart des User Profile Sync Dienstes…Viel Glück!