WebDAV -Web Folders on Windows Server 2003 Problem

Zum öffnen von Sharepoint Web Folder auf einem Windows Server 2003, muss der Web Client Service gestartet werden. Leider reicht dies nicht, Microsoft hat noch einen Update für den Web Client http://support.microsoft.com/kb/907306/en-us. Ohne dies ist es nicht möglich von einem MOSS die Web Folder Ansicht zu öffnen.

Powershell Command History & Performance

Powershell die Zukunft der Kommandozeile auf Windows Systemen? Ein par Verbesserungen gibt es noch und die kommen zum Teil auch in Version 2.0.

Lieder wird die Command History nicht gespeichert. So ist bei einer neuen Session alle Commands weg, die schon einmal verwendet wurden. Dies kann mit einem Profile Script nicht ganz befriedigend aber funktionierend nach gebessert werden.

1. Muss die ExecutionPolicy gesetzt werden. Sonst werden keine Scripts ausgeführt. Hier gibt es 4 Varinaten die sind beschrieben unter help about_signing. Da wir ja wissen was wir machen verwenden wir die unsicherste ;-)
   

   Set-ExecutionPolicy Unrestricted

2. %userprofile%\Documents\WindowsPowerShell die Datei Microsoft.PowerShell_profile.ps1 erstellen und in Notepad öffnen.

3. Folgendes Script Kopieren und einfügen.
   
   Set-Location C:\
   
   $MaximumHistoryCount = 1KB
   
   if (!(Test-Path ~\PowerShell -PathType Container))
   
   { New-Item ~\PowerShell -ItemType Directory
   
   }
   
   function bye
   
   { Get-History -Count $MaximumHistoryCount Export-CSV ~\PowerShell\history.csv
   
   exit
   
   }
   
   if (Test-path ~\PowerShell\History.csv)
   
   { Import-CSV ~\PowerShell\History.csv Add-History
   
   }
   

Beim Öffnen der Shell wird das gespeicherte csv wieder in die History geschrieben. Was leider nicht so schön ist, dass beim verlassen der Shell das Kommando bye eingeben werden muss. Sonst wird die Funktion nicht aufgerufen und die History ist weg.

Nun kann mit get-history Alias h oder mit invoke-history Alias r die letzten Kommandos wieder dargestellt oder verwendet werden.

http://blogs.msdn.com/powershell/archive/2006/07/01/653194.aspx

Ein weiters Problem ist das aufstarten der Powershell. Da vergehen Sekunden bis das erste Kommando eigegenem werden kann.

Hier hilft auch ein Script das die Powershell assamblies Compiliert. Das Script muss nur nach der Installation einmal ausgeführt werden. Solange kein Update für Powershell installiert wird ist das aufstarten einiges schneller.

Set-Alias ngen @(

dir (join-path ${env:\windir} "Microsoft.NET\Framework") ngen.exe -recurse |

sort -descending lastwritetime

)[0].fullName

[appdomain]::currentdomain.getassemblies() | %{ngen $_.location}


http://blogs.msdn.com/powershell/archive/2007/11/08/update-gac-ps1.aspx

SQL 2000 Backup history löschen

Bei jedem Backup einer DB wir ein Eintrag in der msdb erstellt für die Backup history. Nach ein par Jahren wird die msdb sehr gross und bei einem Restore über das GUI können über 15Min vergehen bis der Dialog er scheint. Mit der Store Procedure von Microsoft sp_delete_backuphistory ist es unmöglich mehrere Jahr oder auch nur Monate aus der msdb zu löschen. Tara Kizer hat ein viel effizienteres Script erstellt. So könnte ich 3 Jahre von 50 DBs ohne Probleme löschen.

CREATE PROC isp_DeleteBackupHistory(@DaysToRetain int)AS
SET NOCOUNT ON
DECLARE @Err intDECLARE @rc int
BEGIN TRAN
DELETE FROM msdb..restorefile FROM msdb..restorefile rf INNER JOIN msdb..restorehistory rh ON rf.restore_history_id = rh.restore_history_id INNER JOIN msdb..backupset bs ON rh.backup_set_id = bs.backup_set_id WHERE bs.backup_finish_date < (GETDATE() - @DaysToRetain)
SET @Err = @@ERROR
IF @Err <> 0 GOTO Error_Exit DELETE FROM msdb..restorefilegroup FROM msdb..restorefilegroup rfg INNER JOIN msdb..restorehistory rh ON rfg.restore_history_id = rh.restore_history_id INNER JOIN msdb..backupset bs ON rh.backup_set_id = bs.backup_set_id WHERE bs.backup_finish_date < (GETDATE() - @DaysToRetain)
SET @Err = @@ERROR
IF @Err <> 0 GOTO Error_Exit DELETE FROM msdb..restorehistory FROM msdb..restorehistory rh INNER JOIN msdb..backupset bs ON rh.backup_set_id = bs.backup_set_id WHERE bs.backup_finish_date < (GETDATE() - @DaysToRetain)
SET @Err = @@ERROR
IF @Err <> 0 GOTO Error_Exit SELECT media_set_id, backup_finish_date INTO #Temp FROM msdb..backupset WHERE backup_finish_date < (GETDATE() - @DaysToRetain)
SET @Err = @@ERROR
IF @Err <> 0 GOTO Error_Exit DELETE FROM msdb..backupfile FROM msdb..backupfile bf INNER JOIN msdb..backupset bs ON bf.backup_set_id = bs.backup_set_id INNER JOIN #Temp t ON bs.media_set_id = t.media_set_id WHERE bs.backup_finish_date < (GETDATE() - @DaysToRetain)
SET @Err = @@ERROR
IF @Err <> 0 GOTO Error_Exit DELETE FROM msdb..backupset FROM msdb..backupset bs INNER JOIN #Temp t ON bs.media_set_id = t.media_set_id
SET @Err = @@ERROR
IF @Err <> 0 GOTO Error_Exit DELETE FROM msdb..backupmediafamily FROM msdb..backupmediafamily bmf INNER JOIN msdb..backupmediaset bms ON bmf.media_set_id = bms.media_set_id INNER JOIN #Temp t ON bms.media_set_id = t.media_set_id
SET @Err = @@ERROR
IF @Err <> 0 GOTO Error_Exit DELETE FROM msdb..backupmediaset FROM msdb..backupmediaset bms INNER JOIN #Temp t ON bms.media_set_id = t.media_set_id
SET @Err = @@ERROR
IF @Err <> 0 GOTO Error_Exit
COMMIT TRAN
SET @rc = 0
GOTO isp_DeleteBackupHistory_Exit
Error_Exit:
ROLLBACK TRAN
SET @rc = -1
isp_DeleteBackupHistory_Exit:
DROP TABLE #Temp
SET NOCOUNT OFF
RETURN @rc
GO

Im Blog ist auch eine Version für SQL 2005 verfügbar:
http://weblogs.sqlteam.com/tarad/archive/2004/07/02/1704.aspx

MCMS 2002 100% CPU Load - zu viele Postings

Beim Deployment von Content im Microsoft CMS 2002 wird bei jedem deployment eine neue archiv Version des Content erstellt. So wird die Live DB immer grösser und kann dazuführen, dass der CMS Server überlastet ist. Da das CMS bei jedem Request alle Postings duchsuchen muss, auch die Archivierten. Wir hatten CMS Server, da war die CPU Last immer auf 100% und so war die Website nicht erreichbar.

Zum feststellen wie viele Postings im CMS vorhanden sind, kann dies SQL Query ausgeführt werden:

Select type, Count(*), GETDATE()
from scmcms.dbo.node
group by type

hier noch die Node Typen:
Type Name
1 Server
4 Channel
16 Postings
64 Ressourcen Folders
256 Ressourcen
16384 Template Gruppe
65536 Template
1048576 Administrator
2097152 Archive Folder, Deleted Items, Folder
524288 Rollen
1048576 Berechtigungs Gruppen

Die archivierten Postings können über den Sitemanager -> Tools -> Clear Revision History gelöscht werden. Leider funktioniert dies nicht immer, da schon zu viele archivierte Postings in der DB sind. Bei mir mit 27000 Postings und 97000 Ressourcen konnte ich nicht einmal ein Monat löschen. Zum Glück hatten dies Problem auch schon andere und kann gelöst werden mit dem ersetzten der Store Procedure PurgeRevisionsByDate.
http://support.microsoft.com/kb/899027/en-us

Danach konnte ich doch 4 Monate auf einmal löschen. Zu beachten ist das Transaction Log der DB dies wachst massiv bei dieser Löschaktion.

Der KB Artikel zum warten einer MCMS DB:
http://support.microsoft.com/kb/836646/en-us

stsadm langsam, Publisher's CRL

Es gibt MOSS Server die haben keine Internet zugriff, auch nicht über einen Proxy. So wird der ganze MOSS Server sehr langsam. Am besten ist der Effekt mit stsadm zu sehen. Nur der Aufruf ohne Parameter dauert 30s.
Wenn die SharePoint DLL's geladen werden versucht der SharePoint im Internet auf http://crl.microsoft.com/ oder http://crl.verisign.com/ zu zugreifen. Tja, und ohne Internet Verbindung wartet der SharePoint auf den Timeout.

Es gibt verschiedene Workarounds dies zu Lösen:

1. Host Eintrag setzen auf 127.0.0.1 für die zwei URL's. (Funktioniert nicht immer)
2. Proxy Server einsetzten und mit proxycfg -p 192.168.0.1:8080 konfigurieren
3. Disable im IE Tools>Internet Options>Advanced>Check for Publisher's certificate revocation.
4. Die CRL's downloaden und Importieren
   Download:
   http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl
   http://crl.microsoft.com/pki/crl/products/CodeSignPCA2.crl
   Add them:
   certutil -addstore CA CodeSignPCA.crl certutil -addstore CA CodeSignPCA2.crl

Wir haben uns für Variante 3 entschieden, so haben wir auch mit weiteren Applikationen zB. SQL Management Studio keine Probleme.

Da ja MOSS meistens unter einem Service Account betrieben wird, ist es wichtigs dass auch diese die CRL (Client Revocation List) nicht übers Internet prüfen wollen. Da die Einstellungen für den IE nur für den Aktiven User gelten habe ich ein Script erstellt, dass die Settings auf allen Usern auf dem Server setzt.

Const HKEY_USERS = &H80000003
SetAllUsersRegKey
"Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software
Publishing\State",146944,"REG_DWORD"
Sub SetAllUsersRegKey(sKeyName,sData,sType)
Dim oShell, sKey, oReg,
sSubKey,aRegKeys,aDesktopKeys

Set oShell = CreateObject("Wscript.Shell")

Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
oReg.EnumKey HKEY_USERS, "", aRegKeys

For Each sSubkey In aRegKeys oReg.EnumKey
HKEY_USERS, sSubkey & "\Control Panel\Desktop", aDesktopKeys

If Not IsNull(aDesktopKeys) Then

Wscript.Echo sSubkey & "\" & sKeyName,sData,sType
oShell.RegWrite "HKEY_USERS\" & sSubkey & "\" & sKeyName,sData,sType

End If

Next
End Sub

Hier weiter Blogeinträge zu diesem Thema:
http://paulhorsfall.co.uk/archive/2007/05/27/Stsadm.exe-and-iisreset-Slow-Behind-Proxy-on-SharePoint.aspx

http://jritmeijer.spaces.live.com/blog/cns!8A48A27460FB898A!965.entry

AddSchedulingJobDefinitions failed beim Site erstellen

Wir haben eine neue Web Application erstellt mit eigenem Service Account und Custom Features und Layouts. Im Templatepicker haben wir unser Template gewählt und OK. Das Template wurde gesetzt aber es folgte die Meldung Access denied. In den ULS war der folgende Eintrag.

AddSchedulingJobDefinitions failed. System.Security.SecurityException: Access denied. at
Microsoft.SharePoint.Administration.SPPersistedObject.Update()
....

Da der Application Pool nicht unter dem Central Administration Pool Accout konfiguriert ist, hat der Account keine Rechte den Job zu erstellen für die Features zu aktivieren. Da dies nur einmal beim erstellen aktiviert wird kann dies mit einem Workaround gelöst werden.

1. Im IIS Admin properties der Web Application öffnen
2. Im Home Directory den Application Pool auf den Central Administration Pool setzten
3. iisreset
4. Site Template wählen (features aktivieren)
5. Den Application Pool wieder zurück setzten

Ähnliches Problem habe ich hier gefunden, sprich die Lösung:

http://msmvps.com/blogs/obts/archive/2007/01/30/528982.aspx

Ausschalten vom UAC Vista Black Screen

Vista UAC sollte ja nicht ausgeschltet werden. Aber wenn jede Anfrage des Administrator-Account und Password nur schon länder 5 sec dauert bis die Anmeldebox da ist nervt dies schon.
Zum Glück kann das verdunkeln des Bildschirms ausgeschaltet werden in der Policy.

Run secpol.msc Security Settings > Local Policies > Security Options
dort suchen nach "User Account Control: Switch to the secure desktop when prompting for elevation" und auf disable stellen.

Voilà, die Anmeldebox erscheint Blitzschnell :-)