SharePoint server umožňuje auditovat přístup k informacím, co kdo otevřel, změnil a podobně. Toto je velmi užitečná funkce, díky které můžete doložit kdo a kdy přistoupil k citlivým informacím. Zvláště v případě jejich vyzrazení se to může hodit. Nastavuje se ve Správě kolekce webů, kde se dají nastavit události, které se mají auditovat.

Pro jednotlivé záznamy:

• Otevírání nebo stahování dokumentů, zobrazování položek v seznamech nebo zobrazování vlastností položek
• Úpravy položek
• Rezervování položek nebo vracení položek se změnami
• Přesouvání nebo kopírování položek do jiného umístění na webu
• Odstraňování nebo obnovování položek
  

Pro seznamy, knihovny a weby:

• Úpravy typů obsahu a sloupců
• Prohledávání obsahu webu
• Úpravy uživatelů a oprávnění

Dále se dá nastavit, zda a po jaké době se mají auditní informace mazat. To velmi doporučuji. Už na středně velkém portálu totiž mohou auditní informace přibývat netušenou rychlostí. Nese to sebou ale jedno úskalí související s mazání starších záznamů. Za to je zodpovědný job Oříznutí protokolu auditování (Audit Log Trimming), který se standardně spouští jednou za měsíc. Tento job totiž spouští uloženou proceduru proc_TrimAuditEntries. Ta bohužel není napsaná zrovna nejlépe. Auditních záznamů totiž může, jak už jsem zmínil, vznikat poměrně dost (u jedné středně velké firmy jsem zažil i několik milionů záznamů denně, záleží na pracovitosti uživatelů). Proto se jejich mazání jednou měsíčně nemusí obejít bez komplikací. Jde především o to, že zmíněná procedura maže záznamy jedním delete příkazem, tedy v jedné transakci. Díky tomu, v případě velkého množství záznamů, můžete narazit na omezení velikosti transakčního logu nebo v horším případě na velikosti disku s tímto logem. Navíc se ještě job v takovém případě neozve a neskončí chybou, takže se na první pohled zdá, že je vše v pořádku. Ale není. Když se mu nepodařilo smazat data jeden měsíc, tak se mu to určitě nepodaří ani žádný další a tabulka s logy AuditData utěšeně narůstá...

Řešení problému má 2 fáze:

1. Je potřeba promazat tabulku AuditData. To uděláte opakovaným spouštěním procedury proc_TrimAuditEntries s pečlivým nastavením parametru @EndDate (mažou se starší záznamy). Nejlépe ještě před tím přepněte databázi do simple recovery modu (tím omezíte velikost transakčního logu). Potom ji opět přepněte zpět do Full recovery modu.
2. Přeplánujte job Oříznutí protokolu auditování tak, aby se spouštěl dostatečně často. Současně nastavte omezení velikosti transakčního logu tak, aby to zvládl mazání starých auditních záznamů.
   

Na závěr musím říct, že bohužel procedura proc_TrimAuditEntries není jediná v SP, která není připravena na to, že bude manipulovat s velkým množstvím dat, takže se podobný problém může vyskytnout i v jiných situacích.