gysinma1

Hallo Eigentlich dürfte dies keine Probleme machen. Ich kenne jedoch verschiedene Szenarien, wo .NET2.0 Probleme macht: A-Ein IIS Server wird nach der Installation zu einem Domain controller B-Der IIS wird nach der Installation entfernt und wieder installiert C-Der IIS wird auf einem 64 Bit Server betrieben A Das Passwort vom IUSR_Servername und IWAM_Servername ist nicht mehr synchron. Lösung IIS deinstallieren und neu installieren B Nach der IIS installation im Framework\v2xx Verzeichnis regasp_iis -I ausführen. Damit wird .NET2.0 reinitialisiert C Bei 64 Bit muss zusätzlich konfiguriert werden, ob der .NET2.0 den 64bit Pool verwenden darf oder nicht. Weiss ich nicht grad auswendig ... such mal unter enable 64bit Pool .NET2.0 im google Last not least was immer Probleme gibt ist .NET11 auf einem Exchange 2007 Server (welcher für das OWA .NET2.0 benötigt). Ergo ein WSUS 2.0 und ein Exchange 2007 schliessen sich praktisch aus. Gruss, Matthias

Das ist mir auch klar .. oder ein Adressbuch ... :cool: Trotzdem bleibe ich dabei, Fehlersuche mit Silentshell ist nicht gut .. hatte meine ERFA gemacht. Gruss, Matthias

Hallo Ich wäre mit dem nachstehen shell vorsitichtig, denn die Mailboxen existieren, so ich den Post verstanden habe, noch auf dem anderen Store und werden dort benötigt. # vorhandene Mailboxen löschen Get-Mailbox | Remove-Mailbox get-mailbox | Disable-Mailbox Ich wäre mit dem Attribut in der Shell "-ErrorAction:SilentlyContinue" sehr vorsichtig, denn damit werden Fehler übersprungen und weitergemacht. Das ist in dieser Situation nicht sinnvoll. Da man ja wissen will WARUM die Deinstallation nicht klappt. Gruss, Matthias

Hallo Also ich würde so vorgehen: 1. Alle Exchange Dienste stoppen (inkl POP Connector) 2. Den Ordner wo die priv.edb und pub.edb drin sind (alle mit den Logdateien !) kopieren. 3. Alle Dienste wieder starten (damit hast Du eine offline Kopie) 4. Die Datenbank dismounten und als not protected mounten (wirst Du bei dem Vorgang gefragt, respektive ist unter properties database evtl. zu finden) - musst halt rasch schauen. Ist alles im Karteireiter "server". 5. ntbackup restore Gruss, Matthias

Hallo JA der will auf Nummer sicher sein. Ich würde Schritt für Schritt vorgehen ... Alle Mailboxen sind ja schon auf dem anderen Store nehme ich an... Also Change/Remove Mailbox Rule und ClientAccess Rule. Dann hast Du noch den Transporter. Dafür musst Du sämtliche Connectoren weg haben (receipt und outgoing). Dann diesen auch weg. Ich würde alle Aktionen aus dem MGMT Studio es Exchange 2007 machen. Gruss, Matthias

Hallo Exchange Admin Tools, Server, Databases, Dismount. Ich würde jedoch anders vorgehen. Informationstore stoppen. Verzeichnis renamen, Ganzes Verzeichnis restoren (flat file) und Store wieder starten. Da kannst Du nicht viel falsch machen. Von welchem Exchange redest Du. Ich nehme an 2003 ? Gruss, Matthias

Hallo Habt Ihr möglicherweise Roaming Profiles im Einsatz ? Grüsse, Matthias

Hallo Zusammen Wichtig ist auch zi wissen, dass dcdiag und netdiag auf (möglichen) 64bit Betriebssystemenn Fehler anzeigen, da diese nicht dafür entwickelt wurden (Kerberos z.Bsp.). In diesem Falle ist die verlässliche Quelle das eventlog. Gruss, Matthias

Hallo Lian Der Betrieb ist nicht gestört. Der Fehler ist reproduzierbar wenn auf dem SP2 Server der UNC Pfad zur virtuellen CLuster Resource eingegeben wird: \\clusres\share (zum Beispiel). Dann klepperts und der Event steht auf dem SP2 Server im Log. Gemäss MS auch keinerlei Einschränkungen per dato bekannt. Ms wird ein Bugfix evtl. machen, falls der Fehler gehäuft bei Kunden auftritt. Momentan seien halt noch viele Cluster ohne SP2 in Betrieb. Der Fall wurde in die Entwicklung weitergegeben. Gruss, Matthias

Hallo Mir fallen auf Anhieb eigentlich nur zwei Lösungen ein: - Absichern des FTP durch S-FTP - Firewall dazwischen (Cisco PIX zum Beispiel) Der Administrator account umbenennen ist security basic und gehört eigentlich bei jedem Device gemacht. Gruss, MAtthias

Hallo Zusammen Unser Betrieb is MS Premium Partner, weshalb wir die Kollegen von MS beizogen: - Der Event ist ein Bug von Windows 2003 SP2 bei dem Zugriff auf geclusterte Resourcen - Es gibt kein Hotfix und kein Workaround (ist per dato nicht geplant) Die Empfehlung ist die Fehlermeldung zu ignorieren und in Überwachungssuites zu unterdrücken. Der Fehler ist reproduzierbar bei dem UNC Zugriff auf die fehlermeldende Resource. Gruss, MAtthias

Hallo Lian Der Fehler wird auf dem DWEPA11 generiert bei dem Zugriff auf die Resource vdwepdfs (File Resource). Es greifen zwei Applicationserver darauf zu (dwepa11 und dwepa21). Jedoch nur der dwepa11 hat diesen Fehler.- Event Type: Error Event Source: Kerberos Event Category: None Event ID: 4 Date: 09.05.2007 Time: 19:20:31 User: N/A Computer: DWEPA11 Description: The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/dwepd21.egldwnet.ch. The target name used was cifs/vdwepdfs.fqdn. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (domain.fqdn), and the client realm. Please contact your system administrator. For more information, see Help and Support Center at Events And Errors Message Center: Basic Search. Ich schalte jedenfalls das KerberosLog ein. Leider seit "immer" d.h. seit der Installation. Gruss, MAtthias

Hallo Zusammen Ich hätt da wieder ein "Lian-Clusterticket" :D Wir haben ein Loadbalancer zwei Node Cluster 2005 SP1 mit SQL2005SP2 und Fileresouren. Die beiden Applicationserver welche drauf zugreifen, haben jeder 1x täglich den Fehler Kerberos 4 KRB_APP_ERR_MODIFIED. In eventid.net find ich nix schlaues und in der Boardsuche habe ich auch schon geschaut .. Rausnehmen und Reinnehmen in die Domain können wir auf keinen Fall. Da das ganze Enviornment hochkritisch ist und wir auf keinen Fall Clusterswitches wollen, stellt sich die Frage, ob dies quasi "normal" ist. Soweit mir die Fehlermeldung sagt, dass das Ticket der Resource nicht korrekt entschlüsselt werden kann. Duplicated entries sind keine drin in der AD wurde bereits mehrfach geprüft. Mich sorgt nicht der einzelne Fehler sondern die Periodizität. Grüsse Matthias

Auja da wär ich auch interessiert ! Gruss Matthias

Hallo D.h. direkter Zugriff ohne ISA Server dazwischen ? Gruss, Matthias

Hallo Der Server mit der ClientAccess Rolle (OWA) muss nicht die Leistung der Server mit der Mailbox Rolle haben. Der Store = DB läuft nur auf der Mailbox Rolle. Ich würd (zwei ?) Pizza Server wie z.Bsp. DL360 von HP einsetzen mit 2 x 145 GB 15 K, 2 resp. 4 Gb RAM (der Webservice braucht auch ziemlich Memory - Ausgebaut hat man noch schnellle) Für den "Hintergrund" jedoch evtl. zwei DL385 G4 Doppel CPU Dualcore mit je 4 GB RAM (jedoch so, dass sie einfach auf 8 GB aufgerüstet werden können. Merkst es ja schnelle). Für die Disks würde ich so machen (evtl.benötigtst ein Disk Enclosure für jeden). Mit der nachstehenden Diskeinteilung machte ich gute ERFA bei den Stores: 2 x 72 GB Raid1 für OS, Pagefile, Exchange binaries --> Lun 0 1 x 72 GB Hotspare für LUN0 3 x 145 GB 15K Raid5 für Store 1 DB --> Lun 1 2 x 145 GB 15 K Raid1 für Log 1 DB --> Lun 1 1x 145 GB Hotspare für LUN 1 3 x 145 GB 15 K Raid1 für Store 2 --> Lun 2 2 x 145 GB 15 K Raid1 für Log 1 DB --> Lun 2 1 x 145 GB Hotspare für LUN 2 Okey bei dem gegenwärtigen Kunden haben wir eine HP XP SAN da sind solche Sachen einfacher ... S kommt halt auch immer ein bissel drauf an wieviel Geld man investieren will. Gruss, Matthias

Hallo LukasB Compare the Editions of Windows Server 2003 Stimmt da haben sich die Zeiten geändert :D Gruss, Matthias

Hallo Substyle Das ist so ein Thema wo es soviele Meinungen wie Philosophen gibt. Grundsätzlich musst Du Dir bei Exchange 2007 die Topologie überlegen oder schauen was schon da ist. Auch Thema Verfügbarkeit ist wichtig, wie lange darf der Server nit laufe .... wenn am SA/SO niemand arbeitet ists einfacher. Willst Du einen Frontend/Backend Betrieb (abgetrennter OWA in DMZ zum Beispiel) oder integrierte all in one Lösung ... wäre eine sichere Lösung benötigt allerdings at least zwei Server. Bei allem Respekt ich kann mir nicht vorstellen, dass mit 170 Postfächern "nur" quasi 300-400MB anfallen (es sei denn pro Tag) Da Exchange 2007 eine Art "Logshipping" mit primary und secondary Store unterstützt würde ich für diese Anforderung eine 2 resp. 3 Server Lösung ins Auge fassen: 1x OWA in einer DMZ mit MailAccess und MailTransportRole in der DMZ 2x Mailstore Server mit MailAccess mit je 80 Leuten auf einem Store. Hat den Vorteil, mit Primary und Secondary DB, dass Du fliegend switchen kannst u.u. grad für Wartungsarbeiten nützlich. Beide Datenbanken auf beide Anlegen und replizieren --> ergibt einen quasi vollwertigen Logshipping Cluster ähnlich wie SQL. Und der Faktum Budget ist natürlich auch ... Wenn Du alles auf einen Server machen (musst) würde ich eine DoppelCPU Dualcore Maschine mit 8 GB RAM nehmen (Windows 2003 Enterprise 64 bit notwendig) mit mindestens 3 RAID SCSI LUNS (1 LUN OS und Pagefile, 2 LUN für DB/LOG). Dann natürlich flotte Disks 15 K denn das ganze is nit übel I/O lastig. Nit dass das Disksystem am Schluss nen dicken Hals kriegt. Es sind jedoch zwei mittelstarke Server deutlich eher zu empfehlen als eine MegatönderMaschine .... .... Und wenn man schon am Planen ist, wichtig ist auch das Backup ! Grüsse, Matthias

:cool: Habe ich auch schon gemacht

Hallo Das sieht komisch aus. Firewall ist auf beiden DCs aus ? Eine Replikation kann entweder mit dem repadmin oder replmon forciert werden - allerdings denk' ich nicht, dass dies geht - trotzdem mal: cmd Fenster öffnen und eingeben: repadmin /syncall -> poste mal den Inhalt Im Replmon gibt es etwa in der Mitte ein Pulldown Menu, wo drin steht "search domain controller for replication error" (oder ähnlich). Gruss, Matthias

Hallo Zusammen Ist vorgesehen, dass Exchange 2007 auf einem Domain controller installiert wird ist folgende Reihenfolge essentiell, da sonst Fehlfunktionen vorhanden sind: 1. Server aufsetzen 2. Domain controller "machen" 3. IIS installieren 4. Exchange 2007 Installation beginnen Wird der IIS vor dem promoten zum DC installiert, kann u.U. der Fehler 440 Logon timout im OWA auftreten. Ursache: der IUSR_Servername muss bei dem promoting Vorgang von einem Lokalen Benutzer zu einem Globalen Domain user konvertiert werden. Gleichzeitig mit dem IWAM_Computername. Es hilft folgender Workaround um OWA zum Laufen zu kriegen: 1. Mail ACcess Rule deinstallieren (den Rest aber lassen!) 2. IIS deinstallieren 3. IUSR_Servername und IWAM_Servername in der AD suchen und löschen - 1. IIS installieren 2. ASPNET_Regiis -i in dem Microsoft.NET\Framework64\2.xxx aufrufen (repariert .NET2.0) 3. MailAccess Rule installieren Zur Wiederholung: Grundsätzlich gibt es von MS keinen Support von Exchange 2007 auf Domaincontrollern (!). Is es dennoch vorgesehen, muss der promotingvorgang (nach Microsoft!) vor der Exchange installation gemacht werden. Verliert der Server dannach seine Domaincontroller Funktion, muss zuerst Exchange 2007 komplett deinstalliert werden. Ein promoting/demoting Vorgang mit nem Exchange 2007 drauf funzt nit und wird keinenfalls empfohlen. Gruss, Matthias

Hallo Zusammen Wird der Exchange 2007 auf einem Domain controller installiert, kann es vorkommen, dass der Service "Exchange Edge Transport Service" und/oder "Exchange Transport Service" nicht gestartet werden können. Die Ursache liegt darin, dass diese Dienste nicht mit "LocalSystem" eingerichtet werden können sondern mit "Network Service". Grund: Sind die Exchange 2007 Rollen auf mehrere Server verteilt, hat der "LocalSystem" SErvice keine Übergreifende Credentials. Die Ursache liegt häufig bei Domaincontroller, dass der Logon as Service für den Network Service nicht erlaubt ist. Laufen alle Rollen auf einem dedizierten Server kann der Service während dem das Setup läuft auf LocalSystem gestellt werden. Gruss, Matthias

Hallo Das sieht so aus, dass da was im DNS nicht stimmt, denn der FQDN sollte von den internen Servern (= Domain controller) aufgelöst werden. Was ergibt denn netdiag /fix und dcdiag /fix ? Gruss, Matthias

:D D D D D D D D D D D D D D D D D D D Ja natürlich Strom ist eine wertvolle Resource. Alles mal abschalten was nit nötig is :cool:

Glückwunsch ! Matthias