Aufgrund einer Domänenumstellung bei einem Kunden war es erforderlich den Befehl ADPREP von einer Windows Server 2008 R2-CD auszuführen.

Dabei musste auf einem Domänencontroller mit Windows Server 2003 R2 (32-Bit) eine Schemavorbereitung für eine Windows Server 2008 R2 Domäne durchgeführt werden.

Dieses stellt im eigentlichen kein Problem dar, wenn man an eine Kleinigkeit denkt:

• Befehl “adprep” für 64-Bit-Systeme verfügbar
• Befehl “adprep32″ für 32-Bit-Systeme verfügbar

Ich hatte leider noch eine ältere Zusammenstellung in meinen Unterlagen gefunden, wo der diese Unterscheidung leider nicht noch dokumentiert war.

Somit konnte ich mit dem entsprechenden Befehlen die Domäne auf ihre Umstellung auf einem Windows Server 2008 R2-Domänencontroller vorbereitet werden:

adprep32 /forestprep

adprep32 /domainprep /gpprep

Nach dem Hinzufügen des ersten Domänencontrollers sollte noch der folgende Befehl ausgeführt werden.

adprep32 /rodcprep

Somit hat man  Befehl komplett für die Umstellung genutzt.

Für den vereinfachten Support durch Mitarbeiter anderer Nationen sollte auf einem Server eine zusätzliche Sprache zur englischen Standard-Installation. Mit folgendem Vorgehen kann ein weitere Sprache auf dem Server installiert werden:

• Herunterladen des erforderlichen LanguagePack-ISO
• Brennen des Mediums
• Aufrufen einer Konando-Konsole mit administrativen Rechten
• Befehl “lpksetup.exe” eingeben und mit der ENTER-Taste bestätigen
• “Install display language” auswählen
• Über “Browse” das entsprechende LanguagePack auf dem Medium auswählen
• Sprache wird entspreechend angezeigt und kann über “Next” installiert werden
• Bestätigung der Lizenzbedingungen durchführen
• Die Installation dauert nun eine ganze Weile
• Mit “Next” zur Sprachauswahl weitergehen

Nun kann die neue Standard-Sprache ausgewählt werden oder über “Close” die Installation beendet.

Wenn eine neue Standard-Sprache für die Systembenutzer und das Begrüßungsfenster ausgewählt wird, muss der Server durchgestartet werden. Wenn im Nachgang ein Anwender seine persönliche Spracheinstellung anpasst, wird eine Abmeldung des Benutzers erforderlich.

Nachdem ich nun den Terminalserver im lokalen Netzwerk nutzen konnte, interessierte mich halt auch in wieweit man den Server direkt über das Internet erreichen konnte.

Es war logisch, dass Ports in der Firewall freigeschaufelt werden mussten. Neben dem Port für das HTTPS-Protokoll 443 musste auch der Port 3389 für den Remote Desktop (jeweils TCP) zum Server durchgeleitet werden. Mit diesen Einstellungen Gels mir. Dreist eine Benutzerauthentifizierung am Webinterface.

Leider war es mir über den bereits im Router eingerichteten DynDns-Account nicht möglich direkt auf die Applikationen zugreifen, da mir die Fehlermeldung mitteilte, dass er den Server nicht erreichen könne, wobei ich diesen per Remote Desktop direkt aufrufen konnte.

Mein Fehler lag in der Konfiguration des Remote Desktop Services. Dort hatte ich den lokalen Servernamen des Systems eingetragen. Nach dem ich nun den die Verbindungseinstellungen auf den DynDns-Eintrag angepasst hatte und einen Reboot durchführte war es mir nun möglich aus dem Internet auf den Dienst zuzugreifen.

Des Weiteren muss man sich darüber im klaren sein, dass aufgrund der nun aktivieren Einstellung auch für den internen Zugriff auf das System standardmässig die Verbindung über das Internet gewählt wird, so dass es zu einem entsprechenden Leistungsengpass auf der Netzwerkanbindung kommen kann.

Sollte man ein entsprechendes System länger im Internet betreiben sollen, sollten man sich auf jeden Fall weitere Gedanken über den Punkt Security machen. Zum Beispiel ist es ebenfalls in der Konfigurationsmaske des Host Servers möglich den Port des abhörenden RDP-Kanals auf einen anderen Port anzupassen, so das ein Direktzugriff per DNS-Auflösung und Standard-Port nicht entsprechend einfach möglich ist.

Für ein Projekt durfte ich mich mit dem Remote Desktop Web Access beschäftigen, welcher in meinem Fall unter den Remote Desktop Services einer Windows Server 2008 R2 zur Verfügung gestellt wird.

Nach der Installation sollte statt dem Standard-Seiten-Titel “Remote Desktop Services Default Connection” ein individueller Name erscheinen. Dieses war möglich in dem eine Änderung in der folgenden Datei durchgeführt wurde:

Datei:  C:\Windows\Web\RDWeb\App_Data\RDWebAccess.Config
Eintrag: <WorkspaceSettings Name=”RD WEB ACCESS – DEMO”>
Dort kann nach der oben genannten Bezeichnung gesucht werden, um das Ersetzen zu erleichtern, da “RD WEBACCESS – DEMO” nur ein Beispiel darstellt

Anschließend wurde bemängelt,  das es eine theoretische Möglichkeit gibt, dass Anwender sich auf ihren eigenen PC oder auf die Server-Landschaft über den Eintrag “Remote Desktop” verbinden könnten. Dieses wurde über eine Änderung einer anderen Datei nur für Administratoren erlaubt:

Datei: C:\Windows\Web\RDWeb\Pages\en-US\Default.aspx
alter Eintrag:
    if (ConfigurationManager.AppSettings["ShowDesktops"].ToString() == “true”)
    {
%>
                              <td width=”15″>&nbsp;</td>
                              <td>|</td>
                              <td width=”15″>&nbsp;</td>
                              <td><a href=”Desktops.aspx” target=”_self” id=’PORTAL_REMOTE_DESKTOPS’><%=L_DesktopTab_Text%></a></td>
<%
    }
neuer Eintrag:
    if (RDWebAccessConfig.UseRDWebAccessConfiguration() && fUserAdmin)
    {
%>
                              <td width=”15″>&nbsp;</td>
                              <td>|</td>
                              <td width=”15″>&nbsp;</td>
                              <td><a href=”Desktops.aspx” target=”_self” id=’PORTAL_REMOTE_DESKTOPS’><%=L_DesktopTab_Text%></a></td>
<%
    }

Somit steht der Bereich um eine Remote Desktop-Verbindung herzustellen nur noch für Administratoren zur Verfügung.

Da ich davon ausgehe, dass ich noch weitere Anpassungen durchführen werde habe ich hinter der Überschrift eine “1″ gesetzt; für eine “2″ habe ich auf jedenfall noch Stoff, der ausgearbeitet werden will.

Aufgrund einer Aufgabenstellung eines Kunden musste auf mehreren hundert Ordnern ein Benutzer hinzugefügt werden. Da in der Kundeninfrastruktur des Anforderers ein Windows Server 2008 zum Einsatz kommt, habe ich statt dem “alten” Befehls cacls den Befehl icacls genutzt:

icacls “Pfad” /grant “Benutzer oder Grupppe”:(OI)(CI)M  /T

Durch diesen Befehl wird auf dem angegebenen Pfad der Benutzer oder die Gruppe mit dem “Modify”-Recht ausgestattet. Dieses wird auch ab dieser Ebene auf alle weiter tieferliegende Gruppen vererbt.

Statt dem “Modify”-Recht können selbstverständlich auch andere Werte gesetzt werden:

• F  = Vollzugriff (full access)
• M = Ändern(modify access)
• RX = Lesen und Ausführen (read and execute access)
• R = Lesen (read-only access)
• W = Schreiben (write-only access)

Weitere Informationen:
Link

Ich habe gestern für eine neue Testumgebung mal wieder einen Widnows Server 2008 R2 installiert. Dabei viel mir mal wieder auf, das beim Start des Benutzerprofils immer wieder der “Server-Manager” angezeigt wird.

Es gibt nun 2 Arten diesen zu deaktivieren:

Wenn der Server in einem Active Directory eingerichtet ist, kann dieses per Gruppenrichtlinie deaktiviert werden:
Pfad: Computerkonfiguration\Administrative Vorlagen\System\Server-Manager
Eintrag:  Server Manager bei Anmeldung nicht automatisch anzeigen.
Dieser muss “aktiviert” werden

Da es sich um eine Testumgebung bei mir handelte und der Server nicht in einer Domäne zur Verfügung stand, habe ich folgendes gemacht:

Aufrufen der “Aufgabenplanung”
Aufgabenbibliothek – Microsoft -Windows – Server Manager aufgerufen
Eintrag “ServerManager” deaktiviert

Somit werde ich bei diesem Server und allen Benutzern nicht mehr von dem Server Manager “gestört”.

Sollte man den Server Manager doch benötigen, dann man über das Kontextmenü “Verwalten” unter dem Punkt “Computer” diesen aufrufen.