sharepointszu

NOT Just another SharePoint Blog, this is a Swiss SharePointCommunity Blog

Posts Tagged ‘Anleitung

SQL Server Maintenance für SharePoint

leave a comment »


Was immer mal wieder gefragt wird ist, was man denn genau für SharePoint Datenbanken für Maintenance Tasks machen muss und welche Operationen auf SharePoint Datenbanken erlaubt sind und welche nicht.

Ich habe im Folgenden mal alles, was eigentlich auch im Technet bekannt aber verstreut oder unübersichtlich ist, zusammengefasst. Zusätzlich gibt es einen SQL Best Practice Skript, der die benötigten Aktionen automaisch erstellt. Viel Spass beim lesen

So long, Samuel

Inhalt

1       Database Maintenance Plan for SharePoint. 2

1.1        Databases in SharePoint 2013. 2

1.2        Database Maintenance. 4

1.3        Supported and Unsupported Chagnes on SharePoint DBs. 5

1.3.1         Unsupported Database Changes. 5

1.3.2         Supported database modifications. 6

1.3.3         Read operations addendum.. 7

2       SQL Maintenance Script7

 

 

 

 

1         Database Maintenance Plan for SharePoint

1.1         Databases in SharePoint 2013

Source: http://technet.microsoft.com/en-us/library/cc678868(v=office.15).aspx

Database Recommended Recovery Model Backup Method Size Characteristics Notes
Config Simple SP BackkupSQL Backup Small Read intensisve
  • Must be Co-Located with CA DB
  • Recovery Model must be full for Mirroring
  • Scale up, only one DB per Farm
Central Administration Content Full SP BackupSQL Backup Small Varies
  • Must be Co-Located with Config DB
  • Can grow over the period of 365 days if Power Pivot is used
  • Scale up, only one DB per Farm
Content Databases Full SP BackupSQL Backup Small to Big Varies by Usage
  • Limit Size to 200GB per Content DB
  • Scale out, Scale up (a Site Collection can sit in only 1 DB)
App Management Full SP BackupSQL Backup Small Write heavy
  • Only write heavy during App installation
  • Scale up, Scale out only on Office 365
Business data Connectivity Full SP BackupSQL Backup Small Read heavy
  • Scale up, only one DB per Farm
Search – Admin Simple SP BackupSQL Backup Medium Read Write
  • Scale up, Scale out only by creating additional Service Applications
Search – Analytics Simple SP BackupSQL Backup Medium to Large Write heavy
  • Nightly Analytics update
  • Scale out by Split Operation when DB becomes > 200GB
Search – Crawl Simple SP BackupSQL Backup Medium Read heavy
  • Scale out by creating new DBs for every 20mio Items crawled
Search – Link Simple SP BackupSQL Backup Medium to Large Write heavy
  • Affected by Content processing
  • Scale out by creating new DBs for 60mio Items crawled and for expected 100mio querys per year
Secure Store Full SP BackupSQL Backup Small Equal Read Write
  • Scale up, Scale out by creating new Service Applications
Usage Simple SQL Backup XLarge Write heavy
  • Scale up, only one DB per Farm
Subscription Settings Full SP BackupSQL Backup Small Read heavy
  • Scale up, Scale out by creating new Service Applications
User Profile – Profile Simple SP BackkupSQL Backup Medium to Large Read heavy
  • Scale up, Scale out by creating new Service Applications
User Profile – Sync Simple SP BackupSQL Backup Medium to Large Equal Read Write
  • Scale up, Scale out by creating new Service Applications
User Profile – Social Simple SP BackupSQL Backup Small to XLarge Read heavy
  • Scale up, Scale out by creating new Service Applications
Word Automation Full SP BackupSQL Backup Small Read heavy
  • Scale up, Scale out by creating new Service Applications
  • Traffic is Affected by Word Conversions only
Managed Metadata Full SP BackupSQL Backup Medium Read heavy
  • Scale up, Scale out by creating new Service Applications
Machine Translation Full SP BackupSQL Backup Small Read heavy
  • Scale up, Scale out by creating new Service Applications
Project Server Full SP BackupSQL Backup Small to Medium Read heavy
  • Scale up
  • One Database per Project WebApp
PowerPivot Full SP BackupSQL Backup Small Read heavy
  • Scale up
Performance Point Full SP BackupSQL Backup Small Read heavy
  • Scale up, Scale out by creating new Service Applications
State Service Full SP BackupSQL Backup Medium to Large Read heavy
  • Scale out by creating additional Databases
Master Simple SQL Backup Small Varies
Model Full SQL Backup Small Varies
Msdb Simple SQL Backup Small Varies
Tempdb Simple SQL Backup Medium Varies
  • Locate on fast Disks and split Database to several Datafiles
Report Server – Catalog Full SQL Backup Small Read heavy
  • Scale Up
Report Server – Temp Full SQL Backup Small to XLarge Read heavy
  • Scale Up
Report server – Alerting Full SQL Backup Small to XLarge Equal Read Write heavy
  • Scale Up
  • Must be on same Server as the Repprt Server – Catalog

1.2         Database Maintenance

Source: http://technet.microsoft.com/en-us/library/cc262731(v=office.14).aspx

These advices were published for SharePoint 2010 but mainly still apply for SharePoint 2013. Only the Timer Jobs might have changed that do automatic Index Maintenance. For all Databases that are used for SharePoint 2013 Content do regularly Database Maintenance.

Action Databases Frequency Notes
DBCC CHECKDB All SharePoint DBs Weekly of before each Full Backup
  • You cannot run DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS.
  • You can run DBCC_CHECKDB WITH REPAIR_FAST and REPAIR_REBUILD
Index Rebuilding All SharePoint DBs Depends on:-          If Database has a Timer Job

-          Fragmentation Level

 

Fragmentation methods

 

Fragmentation level Defragmenta-tion method
Up to 10% Reorganize (online)
10-75% Rebuild (online)
75% Rebuild (offline)
  • Online Index Rebuild only for SQL Enterprise
  • Fallback from Online to Offline Index Rebuild might occur on special occasions (e.g. for LOB Columns)
  • Many of the SP Indexes are rebuilt Offline because of LOB Content (like documents, Pictures etc.)
  • Offline and Online Index Rebuild result in Locks or inaccessibility of Indexes and should therefore be done in low activity times
  • Use “sys.dm_db_index_physical_stats” to measure Fragmentation. Values from 0 to 10 in Column “avg_fragmentation_in_percent” are acceptable
  • SharePoint Timer Jobs (Health Rules) are doing a part of Index defragmentation and Stats updates
  • Timer Jobs look for its associated databases and performs proc_DefragmentIndices stored procedure on int. Indexes with Fragmentation > 30% are considered for reindex
  • Not all Databases have Timer Jobs and should be monitored manually
  • Using DROP INDEX or CREATE INDEX Operations are NOT supported on SharePoint Databases
AutoShrink All SharePoint DBs Never
  • Better Solution is to create a new database, move the Site Collections and delete the old database
  • Only if there is definitely a very high amount of unused space and you do not plan to reuse it and only for Content Databases
  • EMPTYFILE Option is not supported
  • TRUNCATEONLY Option is not supported
Maintenance Cleanup All SharePoint DBs Weekly or with scheduled maintenance plans

 

1.3         Supported and Unsupported Chagnes on SharePoint DBs

The Microsoft Office server products store data in Microsoft SQL Server databases. These products use various stored procedures for regular processing. Therefore, the Microsoft SQL Server databases are important to the successful operation of these products.

SharePoint Products were tested by using a database structure as designed by the SharePoint Development Team and were approved for release based on that structure. Microsoft cannot reliably predict the effect to the operation of these products when parties other than the Microsoft SharePoint Development Team or Microsoft SharePoint Support agents make changes to the database schema, modify its data, or execute ad hoc queries against the SharePoint databases. Exceptions are described in the “Supported Database Modifications” section.

1.3.1        Unsupported Database Changes

Examples of unsupported database changes include, but are not limited to, the following:

  • Adding database triggers
  • Adding new indexes or changing existing indexes within tables
  • Adding, changing, or deleting any primary or foreign key relationships
  • Changing or deleting existing stored procedures
  • Calling existing stored procedures directly, except as described in the SharePoint Protocols documentation
  • Adding new stored procedures
  • Adding, changing, or deleting any data in any table of any of the databases for SharePoint
  • Adding, changing, or deleting any columns in any table of any of the databases for SharePoint
  • Making any modification to the database schema
  • Adding tables to any of the databases for SharePoint
  • Changing the database collation
  • Running DBCC_CHECKDB WITH REPAIR_ALLOW_DATA_LOSS (However, running DBCC_CHECKDB WITH REPAIR_FAST and REPAIR_REBUILD is supported, as these commands only update the indexes of the associated database.)
  • Enabling SQL Server change data capture (CDC)
  • Enabling SQL Server transactional replication
  • Enabling SQL Server merge replication

If an unsupported database modification is discovered during a support call, the customer must perform one of the following procedures at a minimum:

  • Perform a database restoration from the last known good backup that did not include the database modifications
  • Roll back all the database modifications

 

If a previous version of the database that does not include the unsupported modifications is unavailable, or if the customer cannot roll back the database modifications, the customer must recover the data manually. The database must be restored to an unmodified state before Microsoft SharePoint Support can provide any data migration assistance.

If it is determined that a database change is necessary, a support case should be opened to determine whether a product defect exists and should be addressed.

1.3.2        Supported database modifications

Exceptions to the prohibition against database modifications are made for specific usage scenarios:

  • Operations that are initiated from the SharePoint administrative user interface
  • SharePoint specific tools and utilities that are provided directly by Microsoft (for example, Ststadm.exe)
  • Changes that are made programmatically through the SharePoint Object Model and that are in compliance with the SharePoint SDK documentation
  • Activities that are in compliance with the SharePoint Protocols documentation

Additionally, in rare circumstances during a support incident, Microsoft SharePoint Support agents may give customers scripts that modify the databases that are used by SharePoint. In these cases, all modifications are reviewed by the SharePoint Development Team to ensure that the operations being performed will not result in an unstable or unsupported database state. Database changes that are made with the guidance of a Microsoft SharePoint Support agent during the course of a support incident will not result in an unsupported database state. Customers may not reapply the scripts or changes provided by Microsoft SharePoint Support outside of a support incident.

1.3.3        Read operations addendum

Reading from the SharePoint databases programmatically, or manually, can cause unexpected locking within Microsoft SQL Server which can adversely affect performance. Any read operations against the SharePoint databases that originate from queries, scripts, .dll files (and so on) that are not provided by the Microsoft SharePoint Development Team or by Microsoft SharePoint Support will be considered unsupported if they are identified as a barrier to the resolution of a Microsoft support engagement.

If unsupported read operations are identified as a barrier to the resolution of support engagement, the database will be considered to be in an unsupported state. To return the database to a supported state, all unsupported read activities must stop.

2         SQL Maintenance Script

Source: http://ola.hallengren.com/scripts/MaintenanceSolution.sql

The SQL Server Maintenance Solution comprises scripts for running backups, integrity checks, and index and statistics maintenance on all editions of Microsoft SQL Server 2005, SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, and SQL Server 2014. The solution is based on stored procedures, the sqlcmd utility, and SQL Server Agent jobs. I designed the solution for the most mission-critical environments, and it is used in many organizations around the world. Numerous SQL Server community experts recommend the SQL Server Maintenance Solution, which has been a Gold winner in the 2013, 2012, 2011, and 2010 SQL Server Magazine Awards. The SQL Server Maintenance Solution is free.

 

Die Collaboration User Story – Warum braucht es ein Collaboration Tool?

with 3 comments


Dieses Video richtet sich an Entscheidungsträger, Projektleiter aber auch Technische Verantworltiche, die ihren Kunden gerne erklären würden, warum SharePoint eine gute Wahl für ihr Unternehmen ist. Es entlarvt die gängigen Fallstricke in der Zusammenarbeit und zeigt die gröbsten Vorteile von SharePoint verständlich auf.

Viel Spass beim zuschauen und teilen

So Long, Samuel

Written by sharepointszu

15. August 2013 at 11:04

Best Practices Setup von SharePoint 2013, mit Web Apps 2013 und Workflow Manager 1.0

leave a comment »


Hier mal noch das neuste Werk von mir, wo ich zeige, wie man SharePoint 2013 mit SQL, WebApps und Workflow Manager installiert. Inklusive aller Powershell Scripts für das Setup. Alles nach bisher bekannten Best Practices, auch für die SharePoint Topologie etc.

So long, Samuel

Written by sharepointszu

3. Juli 2013 at 13:16

Deployment Szenarien mit AD und Office 365 in Verbindung mit AZURE

leave a comment »


Microsoft hat soeben eine neue Guideline rausgegeben, wie man Identities mit Office 365 und Windows AZURE am besten verwaltet.

Grundsätzlich wird es ja immer wahrscheinlicher, dass man on Prem gar kein AD mehr haben möchte, und alles in die Cloud schiebt. Hier sind einige mögliche Szenarien, ich bin gerade dabei mit einem Kunden die ganzen Möglichkeiten durchzurechnen.

Behandelt werden die Szenarien:

  1. AD on Premise mit Sync in Windows Azure
  2. AD in Windows Azure
  3. AD in Windows Azure als Desaster Recovery

http://www.microsoft.com/en-us/download/details.aspx?id=38845

Enjoy

So long, Samuel

Written by sharepointszu

1. Juli 2013 at 10:05

Veröffentlicht in IT Professional

Tagged with , , ,

Collaboration beginnt im Kopf – nicht bei der Technik

leave a comment »


Schon vor einiger Zeit habe ich mal in einer schlaflosen Nacht eine Präsentation über die Voraussetzungen von Kollaboration erstellt. Es geht dabei darum, dass Kollaboration nicht mit Technik beginnt, sondern in den Köpfen der Menschen. In der Art und Weise wie wir miteinander umgehen.

Wie sollen die Mitarbeiter zusammenarbeiten, einander helfen, sich gegenseitig unterstützen, wenn wir doch in einem System der Selbstbezogenheit, der Gewinnmaximierung und ROI Wahnsinn leben? Wenn es fast nur noch darum geht, was für mich drin ist? Wir es gewohnt sind, dass man uns alles zuträgt? Sit back and kick the TV on…

In dieser Präsentation habe ich mir über diese Themen Gedanken gemacht. Was müssen wir in unserer Zusammenarbeitskultur tun, damit wir auch mit den uns zur Verfügung stehenden Systemen zusammenarbeiten? Natürlich gebe ich die Präsentation auch mal gerne in euren Teammeetings oder auf Tagungen.

So Long, Samuel

 

Mit der SharePoint 2013 Search Topologie arbeiten

with one comment


In SharePoint 2013 hatten wir ja das Vergnügen, ein GUI für die Verwaltung der Search Topologie zu haben. Diese Zeiten sind endgültig vorbei. Des einen Leid, des anderen Freud. Neu muss die Topologie der Suche per PowerShell verwaltet werden. Wie man das macht, entnehmt ihr dem unten folgenden Code.

Grundsätzlich unterscheiden wir folgende Rollen, welche auf verschiedenen Servern redundant aufgebaut werden können:

  1. Crawl Komponente
  2. Content Processing Komponente
  3. Analytics Komponente
  4. Index Komponente (schreibt den Index)
  5. Query Processing Komponente
  6. Admin Komponente

Im Beispiel wird die Suche auf zwei Frontends verteilt, auf welcher die Query Rolle läuft und auf zwei Application Server, die alle anderen Rollen redundant verpasst bekommen, zusätzlich soll die Indexpartition 0 auf beide Server gespiegelt werden.

SearchTop

 

Und hier kommt der Code:

# Abfragen des SharePoint 2013 Search Status
Get-SPEnterpriseSearchStatus -SearchApplication (Get-SPEnterpriseSearchServiceApplication)

# Definieren der Server
$wfe1 = Get-SPEnterpriseSearchServiceInstance -Identity "yourserver"
$wfe2 = Get-SPEnterpriseSearchServiceInstance -Identity "yourserver"
$app1 = Get-SPEnterpriseSearchServiceInstance -Identity "yourserver"
$app2 = Get-SPEnterpriseSearchServiceInstance -Identity "yourserver"

# Starten der Service Instanzen auf allen Servern
Start-SPEnterpriseSearchServiceInstance -Identity $wfe1
Start-SPEnterpriseSearchServiceInstance -Identity $wfe2
Start-SPEnterpriseSearchServiceInstance -Identity $app1
Start-SPEnterpriseSearchServiceInstance -Identity $app2

# Checken ob die Services alle online sind, bevor wir weiter machen
do {
    $globalState = 0
    $wfe1Stat = Get-SPEnterpriseSearchServiceInstance -Identity $wfe1
    if ($wfe1Stat.status = "online") {$globalState++}
    $wfe2Stat= Get-SPEnterpriseSearchServiceInstance -Identity $wfe2
    if ($wfe2Stat.status = "online") {$globalState++}
    $app1Stat = Get-SPEnterpriseSearchServiceInstance -Identity $app1
    if ($app1Stat.status = "online") {$globalState++}
    $app2Stat = Get-SPEnterpriseSearchServiceInstance -Identity $app2
    if ($app2Stat.status = "online") {$globalState++}
    Write-Host "There are $globalState Machines ready"
    if ($globalState -lt 4) {
        Write-Host "Waiting for 10 seconds..."
        Start-Sleep -s 10
    }
}
while ($globalState -lt 4)

# Search Service Applikatioin festlegen
$ssa = Get-SPEnterpriseSearchServiceApplication
$newTopology = New-SPEnterpriseSearchTopology -SearchApplication $ssa

# Frontend Rollen festlegen
New-SPEnterpriseSearchCrawlComponent -SearchTopology $newTopology -SearchServiceInstance $wfe1
New-SPEnterpriseSearchCrawlComponent -SearchTopology $newTopology -SearchServiceInstance $wfe2

# App Server Rollen festlegen
New-SPEnterpriseSearchAdminComponent -SearchTopology $newTopology -SearchServiceInstance $app1
New-SPEnterpriseSearchContentProcessingComponent -SearchTopology $newTopology -SearchServiceInstance $app1
New-SPEnterpriseSearchAnalyticsProcessingComponent -SearchTopology $newTopology -SearchServiceInstance $app1
New-SPEnterpriseSearchQueryProcessingComponent -SearchTopology $newTopology -SearchServiceInstance $app1
New-SPEnterpriseSearchIndexComponent -SearchTopology $newTopology -SearchServiceInstance $app1 -IndexPartition 0

New-SPEnterpriseSearchAdminComponent -SearchTopology $newTopology -SearchServiceInstance $app2
New-SPEnterpriseSearchContentProcessingComponent -SearchTopology $newTopology -SearchServiceInstance $app2
New-SPEnterpriseSearchAnalyticsProcessingComponent -SearchTopology $newTopology -SearchServiceInstance $app2
New-SPEnterpriseSearchQueryProcessingComponent -SearchTopology $newTopology -SearchServiceInstance $app2
New-SPEnterpriseSearchIndexComponent -SearchTopology $newTopology -SearchServiceInstance $app2 -IndexPartition 0

# Search Topologie aktivieren
Set-SPEnterpriseSearchTopology -Identity $newTopology

Achtung: Eine Neudefinition der Topologie funktioniert nur mit leerem Index. Heisst, ggf. müsst ihr zuerst den Indes zurücksetzen oder ein anderes Vorgehen wählen.

So long, Gruss Samuel

Written by sharepointszu

19. März 2013 at 12:25

Mehrsprachigkeit für SharePoint 2013 mit Fokus “Collaboration”

with one comment


In einem aktuellen projekt haben wir uns gefragt, wie wir in einem Kollaborativen Umfeld einige Seiten mit Mehrsprachigkeit versehen können. Wie in unserem Beispiel die Collaboration Community, die einerseits Informationen in D, FR und IT beinhaltet, jedoch im Grossteil entweder in der Corporage Language, oder in einer jeweiligen Landessprache, wenn alle Beteiligten die Sprache beherrschen. Es kann auch mal gemischter Content sein, Collaborative eben.

Natürlich könnten wir Variations benutzen, das wäre das naheliegende. Aber dann wäre die Diskussion in der Community auch getrennt, und dass will man ev. nicht. Ausserdem extra eine Publishing Seite machen, schien mir nicht zielführend, da es sich eben um eine Kollaborative seite handelt. SharePoint 2013 macht es mir ja einfach, Script Blöcke einzubauen, also hab ich mir überlegt, ob es nicht mit Javascript klappen könnte, die Browsersprache raus zu popeln und anhand dieser auf Sprachseiten (aspx Wikipages) zu routen. Nach ein paar Anläufen, mit tollen Hilfe von Thorsten Hans und Kevin Mees ist es uns dann gelungen, einen entsprechenden Script zu bauen.

Die Funktionsweise ist ziemlich simpel. Die Homepage der Community ist eine leere Seite, welche nur Javascript enthält und anhand der Browsersprache auf die richtige Home Seite verzweigt. Die sprachabhängigen Homeseiten wiederum enthalten zum Einen Text in der jeweiligen Sprache aber auch wiederverwendbare Elemente wie z.B. die Community Members. So haben wir dieselbe Datenbasis mit mehrsprachigen Info-Seiten.

Weiter war uns wichtig, dass de-ch, de-de, de-at oder fr und fr-ch gleich behandelt werden, und auch da haben wir eine Lösung gefunden. Wir beachten einfach die ersten zwei Zeichen.

Als Sahnehäubchen sind Wikipages ja eben Wikipages, und auf jeder Sprachseite implementieren wir noch DE | [[Community-Home-fr|FR]] | [[Community-Home-it|IT]] damit jederzeit auf eine andere Sprache umgeschaltet werden kann.

Multi Language Support

Und natürlich hier der Javascript, welcher verwendet wurde um auf die Sprachseiten (Wikipages) zu verzweigen

var browserLanguage = window.navigator.userLanguage || window.navigator.language;
var redirectTo = "/topic/collaborationcommunity/SitePages/Community-Home-de.aspx";
switch (browserLanguage.substring(0,2)) {
  case "de":
  break;
  case "fr":
  redirectTo ="/topic/collaborationcommunity/SitePages/Community-Home-fr.aspx";
  break;
  case "it":
  redirectTo ="/topic/collaborationcommunity/SitePages/Community-Home-it.aspx";
  break;
  default:
  break;
}
window.location = redirectTo;

Nicht jeder Browser ist gleichschnell, z.B. der IE ist mit Javascript langsam, und es dauert eine halbe Sekunde bis der Redirect erfolgt. Chrome sieht man keinen switch.

Für die langsamen Browser haben wir noch die allgemeinen elemente auf die Home Seite gepackt, und per loading gif ein asynchrones Laden der Seite simuliert.

loading

Das sieht dann so aus:

CommunitySwitch

So sind die User glücklich, auch wenn der Browser eine halbe Sekunde zum umschalten braucht, und wir haben eine sehr einfache und günstige Lösung für diese Bereiche einer Kollaborationsplattform, die eben ggf. trotzdem Mehrsprachig sein sollen.

So long, Samuel

Written by sharepointszu

14. März 2013 at 14:11

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 778 Followern an

%d Bloggern gefällt das: