Allerdings irritiert immer mehr Benutzer die Tatsache, dass oft nicht der gesamte physikalisch eingebaute Speicher vom Betriebsystem genutzt werden kann. Obwohl zum Beispiel das Mainboard vier 1 GB RAM-Riegel unterstützt und der gesamte Speicher von 4 GB im BIOS angezeigt wird, kann man oftmals nur 2.8 – 3.5 GB davon effektiv benutzen. Die Schuld schiebt der Benutzer dann schnell auf das Betriebsystem. Woran liegt es aber wirklich?

Wenn man mehr als 2 GB Hauptspeicher in x86-Systeme einbaut, ist es normal, dass nicht der gesamte physikalische Hauptspeicher benutzt werden kann. Der Grund dafür sind Ressourcenkonflikte durch die 32-bit-Technologie. Da das BIOS nicht weiß, ob ein 32-bit oder 64-bit Betriebsystem gebootet wird, startet es immer im 32-bit Mode. Darin stehen maximal 4 GB addressierbarer Speicher zur Verfügung. Deshalb müssen alle Memory- und Device-Adressräume unterhalb der 4 GB-Grenze eingeblendet werden. Wenn man nun >2 GB physikalischen Hauptspeicher einbaut, dann kommt es zum Ressourcenkoflikt zwischen physikalischem Hauptspeicher und den Device-Adressräumen.

Die meisten BIOS-Versionen lösen das Problem in der Form, dass sie ein Speicherloch unterhalb der 4 GB-Grenze einfügen. Dieses Loch wird auch als PCI-Loch (PCI Hole) bezeichnet. Der Speicher, den dieses Loch belegt, kann von keinem Betriebsystem angesteuert werden. Dadurch bleiben ~512 MB bis ~1.5 GB RAM ungenutzt. Es ist dabei unabhängig, ob es sich um ein 32-bit oder 64-bit OS handelt.

Die einzige Möglichkeit, diesen Speicher nutzbar zu machen, ist die Verlagerung in einen Bereich, der oberhalb von 4 GB liegt und nicht durch physikalischen Speicher schon belegt ist. Dazu bedarf es aber einiger Voraussetzungen:

• Betriebsystemunterstützung
  Das Betriebsystem muss Speicher >4 GB ansprechen können. Windows 2000, Windows XP, Windows Server 2003 und Windows Vista unterstützen in den Standardvarianten mit 32-bit maximal 4 GB RAM. Die Advanced-, Enterprise- und Datacenter-Produkte sowie die 64-bit-Versionen können mehr Speicher addressieren, wobei die Grenzen hier von den jeweiligen Versionen abhängen und bis zu 1 TB reichen können.
• Prozessorunterstützung
  Intel und AMD unterstützen 40-bit Addressierung in ihren aktuellen x64-Prozessoren (Intel EM64T/AMD64). Ältere Prozessoren sind auf 36-bit (PAE) oder auch 32-bit limitiert.
• Chipsatzunterstützung
  Der Chipsatz des Mainboards muss Memory Remapping oberhalb von 4GB unterstützen. Leider beherrscht die grosse Mehrheit der derzeit auf dem Markt erhältlichen Chipsätze für Desktops und mobile Computer genau diese Funktion nicht. Sie lässt sich auch nicht mittels eines BIOS-Updates nachrüsten. Erst die Workstation-Chipsätze von AMD und nVidia sowie demnächst erscheinende neue Chipsätze für Desktops und mobile Computer unterstützen mehr als 4 GB RAM und können die Hauptspeicheradressen zur Umgehung des PCI-Lochs verlagern.

Wie kann man nun die vollen 4 GB nutzen?

Windows kann prinzipiell den Hauptspeicher, der durch die Verlagerung zur Umgehung des PCI-Lochs oberhalb von 4 GB angesprochen werden kann, unterhalb der 4GB-Grenze einblenden. Voraussetzung dafür sind aber die obigen drei Punkte:

1. Kann die verwendete Windows-Version Speicher oberhalb von 4GB ansprechen?
   Die Antwort lautet nein für 32-bit und ja für 64-bit.
2. Kann der Prozessor Speicher oberhalb von 4 GB ansprechen?
   Bei aktuellen Modellen besteht eine hohe Wahrscheinlichkeit, dass Speicher oberhalb von 4 GB angesprochen werden kann. Bei AMD64 und EM64T ist die Unterstützung zum Beispiel gegeben.
3. Erlaubt der Chipsatz Memory Remapping und ist die Funktion im BIOS konfigurierbar?
   Die allermeisten Chipsätze können das nicht. Deswegen hilft auf der Umstieg auf ein 64-bit Betriebsystem nicht weiter.
   Aus diesem Grund kann auch ich mit meinem neuen Fujitsu-Siemens Celsius H240 trotz Intel Core2Duo, 4 GB RAM und 64-bit Windows Vista lediglich 3.25 GB Hauptspeicher nutzen.

(Dieser Artikel erschien zuerst unter http://blogs.technet.com/dmelanchthon/archive/2006/11/15/4-gb-ram-mit-windows-vista.aspx)

Verwandte Beiträge:

1. Windows Server 2008 und Vista SP1 sind fertig!
   Mittlerweile pfeifen es schon viele Spatzen von den Dächern: Seit...
2. Alte Hardware unter Windows Vista betreiben
   Vista wird viel gescholten: Es gebe kaum Treiber, alte Hardware...
3. Adminpak auf Windows Vista
   Update 14.3.2007: Mit dem Windows Vista Application Compatibility Update von März...

Dazu wird im LAN ein Webserver benötigt, der eine Textdatei unter einem bestimmten Pfad zur Verfügung stellen muss. Als erstes braucht man eine Datei, die die Proxykonfiguration für den Client enthält. Der Name der Datei sollte clients.wpad lauten, jedoch ist dies nicht zwingend, denn der Name ist in der DHCP-Konfiguration festlegbar. Die Endung der Datei sollte aber bei .wpad belassen werden, da sie die Zuweisung einen MIME-Typs durch den Webserver erleichtert.

1. function FindProxyForURL(url, host)

2. {

3. if (isPlainHostName(host))

4. return "DIRECT";

5. if (!isResolvable(host))

6. return "DIRECT";

7. if (url.substring(0, 5) == "http:"||url.substring(0, 4) == "ftp:"||url.substring(0, 7) == "gopher:")

8. return "PROXY 192.168.1.1:8080; DIRECT";

9. if (url.substring(0, 5) == "wais:")

10. return "DIRECT";

11. else

12. return "DIRECT";

13. }

Der Code, der in dieser Datei verwendet wird, ist JavaScript und wird bei jedem Aufruf einer URL vom Browser ausgeführt. Die Datei muss auf dem Webserver so abgelegt werden, dass sie aus dem Netzwerk, in dem die Clients die Konfiguration erhalten sollen, lesbar ist. Dies kann durch das Aufrufen der Datei mittels eines Browsers getestet werden.

Um nun noch den richtigen MIME-Type für die Datei einzustellen, sollte in der Konfiguration des Webservers der MIME-Typ x-ns-proxy-autoconfig der Dateiendung .wpad zugewiesen werden. Beim Schreiben von clients.wpad-Files sollte man aus Perfomancegründen auf die Funktionen isInNet(), isResolvable() und dnsResolve() möglichst verzichten, da dafür jeweils ein DNS-Lookup durchgeführt wird. Insbesondere in Umgebungen, die intern keine extern DNS-Namensauflösung erlauben und die über einen Proxy surfen, wird sonst der Seitenaufbau unerträglich langsam. Weiterhin kann man die clients.wpad auch auf dem Webserver durch ein Skript erzeugen lassen und in dem Skript dann die Anwendungslogik hinterlegen, so dass die eigentliche Antwort nur noch der richtige Proxyname ist.

Damit die Clients die URL zu der clients.wpad finden, kommt nun DHCP zum Einsatz. Dazu müssen folgende Parameter eingetragen werden:

• Option: 252
• Name: wpad-url
• Option wpad-url: "http://server/clients.wpad"

Wer einen ISA-Server einsetzt, hat es noch einfacher, da dort der ISA die WPAD-Datei automatisch erstellen kann und die Anfragen danach richtig beantwortet:

• Konfigurieren der automatischen Suche von Firewall- und Webproxyclients in Windows 2000
• Konfiguration des ISA für automatische Suche der Clienteinstellungen (WPAD/WSPAD)

Der ISA-Server erstellt automatisch etwas komplexere Skripte. Mögliche Vorgaben fü ein Skript sind etwa:

1. Primärer Proxy ist s-proxy auf Port 8080
2. Wenn der nicht antwortet, nimm den Backupserver s-proxy01 auf Port 8080.
3. Umgehe für die privaten IP-Adresskreise 172.16.x.x und 192.168.x.x den Proxy.
4. Umgehe für lokale Domains (*.domain.local, webmail.firma.tld) den Proxy.
5. Umgehe den Proxy für URLs, bei denen der Servername keinen Punkt enthält (Intranet).

Weitere technische Erläuterungen zu der Konfiguration und wie man WPAD-Files auf Webservern ablegt (Stichwort MIME-Typ) sind hier zu finden:

• Automatische Erkennung von Browsereinstellungen
• Automatic proxy HTTP server configuration in web browsers
• Kill Internet Ads with HOSTS and PAC Files

Clientseitig gibt es zwei Registry-Einträge zu beachten, die im Userkontext durchgeführt werden sollten, damit der Internet Explorer bei der automatischen Proxysuche zwischen mehreren alternativen Proxies ein sauberes Failover durchführt. Die Registry-Einstellungen lassen sich auch über ein ADM-Template als Gruppenrichtlinie verteilen:

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings]
"EnableAutoproxyResultCache"=dword:00000000
"BadProxyExpiresTime"=dword:00000060

Mit diesen Einstellungen wird ein Cachen des Proxynamens verhindert, so dass im Fehlerfalle auf den zweiten umgeschaltet werden kann. Weiterhin erfolgt das Zurückschalten auf einen wieder funktionierenden Proxy innerhalb von 60 Sekunden und nicht erst nach 30 Minuten (Defaultwert). Mehr dazu hier:

• How to Disable Internet Explorer Automatic Proxy Caching
• Internet Explorer Does Not Retry Bad Proxy Server for 30 Minutes

Verwandte Beiträge:

1. Automatische Backups für SQL Server Express
   Die Express-Edition des SQL Server 2005 erfreut sich ähnlich großer...
2. Automatische Systemwiederherstellung (ASR)
   Die automatische Systemwiederherstellung (ASR = Automated System Recovery) sollte die...
3. Automatische Umleitung auf die Anmeldeseite von Outlook Web Access
   Wer es Leid ist, bei der Nutzung von Outlook Web...

Credentials Caching for Internet Protocols
http://support.microsoft.com/kb/166620/en-us

Standardmäßig ist zum Beispiel der Cache-Timeout des Mailboxcache auf 120 min, der DSAccess Cache auf 10 min gesetzt, etc. Diese Caches lassen sich natürlich ändern, allerdings geht das auch zu Lasten der Performance. Es ist aber gut zu wissen, woran dieses Verhalten liegt, damit man beim Kunden nicht um eine Erklärung verlegen ist.

Mailbox-Cache:
http://support.microsoft.com/search/default.aspx?Product=exchange&Query=Mailbox+cache

DSAccess-Cache
http://support.microsoft.com/search/default.aspx?Product=exchange&Query=DSAccess+cache

IIS Token-Cache:
http://support.microsoft.com/search/default.aspx?Product=exchange&Query=IIS+Token+cache

Credentials Cache:
http://support.microsoft.com/search/default.aspx?Product=exchange&Query=credentials+cache

Verwandte Beiträge:

1. Warum funktioniert die Änderung einer Gruppenmitgliedschaft nicht?
   Windows nutzt ein Access Token, das bei der Anmeldung generiert...
2. Exchange 2007: Dienste starten nicht nach Rollup Update 5
   Mit dem Rollup Update 5 für den Exchange Server 2007...
3. Migration verschlüsselter Mails von Lotus Notes nach Exchange
   Die Gründe für eine Migration von Lotus Notes/Domino nach Microsoft...

Schritt-für-Schritt-Anleitung:

1. Download der notwendigen Komponenten:

• Adobe Postscript-Printerdriver für Windows 9x, NT, 2000 und XP
• Adobe PPD-Files
• Ghostscript
• Redmon

2. Installation von Redmon via setup.exe

3. Anlegen eines neuen Anschlußes unter Systemsteuerung -> Drucker -> Servereigenschaften -> Anschlüsse -> Hinzufügen -> Umgeleiteter Anschluß -> Doppelklick. Es wird ein neuer Anschluß mit dem Namen RPT1: erzeugt.

4. Installation von Ghostscript.

• Default-Settings (bis auf "All User")

5. Installation des Adobe Postscriptdrivers via winstger.exe

• Auswählen von lokalem Anschluß (nicht Netzwerkdrucker) -> Port RPT1:
• Anschluß nicht jetzt konfigurieren sondern weiter auswählen
• Druckermodell auswählen -> Durchsuchen -> Adobe Distiller 3.0 (aus dem Ordner mit den heruntergeladenen PPD-Dateien)
• Drucker nicht freigeben, keine Testseite drucken und nicht konfigurieren!
• Anlegen einer Datei pdf.rsp unter c:\gs
  Inhalt (auch die Striche!):
  -Ic:\gs\gs7.04\lib;c:\gsfonts
  -sDEVICE=pdfwrite
  -r600
  -dNOPAUSE
  -dSAFER
  -sPAPERSIZE=a4

7. Anschluß RPT1: konfigurieren

• Anschluß auf das folgende Programm umleiten: c:\gs\gs7.04\bin\gswin32c.exe
• Argumente für dieses Programm: @c:\gs\pdf.rsp -sOutputFile="%1" -c save pop -f -
• Ausgabe: Prompt for Filename
• Ablauf: Hintergrund oder minimiert (dann sieht der User, wie lange es noch dauert)
• Ausführen als Benutzer aktivieren (erlaubt Netzlaufwerkzugriff)
• Schließverzögerung: 300 Sekunden (nach 5 Minuten wird ein hängender Job abgebrochen)
• Protokolldatei nach Wunsch (Debug erzeugt riesige Logs!)

8. Adobe Distiller 3.0 umbenennen in PDF

Verwandte Beiträge:

1. Drucken unter Windows 7 in der Domäne
   Unter Windows 7 haben sich mal wieder die Sicherheitseinstellungen für...
2. Das iPhone im Device Stage unter Windows 7
   Gerade sprach ich mit Kollegen über “Device Stage” in Windows...
3. sFTP-Server unter Windows bereitstellen (Teil 2)
   Wie bereits in Teil 1 angekündigt, möchte ich hier beschreiben,...

Da die Eingabedatei für ldifde sich mit Excel schlecht pflegen läßt, benute ich als Parser GNU Awk, um mit einer Excel-Datei in Kombination mit einem ldifde-Template alle möglichen Änderungen für beliebig viele User automatisiert durchführen zu können. Alles was dazu gebraucht wird, sind die GNU Utilities für Windows.

Man finded bei Sourceforge vorkompilierte exe-Dateien zur nativen Benutzung in Windows-Umgebungen: GNU utilities for Win32. Wir benötigen von der Site aus dem Archiv UnxUpdates.zip die Datei gawk.exe. Als nächstes erzeugen wir uns in einer Tabellenkalkulation ein Worksheet mit Userangaben in Spaltenform. Dabei verwende ich folgende Daten in den entsprechenden Spalten:

givenName; sn; displayName; SAMAccountName; userPrincipalName; ou; cn; company; department; physicalDeliveryOfficeName; streetAddress; postalCode; l; st; co; mail; telephoneNumber; facsimileTelephoneNumber; mobile; countryCode; c; distinguishedName; olddistinguishedName

In olddistinguishedName steht der jeweilige dn der OU, die im ADMT als Ziel-OU für die Migration vorgesehen war. In distinguishedName steht der neue dn. Diesen kann man mit der ou zusammenbauen, so dass der User gleich in die richtige Ziel-OU verschoben wird.

Für die Verknüpfungen nutze ich die Funktion "&" von Excel. In der ersten Spalte findet man ja den Vornamen, in der zweiten den Nachnamen. Die dritte Spalte enthält den displayName. Diesen baue ich mit der folgenden Excelfunktion automatisch zusammen:
=A2&" "&B2

Alle weiteren Spalten sind ebenfalls meist mit Funktionen versehen, so dass keine Informationen redundant eingegeben werden müssen. Für die Emailadressen brauchte ich zum Beispiel noch den ersten Buchstaben des Vornamens, was man so realisieren kann:
=D2&"@firma.local"

Schließlich brauchen wir noch eine Awk-Steuerdatei. Ich habe hier ein Beispiel abgedruckt, welches ich für die Abänderung von mittels ADMTv2 importierten Windows NT-Konten in die ADS verwende. Beim Import werde ja relativ wenige Daten mit übernommen. Dieses ldifde-Template kann mittels Awk die migrierten Accounts entsprechend Ändern und in die richtige Ziel-OU verschieben. Die Anzahl der verwendeten Spalten in der Eingangsdatei ist dabei in der Zeile "NF ==" mit anzugeben, in diesem Beispiel sind es 23 Spalten. "%s" steht für die jeweils verwendete Variable und "n" erzeugt einen Zeilenumbruch.

Zur Nutzung dieses Templates speichert man den Inhalt in eine Datei mit dem Namen ldifde_template.awk. Danach exportiert man seine Excel-Datei nach export.csv und benutzt das Semikolon als Trennzeichen. Die erste Spalte, die die Spaltenbezeichner enthält, muß dabei entfernt werden. Im Ergebnis bekommt man dann eine ldifde-Eingangsdatei import.ldf, die man dann mit ldifde.exe ausführen kann und die alle User gesammelt enthält: gawk -f ldifde_template.awk < export.csv > import.ldf

BEGIN {
  FS = ";"
}
END {

}
NF == 23 {
   printf("dn: %sn", $23)
   print ("changetype: modify")
   print ("replace: sn")
   printf("sn: %sn", $2)
   print ("-")
   print ("replace: givenName")
   printf("givenName: %sn", $1)
   print ("-")
   print ("replace: displayName")
   printf("displayName: %sn", $3)
   print ("-")
   print ("replace: sAMAccountName")
   printf("sAMAccountName: %sn", $4)
   print ("-")
   print ("replace: userPrincipalName")
   printf("userPrincipalName: %sn", $5)
   print ("-")
   print ("replace: company")
   printf("company: %sn", $8)
   print ("-")
   print ("replace: department")
   printf("department: %sn", $9)
   print ("-")
   print ("replace: physicalDeliveryOfficeName")
   printf("physicalDeliveryOfficeName: %sn", $10)
   print ("-")
   print ("replace: streetAddress")
   printf("streetAddress: %sn", $11)
   print ("-")
   print ("replace: postalCode")
   printf("postalCode: %sn", $12)
   print ("-")
   print ("replace: l")
   printf("l: %sn", $13)
   print ("-")
   print ("replace: st")
   printf("st: %sn", $14)
   print ("-")
   print ("replace: co")
   printf("co: %sn", $15)
   print ("-")
   print ("replace: mail")
   printf("mail: %sn", $16)
   print ("-")
   print ("replace: TelephoneNumber")
   printf("TelephoneNumber: %sn", $17)
   print ("-")
   print ("replace: facsimileTelephoneNumber")
   printf("facsimileTelephoneNumber: %sn", $18)
   print ("-")
   print ("replace: mobile")
   printf("mobile: %sn", $19)
   print ("-")
   print ("replace: countryCode")
   printf("countryCode: %sn", $20)
   print ("-")
   print ("replace: c")
   printf("c: %sn", $21)
   print ("-")
   print ("changetype: moddn")
   printf("newrdn: %sn", $7)
   print ("deleteoldrdn: 1")
   printf("newsuperior: %s,ou=ROOT,dc=firma,dc=localn", $6)
   print ("")
}

Verwandte Beiträge:

1. ldifde.exe zur AD-Bearbeitung
   Es gibt seit Windows 2000 ein mitgeliefertes Tool zur Bearbeitung...
2. Excel-Daten in echtes CSV exportieren
   Die Bearbeitung einer CSV-Datei mit Excel ist keine Freude. Excel...
3. CSV-Dateien mit Excel öffnen
   Excel wird bei der Installation als Standardprogramm für CSV-Dateien eingerichtet....

Beide Tools können auch Userdaten exportieren – User ändern kann nur ldifde.exe. Da ich zu ldifde deutlich weniger Dokumentation gefunden habe, als zu csvde (zu dem es auf dieser Webseite bereits mehrere Artikel gibt), gehe ich hier auf die Möglichkeiten von ldifde näher ein.

Ich schätze persönlich die Zeilenorientiertheit von ldifde, da man nicht Gefahr läuft, die maximale Zeilenlänge zu erreichen. Um trotzdem die Vorteile von Excel bei der Verwaltung der Userinformationen nutzen zu können (weshalb viele auf die Nutzung von csvde fokussiert sind), habe ich einen weiteren Artikel zur Nutzung von ldifde-Templates in Verbindung mit GNU Awk verfaßt.

Wenn für die Migration das ADMTv2 zu unflexibel ist, hat man damit sämtliche Usermigrationsschritte in der eigenen Hand. Das Setzen der SIDHistory kann dabei ebenfalls kommandozeilengesteuert erfolgen.

Import einer ldf-Datei:

ldifde -i -f <dateiname>

Export in eine .ldf-Datei:
ldifde -f <dateiname> -d "<rootDN>" -r "(<filter>)" -l "<list>"

-d bezeichnet den Root-Pfad zu der OU, in der sich das/die Objekt(e) befinde(n). Dabei wird quasi rückwärts gelesen: Beispiel für die OU mit dem Namen ROOT in der Domäne firma.local, wobei die OU in der obersten Hierarchiebene liegt: "ou=ROOT,dc=firma,dc=local"

-r bezeichnet den Typ des Objekts, das man exportieren will: "(objectCategory=organizationalUnit)", "(objectCategory=person)", "(objectCategory=group)", "(objectCategory=contact)"

-l bezeichnet ein oder mehrere AD-Attribut(e), die man exportieren will. Für -l kann man alle Attribute, die ein AD-Objekt haben kann, durch Kommata getrennt, angeben: "objectClass,ou,name"

-k ignoriert beim Import die Fehlermeldungen 'Constraint Violation' und 'Object Already Exists'

-y benutzt beim Import 'lazy commit' benutzt, was die Performance in großen Umgebungen verbessert

Eine UND-Verknüpfung mit AD-Attributen zum Filtern ist mit "(&(..))" möglich. Die Nutzung von Wildcards ist dabei erlaubt. Alle Benutzer deren Vorname 'Max' lautet, kann man also folgendermaßen filtern: "(&(objectCategory=person)(givenname=Max))". Alle Benutzer, deren Vorname 'Max' lautet und deren Nachname mit 'A' beginnt: "(&(objectCategory=person)(givenname=Max)(sn=A*))"

Änderbare Attribute (modify): sn, c, countryCode, displayName, logonHours, countryCode, sAMAccountName, userPrincipalName, company, department, streetAddress, postalCode, l, st, co, mail, givenName, physicalDeliveryOfficeName, facsimileTelephoneNumber, mobile

Nicht mit modify änderbare Attribute (moddn): dn, cn, name, distinguishedName
Um diese Attribute abändern zu können, muss der RDN geändert werden. Ein ldifde-Template dazu könnte folgendermaßen aussehen:

dn: CN=MaxM,OU=Migration,DC=firma,DC=local
changetype: moddn
newrdn: cn=Mustermann, Max
deleteoldrdn: 1

Man kann mittels ldifde auch Kennworte setzen. Voraussetzung dafür ist eine SSL-Verbindung mit 128 Bit Verschlüsselung mittels LDAP: How to Set a User's Password with Ldifde

dn: CN=TestUser,DC=testdomain,DC=com
changetype: modify
replace: unicodePwd
unicodePwd::IgBuAGUAdwBQAGEAcwBzAHcAbwByAGQAIgA=

{mospagebreak}

Um jetzt einzelne Attribute abzuändern, benötigt man eine ldifde-Datei mit entsprechenen Steuerbefehlen. Dabei können auch mehrere Operationen pro User und mehrere User hintereinander bearbeitet werden. Anbei ein Beispiel für die Änderung einiger Attribute für den User 'MMustermann' in der Domöäne firma.local. Hinterher wird der User unter 'Mustermann, Max' zu finden sein. Die Namensangabe in der Emailadresse wird jedoch 'Max Mustermann' lauten:

dn: CN=MMustermann,OU=Migration,DC=firma,DC=local
changetype: modify
replace: sn
sn: Mustermann
-
replace: c
c: DE
-
replace: countryCode
countryCode: 276
-
replace: displayName
displayName: Max Mustermann
-
replace: logonHours
logonHours:: ////////////////////////////
-
replace: sAMAccountName
sAMAccountName: MMustermann
-
replace: userPrincipalName
userPrincipalName: MMustermann@firma.local
-
replace: company
company: Firma GmbH
-
replace: department
department: Marketing
-
replace: streetAddress
streetAddress: Musterstrasse 1
-
replace: postalCode
postalCode: 12345
-
replace: l
l: Musterort
-
replace: st
st: Hamburg
-
replace: co
co: GERMANY
-
replace: mail
mail: MMustermann@firma.de
-
replace: givenName
givenName: Max
-
replace: physicalDeliveryOfficeName
physicalDeliveryOfficeName: Raumnummer 1029
-
replace: facsimileTelephoneNumber
facsimileTelephoneNumber: 32156
-
replace: mobile
mobile: 0172-12345
-
delete: description
-
replace: info
-
changetype: modrdn
newrdn: cn=Mustermann, Max
deleteoldrdn: 1

Gruppenzugehörigkeiten lassen sich auf diesem Weg auch ändern. Dabei ist zu beachten, dass die Änderung an der Gruppe ansetzen muss, nicht am Benutzer. Man fügt oder entfernt also Benutzer in/aus einer Gruppe:

dn: CN=Test,OU=Migration,DC=firma,DC=local
changetype: modify
replace: member
member: CN=Mustermann, Max,OU=Migration,DC=firma,DC=local
member: CN=Musterfrau, Anna,OU=Migration,DC=firma,DC=local
-

Bei der Erzeugung von Gruppen kann man den Gruppentyp nicht namentlich mitgeben. Der Typ ist in bestimmten Zahlenwerten codiert. Mit folgendem Template legt man je eine Gruppe eines jeden Typs im AD firma.local in der OU Migration an:

# Universal Security Group
dn: CN=G_Universal,OU=Migration,DC=firma,DC=local
changetype: add
cn: G_Universal
groupType: -2147483640
objectClass: group
sAMAccountName: G_Universal

# Global Security Group
dn: CN=G_Global,OU=Migration,DC=firma,DC=local
changetype: add
cn: G_Global
groupType: -2147483646
objectClass: group
sAMAccountName: G_Global

# Domain local Security Group
dn: CN=G_Local,OU=Migration,DC=firma,DC=local
changetype: add
cn: G_Local
groupType: -2147483644
objectClass: group
sAMAccountName: G_Local

# Universal Distribution Group
dn: CN=G_DL_universal,OU=Migration,DC=firma,DC=local
changetype: add
cn: G_DL_universal
groupType: 8
objectClass: group
sAMAccountName: G_DL_universal

# Global Distribution Group
dn: CN=G_DL_global,OU=Migration,DC=firma,DC=local
changetype: add
cn: G_DL_global
groupType: 2
objectClass: group
sAMAccountName: G_DL_global

# Domain local Distribution Group
dn: CN=G_DL_local,OU=Migration,DC=firma,DC=local
changetype: add
cn: G_DL_local
groupType: 4
objectClass: group
sAMAccountName: G_DL_local

Eine OU läßt sich ebenso einfach erzeugen:

dn: OU=Migration,DC=firma,DC=local
changetype: add
objectClass: organizationalUnit
ou: Migration
name: Migration

Eine Userumbennennung läßt sich auch prima mit einem Verschieben in die Ziel-OU kombinieren:

dn: CN=MMustermann,OU=Migration,DC=firma,DC=local
changetype: moddn
newrdn: Mustermann, Max
deleteoldrdn: 1
newsuperior: ou=Mitarbeiter,dc=firma,dc=local

Die Übernahme der SIDHistory kann man mittels des VB-Skriptes SIDHist.vbs aus dem Support Tools selbst vornehmen:
sidhist.vbs /srcdc:<dcname> /srcdom:<domain> /srcsam:<name> /dstdc:<dcname> /dstdom:<domain> /dstsam:<name>

• /srcdc   – source domain controller NetBIOS computer name (without leading )
• /srcdom  – source domain NetBIOS name
• /srcsam  – source principal SAM name
• /dstdc   – destination domain controller NetBIOS computer name (without leading )
• /dstdom  – destination domain DNS name
  /dstsam  – destination principal SAM name

Verwandte Beiträge:

1. Erzeugen von ldifde-Templates aus Excel mit GNU Awk
   Viele Administratoren benutzen gern csvde, da die Ausgangsdateien sich sehr...
2. NTDSUtil zeigt andere FSMO-Rolleninhaber an als LDIFDE?
   [aus einem Original von http://www.frickelsoft.net/blog/?p=236] Dies ist eine Anfrage aus...
3. Warum kann ich einen User nicht mit dem "memberOf"-Attribut einer Gruppe hinzufügen?
   Das Feld "memberOf" ist ein sog. "Backlink"-Feld, das zur Abfragezeit...

Microsoft empfiehlt den Einsatz von Point&Print-Treibern, die man für HP-Drucker z.B. auf der HP Website findet: http://www.hp.com/pond/pnp/index.html

Manchmal lassen sich aber auch diese Treiber nicht installieren. Ursächlich dafür ist der Unterschied zwischen dem Treibernamen in derListe der installierten Windows 2003-Drucker und dem Druckernamen in der INF-Datei des NT 4.0-Druckertreibers. Beispielsweise der HP LJ2200-Treiber heißt einmal "Laserjet 2200Series PCL" und einmal "Laserjet 2200 Series PCL 5e". Es handelt sichalso um ein ähnliches Problem wie bei der Installation von Clientdruckern via RDP.

Die Lösung ist diametral zu der Terminalserver-Lösung. Man passt den Druckernamen in der INF-Datei des NT-Druckertreibers entsprechend an, sodass er genauso heißt wie das installierte 2003-Treibermodell. </ />Dann kann man über Systemsteuerung -> Drucker -> "Servereigenschaften"-> "Treiber" den gewünschten Drucker mit einem rechten Mausklick auswählen und den Treiber von Diskette hinzufügen. Dort gibt man dann den Pfad zum geänderten NT 4.0-Treiber an. Danach wählt man "Windows 2000, Windows XP und Server 2003" ab und stellt sicher, dass nur "NT4.0" gewählt ist. Dadurch ist die Installation des NT-Treibers unter Windows 2003 kein Problem mehr.

Weiterhin laufen NT-Druckertreiber im Kernel-Mode. Diese Treiber werden mit einer Richtlinie an der Installation gehindert, da sie zu Bluescreens und Memory Leaks führen können. Wer NT-Workstations mit Druckertreibern zentral von Windows 2003 Servern versorgen möchte, muss in der Default Domain Policy unter Computerkonfiguration -> Administrative Vorlagen -> Drucker die Option "Installation von Druckern, die Kernelmodustreiber verwenden, nicht zulassen" (auf englisch "Disallow installation of printers using kernel-mode drivers") auf "Deaktiviert" setzen. Standardmäßig steht diese Richtlinie auf "Nicht konfiguriert", was nicht gleichbedeutend mit "Deaktiviert" ist! "Nicht konfiguriert" meint die Default-Settings, welche durchaus auf "Aktiviert" stehen können. Auf Windows 2003 Server ist die Option standardmäßig aktiviert – daher muß die Policy auf "Deaktiviert" gesetzt werden: Block the installation of kernel-mode print drivers

Verwandte Beiträge:

1. Wie aktualisiert man einen Domänencontroller auf Windows Server 2003 R2?
   Das Release Windows Server 2003 R2 basiert auf zwei CDs....
2. Wie kann man einen Domänencontroller unter Windows Server 2003 umbenennen?
   Wenn man einen Domänencontroller umbenennen muss, so kann man das...
3. NTFS-Platten mit NT4 und Windows 2003 nutzen
   Aus einer aktuellen Situation in einem Migrationsprojekt habe ich getestet,...

Dazu nutzt man einen kleinen Batch, der mittels Task Scheduler auf dem Primär-DHCP-Server (Server 1)  die DHCP-Datenbank via netsh auf ein Share des Backup-DHCP-Servers (Server 2) dumped. Danach 'leert' es den Backup-DHCP-Server und importiert mittels netsh den Dump vo Primär-Server auf den Backup-Server. Damit kann man zum Beispiel stündlich alle Konfigurationsinformationen und die aktuellen DHCP-Leases auf dem zweiten Server automatisiert kopieren.

Zusätzlich autorisiert man den DHCP-Server auf Server 2 nicht im AD. Dadurch läuft man nicht Gefahr, dass er im laufenden Betrieb anfängt, IPs zu verteilen. Im Disasterfall muß nur der Backup-DHCP (Server 2) im AD authorisiert und der primäre (Server 1) gleich deaktiviert sowie der Import-Job abgestellt werden.

Achtung: Der folgende Beispielcode funktioniert nur unter Windows Server 2003. In der netsh-Version von Windows 2000 fehlt die Option "export", die hier genutzt wird. Mit den Informationen aus http://support.microsoft.com/kb/325473/en-us sollte es aber möglich sein, ein analoges Verfahren aufzubauen.

In diesem Beispiel ist der IP-Bereich 172.16.0.0 DHCP-Scope, bei mehreren Scopes müssen alle Scopes in der dhcpimport.cmd analog gelöscht werden. Die erste Datei muß auf dem Server 2 im Ordner c:backup mit dem Namen dhcpimport.cmd hinterlegt werden:

REM dhcpimport.cmd
REM Abzulegen in c:\backup auf Server 2
@echo off
netsh dhcp server delete optionvalue 6
netsh dhcp server delete optionvalue 15
netsh dhcp server delete optionvalue 44
netsh dhcp server delete optionvalue 46
netsh dhcp server delete optionvalue 66
netsh dhcp server delete optionvalue 67
netsh dhcp server delete optionvalue 81
netsh dhcp server delete optionvalue 135
netsh dhcp server delete scope 172.16.0.0 DHCPFULLFORCE
netsh dhcp server import c:\backup\dhcpdump.txt all

Der Export wird als geplanter Task auf Server1 erstellt. Sinnvoll dafür ist die Verwendung eines eigenen Dienstkontos, damit bei Kennwortänderungen das Update nicht versehentlich sabotiert wird. Das eingesetzte Konto muss auf dem Zielserver über Administratorrechte verfügen, ist also mit einem sehr starken kennwort zu schützen. Das folgende Kommando muss dabei in einer Zeile als Job eingetragen werden:

cmd /c netsh dhcp server export \\server2\c$\backup\dhcpdump.txt all && psexec \\server2 c:\backup\dhcpimport.cmd

Das dafür notwendige Tools psexec.exe ist Bestandteil der pstools und kann als Freeware von sysinternals.com downgeloaded werden. Entpacken Sie das Tool am besten in den Windows-Ordner %WINDIR%.

 Es ist erlaubt, unter den Bedingungen der GNU Free Documentation License dieses Dokument zu kopieren, zu verteilen und/oder zu verändern.

Verwandte Beiträge:

1. Wie kann man einen Domänencontroller unter Windows Server 2003 umbenennen?
   Wenn man einen Domänencontroller umbenennen muss, so kann man das...
2. DHCP Failover in Windows Server “8”
   Eine kleine, aber feine Änderung wird der DHCP-Dienst (voraussichtlich) im...
3. Wie kann ich das AD per Backup auf einen anderen Server übertragen?
   Grundsätzlich kann das AD immer nur als ganzes gesichert und...

Per Definition nutzt ein 32-Bit-Prozessor 32 Bits, um den Hauptspeicher anzusteuern. 2ˆ32 = 4.2 Milliarden – also kann eine 32 Bit breite Speicheradresse maximal 4.2 Milliarden Speicherzellen ansteuern. Daraus resultiert also die 4 GB-Grenze. In unserer 32-Bit-Windows-Welt steht jeder Applikation ein eigener 'virtueller' 4 GB großer Speicherbereich zur Verfügung. Diese 4 GB werden in zwei Hälften zerlegt, je 2 GB für Kernel und User Memory Space. Jede Applikation bekommt ihre eigenen 2 GB User Memory Space. Der Haken: Die anderen 2 GB Kernel Memory Space sind zwischen allen Applikationen geshared.

Das verursacht die Probleme im Terminal Server-Umfeld. Auf Terminal Servern mit vielen Usern, die mehrere Applikationen nutzen (je nach Nutzungsart ab ca. 40 User aufwärts), wird dieser 2 GB große Kernel-Memory-Bereich recht zügig belegt. Praxistests haben ergeben, dass ein Windows 2000-basierender Terminal Server maximal ca. 200 User-Anmeldungen verträgt, dann ist der 2 GB Kernel Memory Space ausgereizt, auch wenn ein 'Monster-Server' mit 16 GB RAM und acht 3GHz Xeons zur Verfügung steht.

Mit Windows 2003 ist etwas mehr Finetuning in der Belegung der 2 GB Kernel Memory Space möglich. Das schafft allerdings auch keine Abhilfe, wenn sich tausende von Prozessen und hunderte von Usern diesen 2 GB Kernel Memory Space teilen.

Nun könnte man auf die Idee kommen, den /3GB- (Windows 2000) oder den /4GT-Schalter (Windows 2003) in der boot.ini zu nutzen. Das macht aber bei einem Terminal Server alles nur schlimmer – es halbiert die mögliche Anzahl der gleichzeitigen User. Denn für den User Memory Space gibt es zwar dann 3 GB, der Kernel Memory Space wird aber auf 1 GB verringert – das führt dann auf Terminal Servern doppelt so schnell an das Kapazitätslimit.

Oft wird dagegen der Einwand gebracht, dass Versionen wie Enterprise und die Datacenter Edition mehr als 4 GB physikalischen Hauptspeicher unterstützen. Aber auch wenn mehr als 4 GB RAM eingebaut sind, hat jeder Prozess das normale 2 GB-Limit und der Kernel Memory Space ist weiterhin 2 GB geshared – wie bei einem normalen non-PAE-System.

Die einzige sinnvolle Nutzung kann man mit /PAE erreichen. Dann können bis zu 64 GB RAM adressiert werden. Ein 32 Bit-Prozess benutzt dann große Speicherblöcke via AWE-Funktion (Address Windowing Extension). Das bedeutet, dass einzelne Bereiche des physikalischen Speicherbereichs in den (immer noch nur) 2 GB großen virtuellen User Memory Space gemappt wird. Insgesamt kann der Prozess aber auch hier max. 2 GB physikalischen Speicher zur Zeit nutzen.

Mehr dazu findet man in Kapitel 7 von "Inside Windows 2000" von David Solomon und Mark Russinovich:

"All of the Intel x86 family processors since the Pentium Pro include a memory-mapping mode called Physical Address Extension (PAE). With the proper chipset, the PAE mode allows access to up to 64 GB of physical memory. When the x86 executes in PAE mode, the memory management unit (MMU) divides virtual addresses into four fields.

The MMU still implements page directories and page tables, but a third level, the page directory pointer table, exists above them. PAE mode can address more memory than the standard translation mode not because of the extra level of translation but because PDEs and PTEs are 64-bits wide rather than 32-bits. The system represents physical addresses internally with 24 bits, which gives the x86 the ability to support a maximum of 2ˆ(24+12) bytes, or 64 GB, of memory.

As explained in Chapter 2 , there is a special version of the core kernel image (Ntoskrnl.exe) with support for PAE called Ntkrnlpa.exe. (The multiprocessor version is called Ntkrpamp.exe.) To select this PAE-enabled kernel, you must boot with the /PAE switch in Boot.ini.
…
Only Windows 2000 Advanced Server and Windows 2000 Datacenter Server are required to support more than 4 GB of physical memory. (See Table 2-2.) Using the AWE Win32 functions, 32bit user processes can allocate and control large amounts of physical memory on these systems."

Daher sind mehr als 4 GB RAM nur in Ausnahmefällen sinnvoll. Es handelt sich dabei um spezielle Datenbank-Versionen (z.B. MS SQL 2000 Enterprise Edition), die mehr Speicher verwenden können, da sie diese speziellen Aufrufe nutzen können. Die breite Masse der Windows-Anwendungen sind dafür nicht ausgelegt.

Zum Problem des fragmentierten Kernel Memory Spaces und die Optimierungsmöglichkeiten ist der Artikel Konfigurieren des Auslagerungsspeichers und des System-PTE-Speichers interessant.

Nun könnte man ja auch auf die Idee kommen, auf einem TS mit mehr als 4 GB RAM den PAE-Schalter zu nutzen. Leider sorgt aber der PAE-Schalter nicht für mehr Speicher für den Kernel. Er sorgt nur für mehr nutzbaren RAM im User Memory Space. Daher ist die Nutzung von PAE in Terminal Server-Umgebungen eher schlecht. Jede Applikation würde vier mal mehr Einträge im Kernel Memory Space verbrauchen, wodurch die 2 GB noch schneller voll laufen.

Dazu ein Zitat aus The 4 GB Windows Memory Limit: What does it really mean? von Brian Madden:

"How does Terminal Services uses memory? Why is it bound to the kernelmemory of 2 Gb?
In 32-bit Windows systems, the kernel can never ever use more than 2 GB of memory. Period. Even with the x86 PAE, the kernel still is limited to 2 GB. That's just the way it is, and there's no way around it.  The kernel is bound to 2 GB because the memory manager can never address more than 4 GB. Why? Because the memory manager uses 32-bit addresses for memory, and 2ˆ32 = 4GB. This will probably never change, since 64-bit OSes are around the corner, and this 2GB kernel limit is only hit in Terminal Server environments."

Erst mit x64-Systemen steht eine Möglichkeit zur Verfügung, die 4-GB-Grenze zu überwinden. Siehe dazu: Wie Windows mit großem Hauptspeicher umgeht

Verwandte Beiträge:

1. Wie kann ich die Terminal-Server-Einstellungen im AD verändern?
   Wie so oft, muss auch beim Bearbeiten der Terminal-Server-Attribute in...
2. Terminal Server 2008 einrichten
   Als Grundlage eines TS 2008 dient in diesem Beispiel ein...
3. Terminalserver-Profileinstellungen in AD: Die ungenutzte Neuerung
   Mit Windows Server 2008 hat Microsoft einige neue Attribute in...

Es gibt seit Windows NT die Möglichkeit, einem Server mehrere Netbios-Namen zuzuweisen. Die zusätzlichen Servernamen tauchen auch in der Netzwerkumgebung als Server auf. Diese Funktionalität steht lediglich auf Memberservern, nicht auf Domaincontrollern zur Verfügung. Unter Windows NT 4.0 funktionierte es nicht bei Printservern.

Dieses Verhalten ist beim Hersteller recht gering dokumentiert. Man erhält auch keinen offiziellen Support von Microsoft für dieses Vorgehen. Interessant ist allerdings, dass der File Server Migration Wizard genau diese Technik nutzt, um via DFS auf Basis eines W2k3 Enterprise oder Datacenter Servers mehrere Fileserver zu einem zu konsolidieren. Böswillige Zeitgenossen könnten jetzt mutmaßen, Microsoft würde einfach mehr Enterprise und Datacenter Server-Lizenzen verkaufen wollen - allerdings sollten diese auch bedenken, dass man dann auch Support bekommt, wenn mal was nicht so funktioniert

Key: HKEY_Local_MachineSystemCurrentControlSetServicesLanmanServerParameters
Name: "OptionalNames"
Typ: REG_MULTI_SZ

Nun kann man einem Server auch mehrere Alias-Namen vergeben. Dazu trägt man jeden Namen in eine eigene Zeile in die MULTI_SZ-Variable. Zusätzlich sollte das StrictNameChecking ausgeschaltet werden:

Key: HKEY_Local_MachineSystemCurrentControlSetServicesLanmanServerParameters
Name: "DisableStrictNameChecking"
Typ: REG_DWORD
Wert: 1

Der Server wird nach einem Reboot diese zusätzlichen Namen auch dynamisch in die WINS-Datenbank eintragen. Allerdings benutzt ein echter Server normalerweise drei Netbios-Records (00h [Arbeitsstationsnamen], 03h [Nachrichtendienst] und 20h [Serverdienst]). Die Alias-Namen werden allerdings nur als Netbios-Typ 03h eingetragen. Man muß die fehlenden Netbios-Records als statische WINS-Einträge nachpflegen. Mehr dazu hier:

Connecting to SMB Share on a W2k-Based Server May Not Work with an Alias Name
DFS update to support consolidation roots in Windows Server 2003

Ab Windows 2003 gibt es auch eine Möglichkeit, einem Server mehrere DNS-Namen zu geben. Diese werden in der Registry ebenfalls in einer REG_MULTI_SZ-Variable mit dem Namen "AlternateComputerNames" gespeichert:

Key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDnscacheParameters
Name: "AlternateComputerNames"
Typ: REG_MULTI_SZ

Zitat: "The AlternateComputerNames registry entry specifies a list of alternate Fully Qualified Domain Names (FQDNs) for the computer. When the DNS Client service registers the host address (A) and pointer (PTR) resource records for the computer, it will also register the FQDNs specified in this key. This key is used by the Netdom.exe utility and is not typically modified by administrators."

DNS Technical Reference – DNS Tools and Settings

 Es ist erlaubt, unter den Bedingungen der GNU Free Documentation License dieses Dokument zu kopieren, zu verteilen und/oder zu verändern.

Verwandte Beiträge:

1. Sind Vertrauensstellungen ohne NetBIOS-Namensauflösung möglich?
   Sehr oft kommt in den Newsgroups die Diskussion auf, ob...
2. Kann ich NT4 im Active Directory betreiben?
   Workstations oder Server unter Windows NT 4.0 können grundsätzlich problemlos...
3. Brauche ich noch WINS, wenn ich ein AD betreibe?
   Eines der am weitesten verbreiteten Missverständnisse bezüglich moderner Windows-Versionen betrifft...