Archiv der Kategorie: Windows

Windows 8 Apps starten nicht als Administrator

Veröffentlicht am von — 2 Kommentare ↓

Problem

„Die App kann nicht von einem integrierten Adminisrtator-Konto aus gestartet werden. Bitte melden Sie sich mit einem Benutzerkonto an“. So begrüßt Windows 8/8.1 gerne mal einen Admin der eine App, vor allem den Store, verwenden möchte. Ja, richtig gelesen: Der Administrator darf den Store nicht verwenden – auch nicht um das Windows 8.1 Update einzuspielen. Die OEM-Version von Windows 8.1 Pro lässt sich bekanntlich ja nicht anders als über den Store installieren, die ISO benötigt einen nicht-OEM-Key für den Download.

Lösung

Immerhin lässt sich diese Flause dem Windows TwinToken-System schnell austreiben:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\FilterAdministratorToken

Auf „1“ Stellen (Enabled), Default ist 0 (Disabled).

Wie immer auch gerne als .REG-Datei:

REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"FilterAdministratorToken"=dword:00000001

Und natürlich geht das auch via GPO für die ganze Domäne:
COMPUTERKONFIGURATION -> Richtlinien -> Windows-Einstellungen -> Lokale Richtlinien -> Sicherheitsoptionen -> „Benutzerkontensteuerung: Administratorgenehmigungsmodus für das integrierte Administratorkonto“

Mehr zum Thema: http://technet.microsoft.com/de-de/library/dd835564(v=ws.10).aspx#BKMK_BuiltInAdmin

Windows Server 2008/2008R2/2012/2012R2 RDS verbleibende Zeit anzeigen

Veröffentlicht am von — Keine Kommentare ↓

Der Windows Server, seit 2008, bringt eine Gnadenfrist für die Remote Desktop Services (früher Terminalservices) mit. In dieser Zeit lassen sich unbegrenzt Verbindungen herstellen und die Terminaldienste ausgiebig testen. Diese Zeit beträgt 90 Tage, bei nicht-erreichbarkeit des RDS-Lizenzservers bis zu 120 Tage. Doch wieviele Tage verbleiben noch?

Lösung: Die Antwort ist via WMI zu bekommen und versteckt sich in der win32_terminalservicesetting Klasse.

An der Powershell:

(Invoke-WmiMethod -PATH (gwmi -namespace rootcimv2terminalservices -class win32_terminalservicesetting).__PATH -name GetGracePeriodDays).daysleft[/powershell)

Via CMD/WMIc:

C:Windowssystem32>wmic /namespace:\rootCIMV2TerminalServices PATH Win32_TerminalServiceSetting WHERE (__CLASS !="") CALL GetGracePeriodDays

Allgemeine Informationen über die Lizenz und Lizensierung des aktiven Servers gibt es via

slmgr /dlv

windows-server-2012-rds-lizenz

Upgrade Windows Server 2012 Standard Edition auf Server 2012 Datacenter Edition

Veröffentlicht am von — Keine Kommentare ↓

Problem

Muss man einen Server neu installieren, wenn man im Setup die falsche Version des Windows Server 2012 ausgewählt hat?

Antwort: Nein, man kann Windows Server 2012 Standard Edition jederzeit auf Windows Server Datacenter Edition aktualisieren.

Anzeigen der verwendeten Edition:

c:\> DISM /online /Get-CurrentEdition

Lösung

  1. Herausfinden, ob wenn ja welches Upgrade möglich ist: 
    c:\> DISM /online /Get-TargetEditions
  2. Upgrade durchführen: 
    c:\> DISM /Online /Set-Edition:ServerDatacenter /AcceptEula /ProductKey: 48HP8-DN98B-MYWDG-T2DCC-8W83P

Der hier angegebene Key ist der KMS Client Setup Key, der für sich genommen nicht zur Produktnutzung berechtigt. Alle KMS-Setup-Schlüssel gibt’s imTechnet unter http://technet.microsoft.com/en-us/library/jj612867.aspx

windows-server2012-standart-datacenter-upgrade

Powershell Sicherheitswarnung für PS1-Scripts trotz „unrestricted“ loswerden

Veröffentlicht am von — 4 Kommentare ↓

Das man an der Kommandozeile nahezu keine selbst- oder Fremdgebauten PS-Scripts ausführen kann hat sich mittlerweile herumgesprochen. Das kaum ein Admin seine kleinen Helferchen einzeln und bei jeder Änderung signieren wird ist ebeso offensichtlich.

Umso ärgerlicher, als das der Script-aktive Admin ab und an über den doppelten Boden der Powershell-Ausführungsverhinderung stolpert. Trotz der ExecutionPolicy ohne Restriktionen:

Set-ExecutionPolicy Unrestricted

gibt es doch weiterhin Scriptausführungsverhinderungen die sich in deutlich nicht-aussagekräftigen Fehlermeldung an der Kommandozeile und ISE bemerkbar machen:

powershell-ise-warnung

 

…  an der Shell:

PS C:scripts> .format-c.ps1
Sicherheitswarnung
Führen Sie ausschließlich vertrauenswürdige Skripts aus. Skripts aus dem Internet können zwar nützlich sein,
stellen jedoch auch eine potenzielle Gefahr für Ihren Computer dar. Möchten Sie "C:scriptsformat-c.ps1"
ausführen?
[N] Nicht ausführen  [M] Einmal ausführen  [H] Anhalten  [?] Hilfe (Standard ist "N"):

Automatisierungen jeder Art sind so offensichtlich undurchführbar und auch das deutlichste „Als Stapelverarbeitungsauftrag anmelden“ Recht verpufft an diesem Scriptverhüterli wirkungslos.

Lösung

Seit Windows 8 und dem zugehörigen Server 2012 gibt es im Dateisystem ein magisches Flag, das die (telepatisch festgestellte) Herkunft des Scripts als lokal oder „Siebter Kreis der Hölle“ markiert. Das Flag lässt sich mit einem Klick auf „Zulassen“ in den Dateieigenschaften wie für die lokale Ausführung erwartet zulassen.

powershell-ise-warnung-loesung

Selbstverständlich ist der Vorgang irreversibel, denn die telepatischen Fähigkeiten von Windows sind über jeden Zweifel erhaben. Die Anwesenheit des Flags lässt sich durch kopieren/einfügen beibehalten, durch Snippletkopiererei (ein TOTAL ungewöhnlicher Vorgang beim scripten) reproduzieren und nicht automatisiert beheben.

Windows Server 2012 schwarzer Bildschirm nach der Anmeldung (sowohl RDS/RDP/Lokal)

Veröffentlicht am von — 3 Kommentare ↓

Windows Server 2012 und Server 2008/R2 können dem gestandenen Admin ab und an auch mal neue Schrecken einjagen. Praktisch direkt nach der Installation, dem ersten Schwung Updates und vielleicht ein bisschen Rollen-Gewühle bleibt nach einem Reboot der fast-frische Serverbildschirm nach dem Login plötzlich schwarz. Sowohl via RDP als auch bei der loaklen Anmeldung – alles schwarz. STRG+ALT+ENTF zaubert zwar den Taskmanager-Auswahlbildschirm wieder in die sichtbare Realität, mehr aber auch nicht. Ich habe dieses Phänomen jetzt unter VMWare gesehen, unter Hyper-V und auf echter Hardware (selten, aber sowas gibt’s noch). Hardware ist nicht schuld.

Im Eventlog, das via RPC erreichbar ist, offenbart sich der Effekt durch die Warnung:

The Windows logon process has failed to spawn a user application. Application name: . Command line parameters: C:Windowssystem32userinit.exe.

Lösung

Der Fehler liegt irgendwo zwischen der Erzeugung des Twintoken bei der Anmeldung und der UAC-Steuerung. Beides benötigt zur Anzeige rechte für die Interaktive Anmeldung; irgendetwas zerstört offenbar diese (lokal). Daher: Die lokale Gruppe „Benutzer“ verfüg über diese – und bekommt die beiden neuen Mitglieder „Authentifizierte Benutzer“ und „Interaktive Anmeldung“. Das ist remote möglich – reboot und der Bildschirm ist wieder da. Auf einem DC gibt es bekanntlich keine Lokalen Gruppen, daher müssen für solche Server die Domänen-Prinzipale in builtin herhalten. Einfach dort beide Prinzipale einfügen, fertig.