Diese Neuerungen bringt Windows Server 2012

Input/Output Operations Per Second
Windows Server 2012 hat gemäss Microsoft nun mit Abstand die beste IO Performance und schafft bis zu 1'000'000 IOPs auf einer einzelnen virtuellen Maschine. Zum Vergleich: VMware vSphere 5 schaffte im Test von Microsoft 300'000 IOPs.

Remote Desktop Services
Der Nachfolger von RDP heisst RemoteFX und besticht durch einen minimalen Verbrauch an Bandweite und ruckelfreier Grafikdarstellung, selbst bei HD Videos.
http://www.microsoft.com/en-us/server-cloud/windows-server/virtual-desktop-infrastructure-features.aspx

Remote Server Administration Tools
Mit den Remote Server Administration Tools for Windows 8 können die Server Rollen und Features auch bequem von einem Windows 8 Client aus verwaltet werden.
http://technet.microsoft.com/en-us/library/hh831501.aspx

Server Manager
Mit dem neuen Server Manager können Rollen und Features remote von einem Server oder Client konfiguriert und einem Server oder einer Servergruppe zugewiesen werden. Der Server Manager bietet zudem ein Dashboard, das alle relevanten Informationen zu den verwalteten Server anzeigt.
http://technet.microsoft.com/en-us/library/hh831456.aspx

Resilient File System (ReFS)
Das Resilient File System (ReFS) bietet bessere Kompatibilität mit SATA Standards und Korruptionsschutz bei Stromausfällen. CHKDSK wurde bei dieser Gelegenheit massiv verbessert und benötigt neu statt Stunden nur noch einige Sekunden, um korrupte Daten zu beheben.
http://www.microsoft.com/en-us/server-cloud/windows-server/storage.aspx

Data Deduplication
Data Deduplication arbeitet blockorientiert, löscht mehrfach vorhandene Daten und referenziert diese zu einer einzelnen Dateneinheit.
http://www.microsoft.com/en-us/server-cloud/windows-server/storage.aspx

Virtualisierung mit Hyper-V
Hyper-V macht mit Windows Server 2012 nochmals einen riesigen Schritt vorwärts und ist nun endlich auf Augenhöhe mit VMware. So werden neu bis zu 320 logische Prozessoren, 2048 virtuelle Prozessoren und 4 TB RAM pro Host, 64 virtuelle Prozessoren und 1 TB RAM pro virtuelle Maschine, 64 Cluster-Nodes mit 3000 virtuellen Maschinen unterstützt. Weiter wurde die Virtual Hard Disk (VHD) überarbeitet, welches neu im Format VHDX daherkommt. VHDX kann bis zu 64 TB gross werden, bietet Schutz vor korrupten Daten und ist optimiert für Large Sector Disks (4 KB disk sectors). Weitere wichtige Neuerungen sind die unterbruchslose Migration von Virtual Hard Disks, die Shared Nothing Live Migration, Quality of Service minimum Bandwidth, die dynamische RAM Zuteilung, das NIC Teaming, PowerShell Automation sowie der Non-Uniform Memory Access (NUMA) und Virtual Fibre Channel Support.
http://technet.microsoft.com/en-us/library/hh831410

Virtual Desktop Infrastructure
In Virtual Desktop Infrastructure Umgebungen stehen neu User Profile Disks zur Verfügung, welche alle Benutzereinstellungen und Daten speichert. Fair Share ist eine weitere Neuerung und verteilt dynamisch die Ressourcen (RAM, Disk I/O, Bandweite) zwischen den virtuellen Maschinen und RDS Sessions.
http://www.microsoft.com/en-us/server-cloud/windows-server/virtual-desktop-infrastructure-features.aspx

Windows PowerShell 3.0
Microsoft baut auch im Windows Server 2012 die PowerShell Funktionalitäten aus. Neu lassen sich alle Funktionen des Betriebsystems via PowerShell steuern, sei dies lokal oder remote. Mit der neuen Version kommt auch Windows PowerShell ISE 3.0, in welcher vorallem die Intellisense Fuktion hervorsticht. Diese zeigt dem Benutzer direkt bei der Eingabe Vorschläge, bietet die Autovervollsändigung an und zeigt Informationen zum Syntax des entsprechenden Cmdlets.


The license state for the server doesn’t match the farm’s license state

Wird versucht, ein Server mit einer SharePoint Server 2010 Standard Lizenz einer bestehenden SharePoint 2010 Farm mit aktivierten Enterprise Features hinzuzufügen, erscheint beim Farm Join Versuch folgende Fehlermeldung:

Configuration Failed

One or more configuration settings failed. Completed configuration settings will not be rolled back. Resolve the problem and run this configuration wizard again. The following contains detailed information about the failure:

Failed to connect to the configuration database.

An exception of type System.InvalidOperationException was thrown. Additional exception information:
The current server cannot be joined to this farm because the set of installed products does not match the products installed in the farm.

The license state for the current server doesn’t match the farm’s license state.

Eigentlich logisch, dass das nicht funktioniert. Kann aber schon mal vorkommen, wenn nicht sauber dokumentiert wird ;) Die "Lösung" ist hier leider eine Deinstallation und Neuinstallation von SharePoint auf dem betroffenen Server, da der Lizenzschlüssel im Nachhinein nicht mehr geändert werden kann.


Benutzer sehen keine Metadaten Felder (Column Values)

Falls SharePoint Benutzer keine Metadaten Felder oder Enterprise Keywords sehen können, obwohl diese offensichtlich auf der entsprechenden Liste oder Library hinterlegt wurden, kann dies damit zu tun haben, dass die Berechtigungen in der TaxonomyHiddenList falsch gesetzt sind. Diese Liste steuert, wer ganz grundsätzlich Metadaten sehen darf und wer nicht. Unabhängig von den Berechtigungen auf der anzuzeigenden Liste oder Library. Ein weiteres Indiz dafür kann sein, dass Site Collection Administratoren die Metadaten sehen, nicht aber eben die User.

  • Um dies zu überprüfen rufen Sie http://<SiteCollectionURL>/Lists/TaxonomyHiddenList (ersetzen Sie <SiteCollectionURL> durch die URL der entsprechenden Site Collection).
  • Navigieren Sie im Ribbon auf List Tools > List > List Settings.
  • Unter Permissions and Management wählen Sie Permissions for this list

Standardmässig sind folgende Berechtigungen gesetzt:

Ist dies bei Ihnen nicht der Fall, dann fügen Sie alle Benutzer hinzu, in dem Sie z.B. im Ribbon auf Edit > Grant Permissions klicken und dort der Gruppe NT AUTHORITY\authenticated users die Berechtigung Read vergeben.

Nun sollten alle Benutzer die hinterlegten Metadaten in den Listen und Libraries sehen können.


Korrupte (Search) Service Application mittels PowerShell löschen

Bei der Arbeit mit Service Applications in SharePoint 2010 kann es manchmal vorkommen, dass diese in einen korrupten Status verfallen und gelöscht werden müssen. Besondere "Problemfälle" sind hierbei sicherlich die Search Service Application und die User Profile Service Application. Zumal oftmals nicht nur die Reparatur sondern auch das Löschen eine Herausforderung darstellt.
Kann eine Service Application nicht über die Benutzeroberfläche, das GUI, gelöscht werden, sollte spätestens dann zu PowerShell und STSADM gegriffen werden.

Service Application löschen

  • SharePoint 2010 Management Shell mit administrativen Rechten ausführen.
  • Get-SPServiceApplication listet alle Service Applications mit deren GUID auf. Kopieren Sie die GUID der zu löschenden Service Application - in meinem Beispiel 07b0d35f-9d10-44ec-a049-e09cc2219718
  • Führen Sie den Befehl Remove-SPServiceApplication -id 07b0d35f-9d10-44ec-a049-e09cc2219718 -RemoveData (ersetzen Sie die GUID durch Ihre eigene). Der Parameter -RemoveData löschen nebst der Service Application auch die darin enthaltenen Daten.
  • Bei hartnäckigen Service Applications, bei denen auch die Löschung mittels PowerShell nicht erfolgreich ist, kann alternativ auch der STSADM-Befehl ausgeführt werden, welcher in gewissen Situationen etwas härter durchgreift:
    Stsadm -o deleteconfigurationobject -id 07b0d35f-9d10-44ec-a049-e09cc2219718 (ersetzen Sie die GUID durch Ihre eigene)

In einigen Fällen kann es vorkommen, dass auch mit diesen Methoden das Löschen einer Service Application scheitert. Ist dies der Fall, sollte als nächstes geprüft werden, ob die Service Application in einem eigenen Application Pool läuft. Ist dies der Fall, kann wie in diesem Artikel beschrieben vorgegangen werden um das Problem eine Ebene tiefer zu lösen: Application Pool in SharePoint 2010 (anhand seiner ID) löschen

 


Log File Verzeichnisse aller IIS Sites per PowerShell anpassen

Standardmässig werden alle Logs des IIS auf dem Laufwerk C: abgelegt. Dies ist jedoch nicht empfehlenswert, weil dadurch einerseits Performance verloren geht (je nach Konfiguration) und andererseits besteht die Gefahr, dass das Systemlaufwerk voll läuft und das OS somit zum Absturz gebracht wird.

Wie die IIS Logs für einzelne IIS Sites verschoben werden können, ist hier beschrieben: IIS Log Files (mittels PowerShell) verschieben

IIS Logs verschieben
Kopieren Sie nachstehenden Code in ein Textfile (z.B. Notepad) und ändern Sie den Pfad in der zweiten Zeile. Speichern Sie die Datei als PS1, indem Sie die Dateiendung von dateiname.txt auf dateiname.ps1 ändern. Führen Sie die Datei dateiname.ps1 auf dem Server, auf welchem die Log Files aller IIS Sites verschoben werden sollen, als Administrator aus.
Das Script erstellt unter dem angegebenen Pfad - in meinem Beispiel D:\Logs pro IIS Site ein gleichnamiges Verzeichnis. Anschliessend wird der Logpfad für jede IIS Site auf das jeweilige Verzeichnis angepasst. In diesem Beispiel wäre dies somit D:\Logs\SiteName

Import-Module WebAdministration
$LogPath = "D:\Logs"
foreach($site in (dir iis:\sites\*))
{
New-Item $LogPath\$($site.Name) -type directory
Set-ItemProperty IIS:\Sites\$($site.Name) -name logFile.directory -value "$LogPath\$($site.Name)"
}