Monat: November 2014

Wiederherstellen von Dateien aus einer Schattenkopie vom CSC Cache (Offlinedateien)

Veröffentlicht am von — 8 Kommentare ↓

Problem

Im Windows-Offline Cache, der seine Inhalte in %SystemRoot%\CSC ablegt, sind wichtige Dateien oder Änderungen abgelegt, die [noch] nicht korrekt synchronisiert wurden. Der Ordner ist aber gesperrt, um den Zugang von beliebigen interaktiven Nutzern zu verhindern – wobei Admins an dieser Stelle auch „Nutzer“ sind. Auch ein Administrator kann die Dateien der Schattenkopie-Sicherung nicht öffnen oder wiederherstellen, stattdessen erscheint diese Fehlermeldung:screenshot-keineberechtigung

Auf \\localhost\C$\@GMT-<datum>\Windows\CSC\v2.0.6 konnte nicht zugegriffen werden.
Sie haben keine Berechtigung für den Zugriff auf \\localhost\C$\@GMT-<datum>Windows\CSC\v2.0.6. Wenden Sie sich an den Netzwerkadministrator, um den Zugriff anzufordern.

Gründe für solche Inkonsistenzen gibt es viele – lange Offlinearbeit, ausgetauschte Server, geänderte Namen oder Freigaben, neue Rechte …

Lösung

Es gibt die Möglichkeit, als „SYSTEM“ die Daten aus dem Cache wiederherzustellen, vorausgesetzt es gibt eine lokale Schattenkopie davon. Das lässt sich schnell überprüfen mit  „vssadmin list shadows“.Wenn das der Fall ist, werden die beiden Tools VOLREST.EXE (aus dem Windows Server 2003 Ressource Kit) und PSEXEC (aus der Sysinternal PS-Tools Sammlung) benötigt. Keine Sorge, die meisten 2003’re Reskit-Tools laufen auch unter 7/8/8.1+ einwandfrei.

  1. Eine Shell als Administrator öffnen (cmd)
  2. Aus dieser eine neue Shell als SYSTEM öffnen: 
    psexec.exe -i -s -d cmd
  3. Den Ordner komplett mit volrest an einen neuen Ort retten: 
    volrest \\localhost\c$\windows\CSC /s /e /sct /r:C:\temp

Dieser vorgang stellt ALLE Versionen ALLER Dateien wieder her. Hinterher sortieren und aufräumen ist aber meistens einfacher, als neu schreiben …

Danke @Highly Unsupported, Sysinternals und verschiedene Admins in den Windows support Foren.

Windows 7/8/8.1/10 WLAN Hotspot starten/beenden

Veröffentlicht am von — Keine Kommentare ↓

In der Regel benötigt das Notebook Internet über das UMTS/LTE-Handy. Ab und zu braucht man aber schon mal eine Lösung anders herum – also Internet auf dem Mobiltelefon aus dem Notebook. In bestimmten Hotels wird zum Beispiel nicht nur für den Internetzugang kassiert, sondern auch noch für jedes einzelne Gerät. Windows kann mit Boardmitteln jede (IP-)Netzwerkverbindung via NAT an andere Verbindungen teilen; ausserdem ist ein mobiler WLAN-Hotspot eingebaut.

An der (Administrator-) Eingabeaufforderung geht das mit diesen beiden Befehlen:

c:\>netsh wlan set hostednetwork mode=allow ssid=%ssid% key=%key%
c:\>netsh wlan start hostednetwork

Noch einfacher gehts mit unserem Komfortscript für faule Admins, das nach der gewünschten SSID und nach dem Schlüssel fragt und nach getaner arbeit den zusätzlichen WLAN-Adapter auch wieder entfernt.

Wenn das Script läuft, muss nur noch die entsprechende Netzwerk-Verbindung für den neu erstellten Hotspot-Adapter freigegeben werden und voila: Internet via loakles Windows NAT.

  1. Windows Hotspot Script herunterladen
  2. Mit Admin-Rechten starten
  3. Internet-Adapter für „Die gemeinsame Nutzung“ freigeben

windows-wlan-hotspot-erstellen

SQL Server 2008/2012/2014 „Es kann nicht festgestellt werden, ob der Besitzer () von Auftrag für Serverzugriff hat.

Veröffentlicht am von — 2 Kommentare ↓

Problem

Ein oder mehrere Wartungspläne schlagen fehl und erzeugen unangenehme Fehler im Ablaufplanb, die diesen oder einen ähnlichen Wortlauf haben. Die Sicherungen werden aber korrekt erstellt.

Ereignistyp:       Warnung
 Ereignisquelle:    SQLSERVERAGENT
 Ereigniskategorie: Job Engine
 Ereigniskennung:   208
 Benutzer:          Nicht zutreffend
 Computer:          STACKEXCH1
 Beschreibung:
 SQL Server Scheduled Job ‘<foo>’ (0xLONGID) – Status: Fehler – Invoked on: <date> – Message: Auftragsfehler  Es kann nicht bestimmt werden, ob der Besitzer (‘<foo>\<bar>’) von Auftrag ‘<name>’ Serverzugriff aufweist. (Ursache: Die Informationen über Windows NT-Gruppe oder -Benutzer ‘<foo>\<bar>’ konnten nicht abgerufen werden, Fehlercode 0x5. [SQLSTATE 42000] (Fehler 15404)  Die Anweisung wurde beendet. [SQLSTATE 01000] (Fehler 3621)).

Lösung

Der Benutzer kann tatsächlich nicht aufgelört werden. Das kann am Design der AD-Infrastrutur liegen, wenn die Windows-Authentifizierung benutzt wird. Wir haben gute Erfahrungen gemacht, die Wartungspläne jeweils im lokalen SQL-Server kontext mit der SQL-Authentifizierung laufen zu lassen (z.B. ’sa‘).

Das geht in den Eigenschaften des betroffenen Wartungsplanes (oder Subplanes) in dem Feld „Besitzer“. In TSQL sieht das für den ’sa‘ dann so aus:

UPDATE msdb.dbo.sysssispackages 
SET [ownersid] = SUSER_SID('sa') 
WHERE [name] = 'Meinwartungsplan.Subplan' 

Alternativ ändert man im Management Studio, wärend man als das passende Zielkonto angemeldet ist, einfach den Namen. der aktuelle User wird dann als neue Besitzer übernommen. Einen via GUI erreichbaren Weg kennen wir spontan nicht.