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

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.

Windows Server 2012 RDS RemoteApp Icon ändern

Problem

Bei der Einrichtung einer RemoteApp unter Server 2012/2012R2 ist ein falsches (oder gar kein) Symbol ausgewählt worden. Das Symbol soll nun „mal eben™“ geändert werden.

remoteapp-icon-aendern

Lösung

Über das GUI ist das Ändern des Symbols nicht möglich. Wie man ein so unvollständiges Produkt überhaupt veröffentlichen kann und danach noch ruhig schläft, ist mir ein Rätsel. Über die Powershell ist das aber möglich. Zudem scheinen an der Shell die (ehemaligen?) GUI-Regeln von UNC-Pfaden und ähnlichem nicht mehr zu gelten. Mit Set-RDRemoteApp lassen sich die Einstellungen anpassen:

Get-RDRemoteApp -Alias "meineanwendung" | Set-RDRemoteApp -IconPath "c:\windows\system32\shell32.dll" -IconIndex 6

Der IconPath ist der Pfad zum Symbol (Jeder Broker muss auf das Symbol zugreifen können!) und den IconIndex die Position des Symbols in der Datei, beginnend mit „0“.

.NET Framework 3.5 unter Windows 8.1 installieren

In der Theorie kann man unter Windows 8/8.1 das .NET Framework 3.5 einschliesslich benötigter patches über die Systemsteuerung unf „Programme und Funktionen“ installieren. Das klappt auch ab und zu ganz gut. Der leidgeprüfte Admin befindet sich aber im Regelfall nicht im offenen und schnellen Internet, sondern hinter diversen Firewalls und Sicherheitseinrichtungen die die Freude am runterladen recht schnell verderben.

Daher gib es ein INOFFIZIELLES Offline-Installer Paket vom .NET Framework für Windows 8.1, zusammengestellt von den Jungs von askvg.com. Kein Suport, keine Updates, keine Garantie. Läuft bestens.

Keine RDS-Berechtigung in Office365 „Business“Plänen.

Seit dem 1. September 2014 gibt es mit shared computer activation die neue Terminalserver-Installationsmethode für Office 365 ProPlus. Das Office-Paket aus Office 365 E3 und Office 365 ProPlus kann jetzt mit Hilfe des Office Deployment Tool auf Terminalservern ab Windows Server 2008 R2 (mit aktivierter RDS-Rolle) oder auch in virtuellen Desktop Pools installiert werden. Das bedeutet, dass man endlich nicht mehr diesen (ansonsten) unsinnigen einzelnen zusätzlichen Office 2013 Professional Plus-Datenträger (+Key) braucht.
Bei der Installation muss auch nicht mehr das gesamte Paket installiert werden, sondern man kann mit Hilfe der Steuerdatei für die Installation auch einzelne Anwendungen von der Installation ausschließen. Das ist ja schon fast Praxisnah! 🙂

Jetzt kommt der fiese Teil.

Die neuen Office 365-Businesspläne bringen dafür keine RDS-Berechtigung mehr mit. In den M-Plänen und E-Plänen als OpenValue -Volumenvetrag war das PUR dazu enthalten, in Business nicht mehr. Alle Kunden die Office 365 Business oder Office 365 Business Premium in Zukunft kaufen, verfügen nicht über den gleichen Programm- und Funktionsumfang wie Office 365 ProPlus. Und so sehen die „neuen“ Berechtigungen im Detail aus:

office365-officeproplus-pur-table-2014