Noch einen weiteren Eintrag muss ich in die Welt hinaus posaunen.
Man staunt schon, wie schnell man auf die Nase fallen kann, wenn man nicht wirklich ganz bis zum Ende denkt.
Für einen Kunden habe ich eine automatisierte Setup-Routine geschrieben, welche SQL Server automatisiert verteilt. Das wäre an sich ja nichts besonderes. Darin enthalten ist aber auch das Einrichten der Berechtigungsstruktur, das Anlegen von Verzeichnissen und MountPoints (= Bereitstellungspunkte für das Dateisystem bzw. Partitionen). Die Freigaben (incl. Berechtigungen) und NTFS-Berechtigungen werden ebenfalls automatisch gesetzt.
Spannend wird es nun, wenn diese Struktur in einer Umgebung mit hoher Arbeitsteilung von verschiedenen Kollegen und dann manuell eingerichtet wird.
Wenn man nun Berechtigungen auf Clustern einrichtet, wird man in der Regel auf das Konto [NT Service\SQLServerDienstName] zurückgreifen wollen. Wenn man dies nicht getan hat, sondern während der Installation [LocalSystem] oder ein Domänenkonto verwendet, kann es schnell kritisch werden, wenn man bei Änderungen des Dienstkontos vergisst, dass Berechtigungen auf MountPoints eben nicht ganz so einfach zu vergeben sind.
Bild 1 zeigt die Bereitstellungspunkte im Windows Explorer:
Bild 2 zeigt mit blauem Pfeil, den scheinbar kurzen Weg, nur dass an dieser Stelle nur der Bereitstellungsordner aber nicht die gebundene Windowspartition mit Berechtigungen versehen wird. Dazu muss man erst noch in die Eigenschaften des bereitgestellten Volumen (Pfeil rot) gehen.
Bild 3 zeigt dann die relevante Registerkarte der Partition, wo die Rechte ebenfalls gesetzt werden müssen. Wenn man dies vergisst, kann man auf einmal keine Datenbanken mehr anlegen oder wiederherstellen. Auf Clustern fällt dass dann spätestens beim ersten Failover auf ... Der SQL Server kann auf seine Datenbanken nicht mehr zugreifen --> wohl dem, der es vorher merkt :-)
Das gilt insbesondere, wenn man verschiedene Serverklassen hat, wo die Daten sowohl im Ordner (kleiner Server) oder eben auch auf der gemounteten Partition (großer Server liegen).
P.S.: Bitte daran denken, das Dienstkonto wird im Konfigurationsmanager geändert und nirgendwo sonst, wenn man nicht zu viel Zeit hat.
Nach einigen Monaten Pause nun mal wieder 2-3 Einträge. Man sollte halt gleich schreiben, bevor wieder Gras über die Sache gewachsen ist. Und ich muss mich beeilen - nicht dass es für einen Aprilscherz gehalten wird.
Für die automatisierte Relocation von Datenbanken habe ich ein Spezialprozedur geschrieben, damit ich die in Summe weit über 100 Datenbanken nicht manuell verschieben muss.
Darin habe ich auch mit TRY...CATCH die Systemprozedur sp_detach_db benutzt. Die Überraschung war groß, dass diese mit Fehler 3705 abgebrochen wurde, obwohl scheinbar keine Prozesse auf die fragliche Datenbank zugegriffen haben.
Die Lösung offenbarte sich an anderer Stelle. Ein weiterer Prozess mit völlig unterschiedlicher Aufgabenstellung hatte eine Sperranforderung für die Datenbank erstellt.
Es reicht also nicht, die Sessions zu beenden, welche die umzuziehende database_id direkt (als verbunden) referenzieren. Vielmehr müsste man auch die Spalte wait_resource prüfen, um wirklich sicher zu sein, dass keiner die Datenbank benutzt bzw. benutzen möchte.
Anmerkung: Ich wurde darum gebeten, den Code an dieser Stelle zu veröffentlichen. Leider ist das nicht möglich, da ich die Prozedur noch nicht anonymisiert habe und leider im Moment auch nicht noch dazu komme. Es gibt gute und interessante Neuigkeiten!
Die Datenbank-Spiegelung wurde komplett überarbeitet!
Endlich gibt es die Möglichkeit, lesbare Kopien zu nutzen.
Daneben werden Fail-Over-Gruppen sowie eine differenzierte Konfiguration eingeführt.
Auf der Basta! 2010 haben Nico Thiemer und Cedric Oettel den Vortrag Arbeiten und Entwickeln mit den VisioServices in SharePoint 2010 gehalten. In diesem Vortrag haben wir auch versprochen, den Code zur Verfügung zu stellen, der es erlaubt, in Visio einen benutzerdefinierten Datenprovider zu verwenden und mit der Mashup–API zu arbeiten. Den Code und die dazu verwendenden Visiodateien können Sie hier herunter laden. Viel Spaß damit. Wer - wie unsere Firma - konsequent auf Technologien setzt, die die Notwendigkeit zu reisen einschränkt, schaut auch immer nach Tipps, was man dabei besser machen kann.
Dabei habe ich bei silicon.de einen Artikel gefunden, der offensichtlich aus leidvoller Erfahrung entstanden ist.
In 12 Tipps für Webkonferenzen findet man vieles Altbewährtes, was nur zu oft in Vergessenheit gerät. Trotzdem gibt es aus meiner Sicht noch Wichtiges zu ergänzen: Ich finde es besser, wenn man sich vor einer Web- oder Telefonkonferenz schon einmal vis-a-vis getroffen hat. Die "Chemie" stimmt dann einfach schneller und besser. Eine Videokonferenz kann da zwar einiges auffangen, aber leider ist auch heute noch immer nicht überall ausreichend Bandbreite und gute Technikqualität vorhanden.
Wer möchte, kann über die datafino GmbH BPOS (Business Productivity Online Suite) kennenlernen und buchen --> wir nutzen besonders gern Office Live Meeting, speziell auch für ad hoc-Konferenzen. Das Preis-Leistungsverhältnis ist in unseren Augen unschlagbar.
Jetzt ist es passiert. Ich habe es selbst noch nicht verifiziert, aber: der Bug ist zu wichtig, als das ich euch das vorenthalten möchte:
Es scheint so, dass unter SQL Server 2008 R2 Installationen existieren, in denen die Neu-Erstellung (Rebuild) der Systemdatenbanken nicht möglich ist.
Für alle die des Englischen mächtig genug sind, eine weitere Quelle (SQL Server MVP: Tibor Karaszi) dafür:
Dort findet ihr auch einen Link zur Wiederherstellung unter SQL Server 2008 (ohne R2)
Wenn ich das Prozedere einmal in deutscher Sprache posten soll, lasst es mich wissen.
Anmerkung: Ein Rebuild wird nur notwendig, wenn der SQL Server Dienst nicht mehr starten kann, weil Systemdatenbanken defekt sind. Bei der Behebung von Datenfehlern, wo der SQL Server Dienst dennoch startet, reicht in aller Regel ein Restore.
Eine Umgehungslösung für den Bug(?) habe ich auch für euch:
Nach der Installation und nach jedem (SQL Server-) Patch einmal den SQL Server Dienst herunterfahren und alle Datenbankdateien der Systemdatenbanken manuell (Datei kopieren) sichern.
Sollte ein Rebuild (vor allem der Datenbank "master") nötig werden, könntet ihr dann dieses Backup benutzen, um die Datenbank master (und alle anderen Systemdatenbanken) auf einen funktionalen Zustand zu bringen. Weitere Wiederherstellungen mit Hilfe des Restore-Befehls sind dann auch denkbar. Eine Lokalisierung kann wie schon in der vorherigen Version über Resource-Dateien im "{SharePointRoot}\Resources\" Ordner realisiert werden.
Im neuen Visual Studio 2010 fügt man dazu einfach einen Mapped Folder in die Solution ein und anschließend die entsprechenden Resource-Dateien.
Damit das ganze auch in der SharePoint Solution(*.wsp) mit eingepackt werden kann, muss die Build Action auf Content umgestellt werden. Dadurch landen die .resx Dateien in der SharePoint Solution und werden mit installiert.
Für detaillierte Informationen über das Einbinden ist der folgende Beitrag von John W Powell zu empfehlen:
Wenn man nun aber im Code selbst auf diese Resourcen zugreifen möchte, gibt es ein Problem. Da die Build Action auf Content gestellt ist, um vom Package-Automatismus erkannt zu werden, wird die Resource nicht in die DLL mit eingebunden und es kommt zu einer Fehlermeldung während der Benutzung der Controls o.ä.
Eine Quick & Dirty Lösung ist folgende:
Die .csproj Datei öffnen und folgendes XML(grün) in die ItemGroup der Resource-Dateien hinzufügen.
<ItemGroup>
<Content Include="Resources\MyResource.de-DE.resx">
<Generator>ResXFileCodeGenerator</Generator>
<LastGenOutput>MyResource.de-DE.Designer.cs</LastGenOutput>
</Content>
<Content Include="Resources\MyResource.resx">
<Generator>ResXFileCodeGenerator</Generator>
<LastGenOutput>MyResource.Designer.cs</LastGenOutput>
</Content>
<EmbeddedResource Include="Resources\MyResource.de-DE.resx">
<Generator>ResXFileCodeGenerator</Generator>
<LastGenOutput>MyResource.de-DE.Designer.cs</LastGenOutput>
</EmbeddedResource>
<EmbeddedResource Include="Resources\MyResource.resx">
<Generator>ResXFileCodeGenerator</Generator>
<LastGenOutput>MyResource.Designer.cs</LastGenOutput>
</EmbeddedResource>
</ItemGroup>
Die Änderung speichern und das Projekt in Visual Studio neu laden. Jetzt kann deployed werden. Die .resx Dateien landen wie geplant in der .wsp Datei und werden in die DLL eingebunden.
Eine andere Lösung wäre der Einsatz vom WSPBuilder für Sharepoint 2010.
Seit dem SQL Server 2008 SP1 gab es Probleme mit der Berichtsfunktion im TFS 2008 SP1 und beim Erstellen eines neuen Teamprojektes.
Dabei hat der TFS Wizard folgende Fehlermeldung ausgegeben:
---Anfang Ausnahmeeintrag---
Zeit: 2010-04-16 11:21:57Z
Modul: Initializer
Ereignisbeschreibung: TF30207: Fehler beim Initialisieren des Plug-Ins "Microsoft.ProjectCreationWizard.Reporting".
Ausnahmetyp: Microsoft.TeamFoundation.Client.PcwException
Ausnahmemeldung: TF30224: Fehler beim Abrufen von Projekten vom Berichtsserver. Überprüfen Sie, ob die SQL Server Reporting Services-Web- und -Windows-Dienste ausgeführt werden und ob Sie über ausreichende Berechtigungen zum Erstellen von Projekten verfügen.
Stapelüberwachung:
bei Microsoft.VisualStudio.TeamFoundation.RosettaReportUploader.CheckForProjectFolder(PrivateData data, String projectName, ProjectCreationContext context)
bei Microsoft.VisualStudio.TeamFoundation.RosettaReportUploader.Initialize(ProjectCreationContext context)
bei Microsoft.VisualStudio.TeamFoundation.EngineStarter.InitializePlugins(MsfTemplate template, PcwPluginCollection pluginCollection)
-- Interne Ausnahme --
Ausnahmetyp: System.InvalidOperationException
Ausnahmemeldung: Der vom Client gefundene Anforderungsinhaltstyp ist '', erwartet wurde 'text/xml'.
Fehler: Leere Antwort auf Anforderung.
Stapelüberwachung:
bei System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
bei System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
bei Microsoft.TeamFoundation.Proxy.Reporting.ReportingService.ListChildren(String Item, Boolean Recursive)
bei Microsoft.VisualStudio.TeamFoundation.RosettaReportUploader.CheckForProjectFolder(PrivateData data, String projectName, ProjectCreationContext context)
-- Ende interne Ausnahme --
---Ende Ausnahmeeintrag ---
Ich schaute, wie es auch viele Blogs rieten, ob die SQL Reporting Services richtig gestartet waren und ob die Logs etwas sagten. Leider war an dieser Stelle alles korrekt.
Der wichtigste Hinweis war, dass der Content-Type des Requests nicht text/html ist. Das bedeutet, dass die Kommunikation vom lokalen TFS Explorer(Client) zum SQL Reporting Services Webservice nicht stimmt.
In Emma's TFS Blog fand ich schließlich die Lösung. Durch das SP1 vom SQL Server 2008 wurde ein neuer Webservice mitgeliefert ("ReportService2005.asmx"). Dem TFS war aber nur der Webservice "ReportService.asmx" bekannt.
Daher einfach den Schritten von Emma's Blog folgen und das Problem ist gelöst.
Jetzt laufen die Berichte wieder.
Allerdings nicht die Teamprojekterstellung ;)
Dazu muss man erst das SP1 zum Visual Studio Team System über das existierende SP1 installieren.
Danach kann man wieder ganz normal die Teamprojekte erstellen.
Hier noch schnell der Link zum VS Team Suite SP1:
Ich hoffe, dass ich mit diesem Eintrag den Lesern ein paar Stunden Try and Error ersparen konnte :) Wie ich soeben erfahren habe, wird der SQL Server 2008 R2 auf der europäischen PASS-Konferenz freigegeben! Sehen wir uns dort?
Nun waren die letzten beiden Wochen doch so angefüllt, dass ich den Early Bird für die europäische Konferenz doch fast aus den Augen verloren habe: Am 1. Februar läuft er ab und ich möchte einladen, sich noch schnell anzumelden unter
|
|