Jump to content

gysinma1

Members
  • Gesamte Inhalte

    1.675
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von gysinma1

  1. Hallo Auch je nach dem ob ein Resourcekit (v.a. Windows 2000 Premium oder RK2003) ergänzen/manchmal manchmal nit optimal die shutdown.exe. Ich persönlich kopiere diejenige, die ich beherrsche in mein scripts verzeichnis und rufe diese mit unc oder festem Pfad auf. Gruss, Matthias
  2. Hallo Wir haben den Fehler gefunden. Wir setzten den SLowLink aus. Die GPO muss dafür auf enabled und auf 0 stehen ... Verursacht wurde das ganze durch die NULL Pings welche die Domainmembers auf die Domaincontroller absetzen und durch unsere Firewall mit negativen Werten beantwortet wurden. Deshalb wird das Design nochmals auseinandergenommen. Grüsse, MAtthias
  3. Salü Johannes Wir haben bei meinem gegenwärtigen Kunden 64 bit DCs im Einsatz. Allerdings ist das nicht unproblematisch. Bluescreens hatten wir bisher noch nie. Das Problem ist, dass die meisten Tools (dcdiag, netdiag) nicht für x64 gemacht sind. (Gemäss Microsoft, da ich einen PRemiumCase dazu hatte). Somit lassen sich damit auch keine einfachen Dinge fixen da netdiag /fix teilweise nicht richtig funzt. Generell sehe ich im Normalumfeld (nach 7 Jahren AD Erfahrung) keinen Bedarf x64 als DC einzusetzen, denn perfomanter ist es nicht. Einzig es kann mehr Speicher alloziert werden. Der einzige Dienst der das macht ist ja der lsass.exe. Welcher auch im /AWE Bereich also über >4GB arbeiten kann. Sinnvoll ist es bei Grösstorganisationen bei den Bridgeheads. Gruss Matthias
  4. gysinma1

    Migrationsplan Fragen

    Hallo Der Plan sieht gut aus. Das Verschieben der FSMO Rollen ist unproblematisch - es muss aber kontrolliert werden, dass es auch stattgefunden hat. Vorher würde ich jedem DC noch einen GlobalCatalog gönnen. Die Regeneration des GlobalCatalog dauert etwa 5-10 Minuten. Ich würde vor dem Beginn noch den PopCon stoppen und mit Exmerge alle Mailpostfächer noch exportieren (für den Notfall). Gruss, MAtthias
  5. @Blub Das ist eine geniale Idee.
  6. Hallo Ich würde zudem mal versuchen, die exchange dienste (exchange system attendant) mal zu disablen. Damit fährt die Mühle nicht auch noch den Exchange hoch. Dann schauen ob in den AD Logs Replication, NTDS, DNS keine Fehler drin sind. (Diese evtl. vorher leeren). Möglich, dass auch ein Checkdisk /F hilft. Hatte da aber auch schon erlebt, dass danach "nix" mehr ging. ... Schau mal noch ob das DIT File ~ 20-100 Mbyte gross ist. Sonst müsste man evtl. ein DIT Consistency check machen ... Das File liegt normalerweise im C:\winnt\ntds Verzeichnis Gruss & Viel Erfolg Matthias
  7. Hallo Vielleicht hilft dieser Thread von mir im vmware Forum weiter: 64-Bit Guest auf vmware free server ?? - VMware GSX Server und VMware Server - VMware Forum Ich habe es selbst bei mir noch nicht versucht. Ausser dass ich sicher bin, dass die MS VirtualServer kein x64 emulieren können (z.Zt.). Habe dies versucht und die Bestätigung meinte ich im C'T gelesen zu haben. Grüsse, Matthias
  8. Hallo Wir haben dazu extra ein Case bei HP eröffnet, da unsere X64 Server nicht x64 Systeme emulieren können. Uns wurde gesagt, dass dies an der VTM Emulation liegt und mit Itanium laufen sollte. Allerdings ist möglich, dass dazu ESX notwendig ist. Ich muss mal schauen, ob ich meinen OriginalThread bei HP noch finde ... dazu Gruss, MAtthias
  9. Hallo Du benötigst ab 4 GB RAM zwingend die Enterprise Edition. Zusätzlich benötigt die Boot.ini den Eintrag /PAE und sinnvollerweise /3GB Gruss, Matthias
  10. Hallo Soviel mir bekannt ist, kann lediglich mit Vmware und Itanium 64 ein 64-bit OS emuliert werden. Hatte dieses Problem letztlich auch und musste mich auf dem HP Resource center entsprechend belehren lassen. Gruss, Matthias
  11. gysinma1

    Letzter macht das Licht aus

    Was ist denn hier los ... heute morgen scheint Tote Hose sein. Sitze im Zug und grase die neuen Threads ab ... was is noch niemand wach ??
  12. Hallo Zusammen Teilweise hatten wir auch "komische" Probleme, da wir gewisse Scripts v.a. für Reparaturen mit Domain admin rechten ausführen liessen über den Logonscript. Ich weiss grad das Tool nicht mehr, womit wir diese scripts generierten (da wir natürlich keine Domain Admincredentials plain im Script haben). Gruss, MAtthias
  13. Freude herrscht. Die SlowLink detection bewirkt diesen Fehler. Die mittels GPO der Domain disblen (naütlrich nur in einem "schnellen" Netzwerk). Bei uns war dies auf "not defined" Gruss, Matthias
  14. Hallo Zusammen Vermutlich liegt die Ursache auf der Clientseite, denn nach einem Reboot tritt das Phänomen nicht mehr auf. Leider haben wir jedoch mehrere CLuster in dem Netz und aus "popularitätsgründen" können wir die momentan nicht rebooten. Die Replikationen haben wri mehrfach überprüft. An den Domain controllern kann es auch nicht liegen. Wir haben jedoch ein Premium case bei Microsoft eröffnet. Mal schauen.. Poste die findings. Gruss, Matthias
  15. Hallo Ich denk nicht, dass dies ein Zusammenhang mit den Anzahl Domaincontrollern hat. Was ich schon mal gehabt hatte, ist dass der Schema Master ein defekt hatte und deshalb nicht alle Exchange Attribute aufgenommen hat. Da liess sich aber kein SYstem Attendant starten. Hast Du schon mal auf msexchangefaq.de geschaut ? Ich weiss da leider im Moment auch nix weiteres und würde dort mal suchen. Vorstellen kann ich mir auch, dass ein Fehler bei der ORganisationskonfigurtion vorliegt. Versuch mal mit einem neuen Benutzer (kein transponiertes oder ramponiertes Exchange profil). Ich würde auch mal googlen unter Logon singlesignon oder passthrough authentication exchange ... Gruss, Matthias
  16. Hallo Rossi Das versuchen wir heute - da ich sowieso heute bei den Domain Admins bin ... Gruss, Matthias
  17. Hallo Annette Schalte mal Schattenkopien aus. Ist das möglich ? CI ( .CI ) - File Extension Information Gruss, Matthias
  18. Hallo Ich tippe auf eine verwaiste Shadow Copy Datei oder einen korrupten Papierkorb. Löschen würde ich das so auf Anhieb sicher nicht. Hättest Du vielleicht noch den Filename. Gruss, MAtthias
  19. Hallo Zusammen Wir spielen wieder mal Haschmich :D In einer Domain mit 8 Servern haben wir auf allen Servern zeitgleich die Fehlermeldung GPO Processing Aborted no Domain controller found. In der Domain sind zwei Domaincontroller. Replication geprüft in Ordnung. DNS geprüft in Ordnung (DCs und Domain members). SearchSuffix der Domainmembers und DCs alle geprüft und überall i.o. In replmon und ntfrsdiag keine Fehler innerhalb der AD. netdiag /fix nix zum fix und dcdiag /fix au nit. Domainzeit stimmt mehrheitlich auch (w32tm /resync gemacht). In gpresut werden die Policies alle als applied aufgeführt. Keine Netzunterbrüche und keine Firewallissues vorhanden (wurde mehrfach überprüft). Einziger Indiz DC wurde demoted und die FSMO Rollen verschoben. Das wüste ist, wir haben ein Filecluster und bei eingeschalteter Kerberos Authentication beginnt der ziemlich genau 1h nach diesem Fehler zu switchen. Sorry ich bin sonst vielleicht vom Fach ... aber ich steh auf dem Schlauch ... Grüsse aus dem Fasnachtsbasel Matthias
  20. Hallo Zusammen Manche haben nach der Installation von Exchange 2007 das Problem, dass das OWA Adressbuch nicht mehr geht. Der MS Fix KB919166 hilft ab. Ursache sind verschiedene Language Settings zwischen Domain controller und OWA Client. Benötigt Reboot. Gruss, MAtthias
  21. Hallo Cebo Ich gehe mal davon aus, dass der DNS Server stimmt (sonst hättest Du bei dem Logon sceclient errors). Was gibt gpresult aus ? Ist die GPO aufgelistet ? Sorry ich komme da nit ganz mit ... sind das die permissions wer die GPO erhalten soll ? Gruss, Matthias
  22. Hallo Zusammen Ich möchte da noch etwas nachlegen wegen "seize" und "transfer". Grundsätzlich ist es mal gut, dass alles wieder geht und unser berühmt-berüchtigtes Board einen Beitrag leisten konnte :D Es ist durchaus nicht einfach, wieso eine FSMO Rolle transferiert und erst im Notfall gesized werden soll. Dies hat triftige Gründe. Seize ist für den Notfall, wenn die HW/SW tod ist (Bluescreen, Brand, Diskcrash etc). Für alle FSMO Rollen bis auf den RID Master ist ein sizing/transfer kein grosser Unterschied. Für den RID Master hingegen, ist es problematisch, da er die RIDs der entsprechenden Domain verwaltet. Bei einem Transfer übernimmt der neue DC den bestehenden RID Pool vom alten. Bei einem Size berechnet indem er die vorhandenen RIDs in der Domain zusammensucht und unter Einbezug einer "Sicherheitsmarge" einen neuen RID Startwert ermittelt. Am IT Forum 2005 in Barcelona wurde von John C. (ein Mitentwickler von Active Directory) eindrücklich gezeigt, wie wenig es braucht und was passiert wenn duplicated rids auftreten (kurzum es war net schön ... v.a. unter den DCs. Auch zeigte er eine Domain mit zwei PDC Emulatoren war auch cool). Deshalb muss/müsste bei einem RID Sizing mit LDP der Startvalue des RID Pools manuell geprüft und allenfalls erhöht werden. Das ist - einverstanden - alles sehr theoretisch. Praktisch schneide ich für mich ab, never seize. Nur wenn s gar nicht anders geht. Auch wichtig zu wissen, ist, dass grad bei grossen Domains mit vielen Sites, die FSMO Funktionen nicht sofort "da" sind sondern teilweise unter den DCs auch repliziert werden müssen. Mit dem repadmin/replmon kann dies beschleunigt werden. Grüsse, Matthias
  23. Hallo Du sagst ntdsutil und seize das ist sehr sehr ungünstig, denn die Rollen sollten transferiert werden und nicht rübergerissen werden. Grade bei dem RID Master oder dem PDC Emulator kann dies ein S...Puff geben. Den alten musst Du sofern noch nicht geschehen sofort vom Netz nehmen. Der Catalog gibt es auf beiden nehme ich an oder gab bes auf beiden. Also dns management öffnen NS-Einträge des alten Servers löschen. Mit netdiag /fix prüfen und reparieren. Dann würde ich dasselbe noch mit dcdiag /fix machen. Stimmen die IP Protokolleinstellungen, so dass der Sever sich selbst als 1. DNS eingetragen hat ? Ferner der Fehler ist "nur" ein connection timeout d.h. er findet diesen DNS Server nicht mehr. (Was auch richtig ist). Gruss, Matthias
  24. JA ich auch :D Ich mein ich geh ja davon aus, dass die Clients alle sauber gejoined sind. Grad wenn ein DC "neu" ist. Sonst hast Du schon mal ein client rejoined ? Die User logen auf die Domain ein ? Wenn Du im Exchange Systemadministrator nachschaust hast Du überall die Maillboxen und im DSA auch die Exchange Features angezeigt (gut ist beides auf demselben Server). Gibt es irgendwelche Error Logs v.a. Exchange Topology Check, oder mögliche DNS Fehler ? Was würde ein netdiag /fix oder dcdiag /fix bewirken ? Der Logon auf den Exchange Server mit MAPI wird normalerweise nur verlangt, wenn der SingleSideLogon nicht geht, oder (bei einem Trust), die Vertrauensstellung zwischen Exchangeserver und "Outlook PC" nicht vorhanden ist. Fällt mir noch was ein: Hast Du zufällig ein Outlook Profil im Einsatz sonst würde ich testweise mal das entfernen und neu anlegen, manchmal sind die auch korrupt. Grüsse, Matthias
  25. Hallo Ich würde es auch so machen. Allerdings würde ich den Workaround noch versuchen. Du sparst doch einiges an Zeit. Gruss, Matthias
×
×
  • Neu erstellen...