departure

@Christian R: In dem Augenblick, in dem der Host-Server durch Einschalten der HYPER-V-Rolle zum HYPER-V wird, zeigt Dir der Taskmanager nicht mehr den korrekten, insbesondere durch virtuelle Maschinen ausgelösten RAM-Verbrauch an. Zur Performanceanalyse sind ab diesem Zeitpunkt andere Methoden nötig, als mal eben den Taskmanager des Host aufzurufen. Womit dies geschehen kann, ist bei Microsoft im Technet und in verschiedenen MS-Blogs nachzulesen. Ein Windows Server mit aktiviertem Hyper-V ist eben kein normaler Server mehr. Durch diese relativ leicht zu gewinnende Erkenntnis hättest Du Dir wahrscheinlich einiges an Arbeit (jedoch nichts an Hardware) gespart. Grüße von departure

Stop - hier muß ich mich entschuldigen, ich habe das nicht richtig dargestellt. Der Dozent hat nicht dazu aufgefordert, hosts zu nutzen, sondern allgemein die Möglichkeiten der Namensauflösung aufgezählt, genauso wie deren Historie und Priorität (lokale hosts-Einträge werden bspw. zuerst ausgewertet). Das gehörte zum Lehrstoff und stand auch im entspr. MOC-Buch so drin. Er war auf jeden Fall ein Wins-Befürworter und seine Argumente fand ich durchaus einleuchtend - Wins ist kostenlos, braucht (so gut wie) keine Performance, ist einfach einzurichten und hilft bei vielen Problemen. Wenn man mal danach googelt, findet man genügend Beispiele (auch aktuelle aus den Jahren 2010/2011), wo Wins nützlich, sogar notwendig ist. Warum es dann nicht pauschal nutzen? Kaputt macht es jedenfalls nichts. Grüße von departure

Nö, hat er nicht. Er kannte aber die Spezifikation und wußte, daß die IPv6-Adressen 32 Stellen haben werden (habe in meinem vorletzten Post versehentlich "50" geschrieben, doch ich denke, daß auch "nur" 32 Stellen zu lang sind zum auswendig lernen). Grüße von departure

In seiner geposteten ipconfig-Ausgabe steht, daß er sehr wohl DNS und WINS hat, werden sicherlich per DHCP mitübergeben. Aktivier' testhalber mal NetBIOS über TCP-IP.

Computerbrowserdienst am Domänencontroller läuft noch?

Nein keineswegs, er meinte das genau so (Kursteilnehmer hatten da auch nachgehakt) und ich halte das auch nicht für Stuss. Er erklärte, das eine funktionierende Namensauflösung immer wichtiger werden wird. Viele Admins können IPv4-Adressen in ihrem Netzwerk, zumindest die wichtigsten, auswendig. Irgendwann ist IPv6 Standard, und diese Adressen lernt sicherlich niemand mehr auswendig (haben 50 Stellen!). Wie gesagt, umso wichtiger wird eine funktionierende Namensauflösung sein. Und dann sollte man die zur Verfügung stehenden Methoden zur Namensauflösung, vor allen Dingen auch, wenn sie nichts kosten, also kein Geld und keine Performance und kaum Arbeitszeit, auch nutzen. Dein Link aus Antwort 3 zählt da einiges auf, was hinsichtlich WINS auch heute immer noch wichtig sein kann. Grüße von departure

Ich habe im MCSA-Kurs gelernt, daß jede zur Verfügung stehende Namensauflösungsmethode auch genutzt werden sollte. Angefangen bei der lokalen Hosts bis hin zu DNS und WINS. Wins ist kostenlos, verbraucht keine spürbaren Ressourcen (meßbar ja, spürbar nein) und macht dem Admin auch keine Arbeit (einmal im DHCP miteingetragen und läuft). Grüße von departure

Du mußt zwischen Dienstname und der Namensanzeige in den Diensten (die Du mit "services.msc" aufrufst) unterscheiden. Der Wsus-Dienst ansich ist bei den Diensten als "Update Services" gelistet, der Dienst HEISST aber "WsusService". Die WSUS-Datenbank wird gelistet als "Windows Internal Database (MICROSOFT##SSEE)", der Dienstname lautet aber "MSSQL$MICROSOFT##SSEE". IIS ist gelistet als "IIS-Verwaltungsdienst", der Name des Dienstes lautet aber "IISADMIN". Wie Du siehst, sind die Listeneinträge unter "Dienste" durchaus auch mal in Deutsch, die echten Dienstnamen aber eigentlich immer in englischer Sprache. Müßte beim SBS ebenfalls so sein.

O.K, ich hab' einen dedizierten WSUS, da hätte ich kein Problem damit. Doch warum soll sich die WSUS-Installation auf einem SBS nicht genauso entfernen (und danach neu installieren) lassen?

Mach ihn neu! Ich weiß nicht, ob Du das geschilderte Problem noch irgendwie gebacken kriegst, doch ich würde mit dieser Installation nicht mehr herumeiern. Sorge dafür, daß genügend Platz für den WSUS-Content vorhanden ist (bloß nicht auf C:\, was leider Standardvorgabe ist)! Es ist nicht grundsätzlich falsch, alle Updates pauschal zu genehmigen (hat mir nur seltenst Probleme eingebracht, vielleicht höchstens einmal pro Jahr), doch Du mußt auf jeden Fall dafür Sorge tragen, daß Du die Produkte und Klassifizierungen klug auswählst, Zeug, daß nur "Nice 2 Have" ist oder "brauche ich vielleicht irgendwann mal", würde ich weglassen. Schreib' Dir ein Skript, daß Dir per Windows-Taskplaner einmal täglich die DB sichert, wenn der WSUS mal einige Zeit gelaufen ist, wird es mit der Reproduktion schwierig. Beispielskript für die DB-Sicherung (die Pfade natürlich auf Deine anpassen, den Ordner "WSUS-Config-Backup" mußt Du vorher einmalig von Hand anlegen): net stop MSSQL$MICROSOFT##SSEE d: cd D:\WSUS\UpdateServicesDbFiles dir xcopy /C /H /R /Y *.* D:\WSUS-Config-Backup net start MSSQL$MICROSOFT##SSEE Wenn Du noch Fragen hast, melde Dich nochmal. Grüße von departure

Das hatten wir erst vor kurzer Zeit. In aller Kürze: Per GPO ist soweit richtig, es kommt jedoch auf das OS an. Seit Windows 6.X (also Vista/2008 und höher) wirken die alten Einstellungen nicht mehr, die funktionierten bloß bis inkl. Windows 2003. Ausführlicher steht es hier: http://www.mcseboard.de/windows-server-forum-78/terminalserver-computer-netzwerk-179238.html Grüße von departure

Genau kann ich's im Moment nicht sagen, doch ich glaube, man kann die bereits vorgeschlagenen Verzeichnisse um weitere erweitern (fuchtel doch mal ein bißchen mit der rechten Maustaste herum, vielleicht zeigt sich in irgendeinem Kontextmenü in den GPO's ein "Hinzufügen" oder ähnliches). Sorry, weiß es im Moment nicht genauer, aber ich weiß sicher, daß auch Favoriten umgeleitet werden können. Grüße von departure

Sorry, dann bin ich erstmal Rudi Ratlos. Vielleicht weiß noch jemand was (die allgemeine Aussage, daß die Remote-Protokolle zur TS-Nutzung von Microsoft und Citrix halt so ihre Macken haben und Dinge wie Icons u. a. gern mal durcheinanderwirbeln, war auch bloß vermutet, daß das hier eine Erklärung sein könnte). Was passiert, wenn Du die Symbolzuweisung bei einem User mit falschem Symbol einfach mal erzwingst (re. Maustaste auf Verknüpfung, Eigenschaften, Register "Verknüpfung", Button "Anderes Symbol", korrektes Symbol doppelklicken)? Verändert es sich dann zum ausgewählten (also dann zum richtigen Symbol) und bleibt's dann über den Reboot und die nächste Anmeldung hinaus erhalten? Falls ja, was passiert danach, wenn dann wieder der Administrator-Account dazwischenplatzt? Grüße von departure P.S.: Ich will Dich absolut nicht bevormunden, es ist Dein Netzwerk, aber ich würde wirklich nicht mehr mit DEM Administrator arbeiten, das ist wirklich gefährlich! Ein Sicherheitsprofi würde Dir das bei einem Audit auch garantiert so sagen!

@nicholasdille: Das funktioniert aber nur, wenn es sich um den ICA-Client für Windows handelt (egal ob an einem FAT-Client oder einem ThinClient installiert). Unter Linux und OSX sieht's diesbezüglich sehr düster aus. Liegt auch daran, daß Citrix den ICA-Client für Windows bevorzugt behandelt (und das auch zugibt). Der ICA-Client für Linux ist bei Citrix immer noch auf Version 11.X, der für Windows schon länger auf Version 12. Leider. Wir haben auch noch jede Menge Linux-Thinclients und müssen wegen eines Archivierungssystems immer mehr einscannen. Grüße von departure

Den Rest, außer den Eigenen Dateien (also das Userhome, das Du hoffentlich über das Basislaufwerk des Nutzers im AD steuerst), kannst Du doch recht simpel mit einem täglich per Taskplaner laufenden Skript abfackeln. Noch eleganter wäre ein Ordnerumleitung (läßt sich per GPO einstellen), die meisten Inhalte des Nutzerprofils lassen sich nämlich ins Basislaufwerk des Nutzers (also in das Userhome im Netzwerk) umleiten. Doch Vorsicht, es gibt Ausnahmen (nächster Absatz). Und bezüglich deiner letzten Frage: Ich weiß nicht, was mit einem Profil passiert, in das von 2 verschiedenen Systemen aus (FAT-Client und Terminalserver) gleichzeitig (!) hineingeschrieben wird. Zumindest die ntuser.dat und auch die *.pol-Datei sehe ich da in größter Gefahr. Auch manche Inhalte des Ordners "Anwendungsdaten" ("AppData") würden dabei korrumpiert, fürchte ich. Nicht umsonst trennt Microsoft in den Eigenschaften des Nutzers im Active Directory sehr strikt nach "Profile" und "Terminaldienst- bzw. Remotedesktopdienstprofile" (sieh' Dir die beiden Registerkarten mal an, sehen zwar gleich aus, die eine ist aber für FAT-Clients gedacht, die andere für Terminalserver). Grüße von departure

@Dukel: Wenn das so gewollt ist, verstößt das aber so ziemlich gegen alles, was ich in Kursen über SID's gelesen und gehört habe. Bitgenau gleiche Rechnergeschwister mit gleicher SID im selben Netzwerk galten bisher als tödlich für ein ordentlich funktionierendes Netzwerk. Doch wahrscheinlich bin ich da nicht mehr so ganz auf dem neuesten Stand ... Grüße von departure

@NilsK: Der Rechner in der Zweigstelle, an dem ab und zu mal ein Mitarbeiter aus der Zentrale hockt, muß doch deswegen trotzdem nicht in die Domäne aufgenommen werden. RDP funktioniert doch auch nur mit reinem TCP-IP.

Ich kenne die genannte VMware-Clone-Technik nicht, doch ganz offensichtlich ist hier kein ordentliches Sysprep gelaufen. Wäre das der Fall, wäre jeder VDI-Rechner hinsichtlich seiner SID's ein Unikat und es würde sich nicht jedesmal das Masterimage am Lizenzserver melden. Damit scheint das irgendwie zusammenzuhängen, ich würde mal in diese Richtung weiterforschen. Noch eine Frage: Wie gesagt, ich kenne die genannte VMware-Technik nicht, aber kann es sein, daß diese geklonten Rechner die erhaltene Lizenz (die Gültigkeitsdauer beträgt übrigens irgendwas zwischen 59 und 89 Tagen, das ist dynamisch) nicht speichern können? Bei ThinClients ist das immer so, da werden die Lics stattdessen in der Registrierung der Terminalserver abgelegt ("bucket"). Der Terminalserver unterscheidet das anhand des Clientbetriebssystems. Kommt ein Linux-ThinClient, ein Mac-Rechner oder ein Windows-Embedded-ThinClient, weiß der TS, daß er die gezognen Lizenzen in seiner Registry als sog. "buckets" ablegen muß. Kommt ein herkömmliches Windows-FAT-Client-OS (XP, Vista oder 7), speichern sich diese Clients die TS-CAL in ihrem eigenen System. Wenn Deine Clients das nicht können (aus welchem Grund jetzt auch immer), hat der Terminalserver ein Problem. Er erkennt ein XP, Vista oder 7, das um Terminalverbindung ersucht, prüft die TS-Cal beim LicServer und weiß, daß diese Betriebssysteme sich ihre TS-Lizenz selber abspeichern, er schreibt also kein bucket in seine Registry. Wenn dann Deine VMware-geklonten, virtuellen Recher die TS-Lic nicht speichern, ist bei jedem anmelden eine neue fällig und Deine Lizenzen gehen zur Neige. Irgendwas stimmt mit Deinen Klonen nicht, so sieht es für mich aus.

Ist gewiß keine Lizenzsache (weil Du das am Ende Deines Postings extra erwähntest). Ist der Effekt tatsächlich gleich wieder da, wenn sich der Adminstrator nach dem Neustart des Servers nur anmeldet, oder erst dann, wenn der Admin Outlook öffnet? Ist tatsächlich "DER" adminstrator (also "administrator@local.domäne.de") gemeint, oder der pers. Useraccount eines IT-Mitarbeiters mit administrativen Rechten (also z.B. Dein Account)? Ist es der erstere, frage ich mich, warum der administrator Outlook öffnen sollte? Mit diesem Account sollte eigentlich gar nicht gearbeitet werden und sein PWD sollte im Tresor liegen, administrative Tätigkeiten sollten mit administrativen Hilfsaccounts, deren Accountbezeichnungen kein User erraten kann, erledigt werden. "Administrator" kennt jeder, wenn dann mal unglücklicherweise und versehentlich das PWD ausgeplappert wird, ist dann plötzlich der Mitarbeiter "Hans Wurst" aus der Finanzabteilung Chef der gesamten Windows-Domäne. Hier also aufpassen. Falls Du hingegen Deinen eigenen Account meintest (der am Terminalserver Outlook öffnet und danach sind Outlook- und PP-Icon vertauscht), nehme ich den Vorwurf zurück. Was ich allgemein zur Nutzung des Administrator-Accounts gesagt habe, gilt trotzdem. Ansonsten weiß ich, daß beide für Terminaldienste verfügbaren Protokolle (RDP oder ICA, falls man Citrix im Einsatz hat) hier die Schwäche haben, manches durcheinanderzuwirbeln. Programmicons zählen eindeutig dazu. Oder zum Beispiel auch, daß ein User in Microsoft Word plötzlich die Recent-Liste eines anderen Users hat und umgekehrt.

Bau sein FAT-Client-Profil (das vom normalen Rechner in der Zentrale) auf dem Terminalserver passend nach (kopieren würde ich es nicht, ein TS-Profil ist anders aufgebaut als ein FAT-Client-Profil) und mach dies zum serverbasierenden Remotedesktop- bzw. Terminaldiensteprofil für Herrn Meier. Eine passende Netzwerkfreigabe für solche Profile wirst Du sicherlich schon haben. Gib Herrn Meier's RDP-Client in der Zentrale die Option mit, daß nur das Fachprogramm im Vollbild gestartet werden soll. Ist er in der Filiale/Zweigstelle, soll die RDP-Verbindung keine Angabe zu einem exra zu startenden Programm haben, dann kriegt er den vollen Desktop. Ich würde also über die RDP-Clientkonfiguration bzw. die RDP-Datei steuern, ob er direkt das Fachprogramm (im Vollbild) gestartet kriegt (Zentrale) oder kein Fachprogramm (und somit den vollen Desktop auf Terminalserver) wenn er in der Zweigstelle ist. Das wirklich "gleiche" Profil wie auf dem FAT-Client "ZentralePC1" wird es also niemals sein, weil das nicht geht, FAT-Client-Profile lassen sich nicht direkt auf Terminalserver nutzen und umgekehrt, aber zumindest wird es ein sehr ähnliches Profil sein (hängt auch davon ab, wie genau, detailliert und vollständig Du es ihm "nachbaust"). In das serverbasierende Terminaldienst-bzw. Remotedesktopdienstprofil würde ich natürlich (vielleicht per Login-Script) seine vom FAT-Client gewohnten Netzwerkressourcen (gemeinsam genutzte, zentrale Verzeichnisse, zum Beispiel) und sein Home-Laufwerk einhängen, damit das Terminaldienstprofil dem FAT-Client-Profil möglichst gleich oder ähnlich ist. Grüße von departure

Ich meine, daß in diesem Verzeichnis auch die aufbereiteten Druckdateien liegen. Normalerweise werden die nach erfolgreichem Ausdruck von selbst wieder gelöscht, ich hatte aber auch schon Druckserver, wo die Druckdateien stehengeblieben sind (warum auch immer). Sind *.shd- oder *.spl-Dateien dabei? Falls ja, sind das stehengebliebene Druckaufträge. Du kannst ja am Datum sehen, von wann die sind. Alle, die älter sind als von heute, kannst Du löschen. Außerdem würde ich die Dienste "TCP/IP-Druckserver" und "Druckerwarteschlange" mal neu starten ("net stop spooler" und "net start spooler"). Sieh' außerdem im Dialog "Eigenschaften von Druckserver" mal nach, was da an Treibern so los ist. Vielleicht gibt's ja Dubletten: Grüße von departure

Excel? Ein "Zusammenführen", am besten noch automatisch, wie soll das gehen? Beispiel: Der Außendienstler ändert im Excel-Sheet "Dokument1.xls" in Zelle D24 den bisher angegebenen Wert von "0,03" auf "0,04", währenddessen die Sekretärin den Wert zeitgleich auf "0,05" ändert. Das sind sich widersprechende Inhalte, das läßt sich nicht "zusammenführen". Kannst Du Deinem Chef mal direkt so sagen. Was sicherlich geht ist eine Versionierung, die auf verschiedene Art und Weise (z. B. nach Kriterien wie "Wer" oder "Wann") organisert werden kann. Und dazu gibt es vermutlich auch technische Hilfe in Form von Software. Kenne aber leider keine. Grüße von departure

Hier sind wahrscheinlich serverbasierende Profile im Einsatz. Und da seit Vista/2008/7/2008R2 auch alles, was der User so an Daten produziert, im Userprofile liegt (Dokumente, Videos, Bilder, Downloads, Favoriten usw. usf.) wird das bei Abmeldung brav ins serverbasierende Profil zurückgeschrieben (was ja bei serverbasierenden Profilen auch so sein soll). Meldet sich der User am nächsten TS an, wird dann latürnich wieder alles aus dem serverbasierenden Profil geholt. Deine Lösung (also auf jedem Server ein eigenes Profil): Keine serverbasierenden Profile verwenden! Diese Zeile in den AD-Eigenschaften des/der User muß leer sein: Viele Grüße von departure

Hab' jetzt nochmal nachgesehen, was der RDP-Verbindung noch ein bißchen auf die Sprünge helfen könnte: - am Client den jeweils jüngsten, neuesten, aktuellsten RDP-Client installieren (aktuelle Version unter Windows: RDP 7.0, unter WVista und W7 müßte der neueste Client per WU automatisch hereinkommen, unter XP ist es nur ein optionales Update: WindowsXP-KB969084-x86-deu und danach noch ein Patch: WindowsXP-KB2483614-x86-DEU) - Farbtiefe, die vom Server kommt und auch am Client auf 15-Bit-Farben reduzieren (reicht für normalen Bürobetrieb vollkommen aus, das menschliche Auge kann kaum mehr als diese ca. 32.000 Farben bei 15-Bit unterscheiden). Max. 16-Bit-Farben (das sind dann ca. 65.000 Farben). Auch die Farbvielfalt muß durchs RDP-Protokoll übertragen werden, wird diese reduziert, kann sich eine Verbesserung ergeben. So, Latein am Ende. Wenn Dich die Schwächen von RDP auch noch in anderer Hinsicht quälen (hier gibt's ein paar Threads dazu, z.B. USB-Flachbettcanner am Thinclient in die TS-Session per RDP u. a.), kann es sich mittel- bis langfristig lohnen, doch zu Citrix zu greifen. Grüße von departure

Ich wüßte jetzt keine Lösung für den gegenwärtigen Zustand, den Du beschreibst. Was jedoch helfen könnte (1.) oder ganz sicher helfen würde (2.) kann ich Dir sagen. Beide Möglichkeiten machen Arbeit, eine davon ist zudem auch noch teuer (die zweite): 1. Das RDP-Protokoll beim Server 2008 R2 wurde gegenüber dem Server 2008 verbessert. Zudem verfügt der 2008 R2 seit Service Pack 1 über das Remote-FX-Feature, das in Deinem Fall helfen könnte. Also Server aktualisieren. 2. Citrix installieren (mind. Citrix Presentation Server 4.5, welcher gegen über 4.0 multimediaoptimiert wurde). Zudem ist das ICA-Protokoll dem RDP-Protokoll schon immer überlegen. Achtung, teuer! Mehr weiß ich leider nicht. Grüße von departure