martins

Hier: http://www.mcseboard.de/microsoft-lizenzen-50/hyper-v-kein-ende-155909.html Ich denke du hast recht. Vielleicht hat Dr. Melzer ja einen Link zur Hand, wo das für Deutschland eindeutig geregelt ist. Einen deutschsprachigen Lizenzvertrag habe ich leider nicht gefunden. Gruß Martin

Das bedeutet also, dass ich sowohl auf einen Windows Server 2008 Standard, Enterprise und Datacenter z.B. 50 virtuelle Maschinen (max. 196?) (auch Windows Server) gleichzeitig laufen lassen kann, wenn ich die passende Anzahl an zusätzlichen Lizenzen erworben habe, nur mit dem Unterschied, dass bei einem Standard-Server bereits eine W2K8 Std.-Lizenz für Virtualisierung enthalten ist, bei einem Enterprise-Server vier Lizenzen und beim Datacenter 196 Lizenzen? Ist das so korrekt? Nicht beachtet habe ich jetzt die Sondermöglichkeiten, dass z.B. bei einem Enterprise-Server 1x Standard genutzt werden kann + 3x Enterprise. Dies bitte ignorieren. Danke Martin

Danke Norbert. Das Problem welches mittlerweile aufgetreten ist, ist dass die Clients sich die Richtlinie nicht abholen. In den Netzwerkeinstellungen der Clients ist noch ein „alter“ DC als 1.DNS angegeben, der am Wochenende durch einen Windows Server 2008 R2 ersetzt wurde. Der neue 2008er DC hat eine andere IP als der vorherige 2003er DC. Der alte DC wurde heruntergestuft und ist nur noch Memberserver. Leider werden die DNS-Anfragen nicht an den neuen 2008er DC weitergeleitet. Ich denke dass dies der Grund dafür ist, dass sich die Clients die Gruppenrichtlinie nicht ziehen können. Was kann ich denn machen, dass die Clients automatisch auf dem 2008er nach dem DNS gucken? Auf dem alten 2003er DC ist dies in den Weiterleitungen konfiguriert: „Alle anderen DNS-Domänen“ im Bereich: (…) „Abfragen von Namen in folgenden DNS-Domänen weiterleiten.“ Wenn ich aus dem DNS des alten 2003er DC mich mit dem DNS-Server auf dem 2008er verbinden möchte: DNS => Mit DNS-Server verbinden, erscheint die Meldung: „Server ist nicht verfügbar. Soll er trotzdem hinzugefügt werden?“ Wenn ich dies bestätige, kann ich aber trotzdem nicht den DNS-Server auf den anderen Server (2008er) verwalten. :confused:

Kann ich denn auf einem physikalischen Server (1 oder 2 CPU-Sockets), der mit Windows Server 2008 R2 Standard installiert wurde, 1x die Hyper-V Rolle installieren und dann z.B. 15 gleichzeitige Instanzen (virtuelle Server) mit jeweils Windows Server 2008 R2 installieren und starten, wenn ich insgesamt 16 Windows Server 2008 R2 Std.-Lizenzen erworben habe? :confused:

Danke für den informativen Link! Ich werde morgen testen, ob Nr. 36 hier zutrifft. Wozu werden überhaupt diese ...\{C56486AF-1CA5-4A1B-A3CA-914D55A9BBBA}\... Ordner generiert?

Danke für den Tipp, Lukas. Gesagt, getan => Gruppenrichtlinie für die betreffenden PCs in der entsprechenden Organisationseinheit erstellt und mit der Batch-Datei gefüttert. Geändert wurde allerdings nichts. Das Ereignisprotokoll eines Clients spuckte dann das hier aus: Ereignistyp: Fehler Ereignisquelle: UserInit Ereigniskategorie: Keine Ereigniskennung: 1000 Datum: 13.09.2009 Zeit: 17:17:33 Benutzer: Nicht zutreffend Computer: TEST01 Beschreibung: "Folgendes Skript konnte nicht ausgeführt werden: \\domaene.lokal\SysVol\domaene.lokal\Policies\{C56486AF-1CA5-4A1B-A3CA-914D55A9BBBA}\Machine\Scripts\Startup\DNS_WINS.bat. Das System kann die angegebene Datei nicht finden. Ich hab es dann auf einem der DCs in diesen Pfad verschoben: C:\Windows\SYSVOL\sysvol\domaene.lokal\scripts - seither gehts. Danke! ;)

Ich würde gerne in unserer Domäne bei einigen Clients den DNS-Server ändern, da sich dieser geändert hat und wir kein DHCP einsetzen. Ich habe für die entsprechenden Clients, bzw. User ein Anmeldeskript erstellt, was so aussieht: netsh interface ip set dns LAN-Verbindung static 192.168.1.1 netsh interface ip add dns LAN-Verbindung 192.168.1.2 index=2 Bei der Anmeldung eines Users wird das Script auch gezogen, leider erscheint aber die Fehlermeldung "Zugriff verweigert". Führe ich das Script als Administrator aus, werden die DNS-Server entsprechend geändert. Den "Testuser" habe ich der Gruppe "Netzwerkkonfigurations-Operatoren" hinzugefügt, was leider aber nicht geholfen hat. Wo ist mein Fehler? Gruß und Danke Martin P.S. Die Clients sind alle Windows XP Prof. (SP2), die Domäne ist Windows Server 2008 R2

Den DC habe ich jetzt heruntergestuft, jedoch habe ich ab und zu das Problem, dass ich mich über RDP nicht immer (fifty-fifty) am neuen DC (2008 R2) anmelden kann. Das Ereignisprotokoll protokolliert in diesem Zusammenhang nichts gehaltvolles. Ich werde es beobachen. Warten wir mal die Nacht ab, wie das Ereigniprotokoll morgen aussieht. ;) Gruß und Danke Martin

AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System .Security.AccessControl.CryptoKeyAccessRule} CertificateDomains : {srv07.domaene.LOKAL} HasPrivateKey : True IsSelfSigned : True Issuer : CN=srv07.domaene.LOKAL NotAfter : 18.03.2008 13:48:19 NotBefore : 11.03.2008 13:48:19 PublicKeySize : 1024 RootCAType : Unknown SerialNumber : AEEAC8561B57B6BF44FB4D9CA0CDF9AD Services : None Status : DateInvalid Subject : CN=srv07.domaene.LOKAL Thumbprint : 1E7E7E873E431F0A559909405241E72C38BF5787 AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System .Security.AccessControl.CryptoKeyAccessRule} CertificateDomains : {srv07} HasPrivateKey : True IsSelfSigned : True Issuer : CN=srv07 NotAfter : 18.03.2008 13:46:35 NotBefore : 11.03.2008 13:46:35 PublicKeySize : 1024 RootCAType : Unknown SerialNumber : 9F033163EF5CE5BA491D54832918DF33 Services : None Status : DateInvalid Subject : CN=srv07 Thumbprint : 63D00AFC4A63CB1D00178D01C7420786D2B3BC3D AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System .Security.AccessControl.CryptoKeyAccessRule} CertificateDomains : {} HasPrivateKey : True IsSelfSigned : True Issuer : CN=82.141.xx.xxx NotAfter : 16.11.2021 15:37:40 NotBefore : 09.03.2008 15:37:40 PublicKeySize : 1024 RootCAType : None SerialNumber : 01BE6E34297FEABB4AFC4765C2A9E805 Services : None Status : Valid Subject : CN=82.141.xx.xxx Thumbprint : 05EAEC4E64D4A14FD19E34F5276E11B8EC2FD327 AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System .Security.AccessControl.CryptoKeyAccessRule, System.Securi ty.AccessControl.CryptoKeyAccessRule} CertificateDomains : {srv07, srv07.domaene.lokal} HasPrivateKey : True IsSelfSigned : True Issuer : CN=srv07 NotAfter : 12.01.2009 23:37:28 NotBefore : 12.01.2008 23:37:28 PublicKeySize : 2048 RootCAType : Unknown SerialNumber : D3E90918994DA88449B54713A63D4041 Services : SMTP Status : Invalid Subject : CN=srv07 Thumbprint : 8C10B042B1911FE0EBC794DB118538D4805C6734 Ich habe es jetzt mal nicht als Code eingefügt. Ich finde, das ist übersichtlicher.

das überprüfe ich doch auch mit "get-exchangecertificate |fl"!? Das Ergebnis auf dem Hub: [PS] C:\Dokumente und Einstellungen\Administrator.domaene>get-exchangecertificate |fl AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System .Security.AccessControl.CryptoKeyAccessRule, System.Securi ty.AccessControl.CryptoKeyAccessRule} CertificateDomains : {mail.firmenname.de, http://www.mail.firmenname.de,'>http://www.mail.firmenname.de, s rv07-ks, srv07.domaene.lokal, exgw-01.firmenname.de , autodiscover.firmenname.de} HasPrivateKey : True IsSelfSigned : False Issuer : SERIALNUMBER=01961287, CN=Go Daddy Secure Certification Au thority, OU=http://certificates.godaddy.com/repository, O= "GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US NotAfter : 04.06.2010 18:52:04 NotBefore : 28.05.2009 12:51:50 PublicKeySize : 1024 RootCAType : ThirdParty SerialNumber : 00ABFC58A87154 Services : IMAP, POP, IIS, SMTP Status : Valid Subject : CN=mail.firmenname.de, OU=Domain Control Validated, O=mail.firmenname.de Thumbprint : EDCEBF3947799A25B047D0F021BA35ABA788F097 AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System .Security.AccessControl.CryptoKeyAccessRule, System.Securi ty.AccessControl.CryptoKeyAccessRule} CertificateDomains : {mail.firmenname.de, http://www.mail.firmenname.de, s rv07-ks, srv07.domaene.lokal, exgw-01.firmenname.de , autodiscover.firmenname.de} HasPrivateKey : True IsSelfSigned : False Issuer : SERIALNUMBER=01961287, CN=Go Daddy Secure Certification Au thority, OU=http://certificates.godaddy.com/repository, O= "GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US NotAfter : 04.06.2009 18:52:04 NotBefore : 04.06.2008 18:52:04 PublicKeySize : 2048 RootCAType : ThirdParty SerialNumber : 4531BA Services : IMAP, POP, SMTP Status : DateInvalid Subject : CN=mail.firmenname.de, OU=Domain Control Validated, O=mail.firmenname.de Thumbprint : 64F9019BC162F1C3DD1A96E23EE2000A53ACB4E6 AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System .Security.AccessControl.CryptoKeyAccessRule} CertificateDomains : {mail.firmenname.de} HasPrivateKey : True IsSelfSigned : True Issuer : CN=mail.firmenname.de, O=Firma AG, L=Frank furt, S=Hessen, C=DE NotAfter : 01.06.2009 01:18:01 NotBefore : 31.05.2008 19:18:01 PublicKeySize : 2048 RootCAType : Unknown SerialNumber : 6253187B920210AB486E12DD017F55EB Services : None Status : Invalid Subject : CN=mail.firmenname.de, O=Firma AG, L=Frank furt, S=Hessen, C=DE Thumbprint : 725BC86FD0CA8825C50404B3A45A34894F6499C1 AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System .Security.AccessControl.CryptoKeyAccessRule} CertificateDomains : {srv07.domaene.lokal} HasPrivateKey : True IsSelfSigned : True Issuer : CN=srv07.domaene.lokal NotAfter : 19.08.2035 17:15:33 NotBefore : 02.04.2008 17:15:33 PublicKeySize : 1024 RootCAType : Unknown SerialNumber : F12D9436FF8646AB47F1895C952F35F6 Services : None Status : Valid Subject : CN=srv07.domaene.lokal Thumbprint : A6F4968857B525D1B67BC146397ABACE8ACE51D8 => und

Also die beiden Sendeconnectoren am EDGE heißen: "edgesync - inbound to frankfurt" "edgesync - frankfurt to internet"

Hallo Brainstorm, "get-exchangecertificate |fl" auf dem Edge ergibt folgendes: AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System .Security.AccessControl.CryptoKeyAccessRule, System.Securi ty.AccessControl.CryptoKeyAccessRule, System.Security.Acce ssControl.CryptoKeyAccessRule} CertificateDomains : {exgw-01, exgw-01.firmenname.de} HasPrivateKey : True IsSelfSigned : True Issuer : CN=exgw-01 NotAfter : 11.09.2010 20:23:35 NotBefore : 11.09.2009 20:23:35 PublicKeySize : 2048 RootCAType : None SerialNumber : 121C6155C071B39B434B344A9C5F3665 Services : SMTP Status : Valid Subject : CN=exgw-01 Thumbprint : 10454D4A46BC0B3EA28627346A9F0CBCF648C6C5 [b]und[/b] AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System .Security.AccessControl.CryptoKeyAccessRule, System.Securi ty.AccessControl.CryptoKeyAccessRule, System.Security.Acce ssControl.CryptoKeyAccessRule} CertificateDomains : {exgw-01, exgw-01.firmenname.de} HasPrivateKey : True IsSelfSigned : True Issuer : CN=exgw-01 NotAfter : 13.06.2009 17:58:59 NotBefore : 13.06.2008 17:58:59 PublicKeySize : 2048 RootCAType : Unknown SerialNumber : F720AD650C43A09E41D9274BC83670A2 Services : SMTP Status : Invalid Subject : CN=exgw-01 Thumbprint : DBD42BEF851C1922C585766215BC5E38B96DA497 Da die dort angegebenen Namen identisch sind und vorher alles funktionierte, denke ich nicht, dass es an einem falschen FQDN liegt. :confused: Gruß Martin

Ereignistyp: Fehler Ereignisquelle: MSExchangeTransport Ereigniskategorie: Routing Ereigniskennung: 5016 Datum: 11.09.2009 Zeit: 21:22:39 Benutzer: Nicht zutreffend Computer: SRV07 Beschreibung: Der Active Directory-Topologiedienst konnte keine Route zu dem Connector "CN=Firma,CN=Connections,CN=erste routinggruppe,CN=Routing Groups,CN=erste administrative gruppe,CN=Administrative Groups,CN=Domaene,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domaene,DC=lokal" in Routingtabellen mit dem Zeitstempel 11.09.2009 19:22:39 erkennen. Dieser Connector wird nicht verwendet. Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://www.mcseboard.de ;) Was sagen die Exchange-Spezies dazu? Danke für eure Hilfe! Martin

Hallo liebes Board, Ich habe ein Exchange-Problem, bei dessen Lösung ich aber derzeit etwas auf dem Schlauch stehe. Es existieren zwei Exchange-Server 2007 (aktueller SP- und Patchstand): 1x EDGE-Server 1x Postfach-/Client-/Hub-Server auf dem EDGE-Server wird seit einigen Tagen folgendes protokolliert: Protokollname: Application Quelle: MSExchangeTransport Datum: 11.09.2009 20:17:50 Ereignis-ID: 12014 Aufgabenkategorie:TransportService Ebene: Fehler Schlüsselwörter:Klassisch Benutzer: Nicht zutreffend Computer: exgw-01.firmenname.de Microsoft Exchange konnte ein Zertifikat nicht finden, das den Domänennamen "exgw-01.firmenname.de" im persönlichen Informationsspeicher auf dem lokalen Computer enthält. Daher kann die STARTTLS-SMTP-Aktionsart für den Connector "edgesync - Frankfurt to internet" mit einem FQDN-Parameter von "exgw-01.firmenname.de" nicht unterstützt werden. Überprüfen Sie die Connectorkonfiguration sowie die installierten Zertifikate, damit sichergestellt wird, dass ein Zertifikat mit einem Domänennamen für jeden Connector-FQDN vorhanden ist. Wenn das Zertifikat vorhanden ist, führen Sie "Enable-ExchangeCertificate -Services SMTP" aus, damit sichergestellt ist, dass der Microsoft Exchange-Transportdienst auf den Zertifikatschlüssel zugreifen kann. auf dem Postfach-/Client-/Hub-Server dieses: Ereignistyp: Fehler Ereignisquelle: MSExchangeTransport Ereigniskategorie: TransportService Ereigniskennung: 12019 Datum: 11.09.2009 Zeit: 15:58:39 Benutzer: Nicht zutreffend Computer: SRV07 Beschreibung: Das interne Remotetransportzertifikat ist abgelaufen. Zertifikatbetreff: CN=exgw-01. Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp. Folgendes habe ich bisher gemacht: Auf dem EDGE => Verwaltungsshell: "New-ExchangeCertificate" (Um ein neues Zertifikat zu erstellen) Auf dem Edge => Verwaltungsshell: "New-EdgeSubscription - Filename “c:\EdgeSubscriptionInfo.xml”" Anschließend "EdgeSubscriptionInfo.xml" auf den HUB-Server kopiert und am HUB über die Verwaltungskonsole importiert: "Organisationskonfiguration / Hub-Transport / Edge-Abonnements" Neustart beider Exchange-Server, allerdings folgende Fehlermeldungen im Ereignisprotokoll: Am Edge-Server: Protokollname: Application Quelle: MSExchange Message Security Datum: 11.09.2009 21:12:00 Ereignis-ID: 1005 Aufgabenkategorie:EdgeCredentialService Ebene: Fehler Schlüsselwörter:Klassisch Benutzer: Nicht zutreffend Computer: exgw-01.firmenname.de Beschreibung: Die EdgeSync-Anmeldeinformationen "cn=ESRA.exgw-01.srv07.0,CN=Services,CN=Configuration,CN={D81AF96B-D19A-449B-A93E-CB35175A28A6}" konnten nicht mithilfe des Zertifikats mit dem Fingerabdruck "10454D4A46BC0B3EC21627346D9F0CECF648C6C5" entschlüsselt werden. Die Ausnahme lautet "Ungültige Daten ". Um dieses Problem zu beheben, heben Sie das Abonnement auf, und abonnieren Sie den Edge-Server dann erneut. und Protokollname: Application Quelle: SideBySide Datum: 11.09.2009 21:31:38 Ereignis-ID: 33 Aufgabenkategorie:Keine Ebene: Fehler Schlüsselwörter:Klassisch Benutzer: Nicht zutreffend Computer: exgw-01.firmenname.de Beschreibung: Fehler beim Generieren des Aktivierungskontextes für "C:\Windows\WinSxS\amd64_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.762_none_c46a533c8a667ee7\MFC80U.DLL". Die abhängige Assemblierung "Microsoft.VC80.MFCLOC,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50608.0"" konnte nicht gefunden werden. Verwenden Sie für eine detaillierte Diagnose das Programm "sxstrace.exe". am HUB ... Fortsetzung siehe unten =>

So ist es auch konfiguriert. Der neue 2008er DC als 1. DNS und als 2. DNS die IP von sich selbst (SRV01). Hast du noch eine andere Erklärung für das Verhalten? BTW: Danke für Link - kannte ich aber schon. Der Blog ist ja schließlich eine der Anlaufstellen beim Thema Active Directory. ;) Ich habe ja sogar drei DCs. Zwei DCs (ein 2003er und der neue 2008er Server) am Standort A und einen DC an Standort B. Der DC der heruntergestuft wird, nicht mitgezählt.

24 Stunden sollten doch eigentlich ausreichen!? BTW: Beim Neustart des "alten 2003er DCs (SRV01)" erscheint folgende Fehlermeldung wenn ich mich an dem System wieder anmelden möchte (per RDP): "Das System kann Sie aufgrund des folgenden Fehler nicht anmelden: Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden. Wiederholen Sie den Vorgang, oder setzen Sie sich mit Ihrem Systemadministrator in Verbindung." Nach 5 Minuten Wartezeit klappt die Anmeldung :shock: :suspect::rolleyes: Hat das mit der 2008er Aktualisierung der Domäne zu tun oder was könnte hierfür ursächlich sein? Vielleicht sollte ich den 2003er DC jetzt einfach herunterstufen!?

Über den 2008er DC hat es funktioniert.

Wenn's was bringt. Warten wir halt! ;) ... wie lange hast du damals gewartet? :D

Ja, auch dann. Edit: Was spricht dagegen, das am 2008er DC zu machen?

Nächste Woche schicke ich dir ein Care-Paket! :) ... leider ist noch ein kleines (?) Problem aufgetreten. :D Beim editieren / ändern wollen des fSMORoleOwner (auf den neuen 2008er DC) wird mir folgende Fehlermeldung beim "Klick" auf Übernehmen/OK angezeigt: "Das Funktionsbesitzerattribut konnte nicht gelesen werden" Geändert wird das dann leider nicht, Google konnte mir bisher auch nicht weiterhelfen. :-/

Danke für deinen Support! :thumb1: Wohin kann ich die Kiste schicken? :D

Kann es sein, dass das in meinem Fall gar nicht angepasst werden muss? CN=Infrastructure (fSMORoleOwner) sieht bei mir so aus, dass der DC der heruntergestuft werden soll, gar nicht in den Eigenschaften angegeben ist. Der Eintrag sieht bei mir so aus: Settings,CN=SRV02,CN=Servers,CN=ORT,CN=Sites,CN=Configuration,DC=Domain,DC=lokal und SRV02 ist ein DC, auf dem nur DNS und GC läuft. Dies betrifft übrigens "ForestDNSZones und "DomainDNSZones".

Irgendwie erschließt sich mir das nicht. Muss ich denn außer dem Übertragen der Rollen noch etwas machen, um den "alten DC" herunterstufen zu können? Mein Ereignisprotokoll sieht soweit ganz gut aus. Grüße Martin

Danke Yusuf, der hier fehlte mir: "regsvr32 schmmgmt.dll"

... kann mir bitte jemand sagen, wie ich den Schema-Master auf den neuen W2K8 R2 DC bekomme?