zahni

Vielleicht greift der User per VPN auf einen Drucker am internen PC zu ? Details erfährst DU, wenn Du mal Netmon oder Wireshark auf dem betroffenen internen PC laufen lässt.

Wozu solltest Du Netzwerkkonfigs sichern, die von einem DHCP gesetzt worden sind ? Bei HP-Tools schaust Du am Besten mal im Tool nach. Besser wäre es, die Einstellungen aufzuschreiben...

Dann öffne nur die Ports, die im Internet benötigt werden. Im Zweifel nur SMTP(S)

Hängt der Server am Internet ? Dann brauchst Du Dich nicht zu wundern. Die Script-Kiddies probieren alles Mögliche. Es könnte ja immerhin doch ein HTTP auf dem SSL-Port laufen ;) Schaue mal in der HTTP-Logs vom IIS.

Das gibt es viele Möglichkeiten, z.B. http://eventid.net/display-eventid-36888-source-Schannel-eventno-10545-phase-1.htm

Benutze mal die Suche im Forum, z.B. http://www.mcseboard.de/topic/161083-64-bit-druckertreiber-auf-einem-32bit-drucker-server-bereitstellen/

Vom Umbenennen einer AD-Domäne sollest Du Abstand nehmen. Die Internet-Domäne zu ändern ist deutlich schmerzfreier ;) Ich würde einfach den Internetauftritt ändern (lassen), damit der Zugriff auch mit www. klappt.

Wie geschrieben: die IE verhält sich korrekt und die anderen beiden Browser nicht. Zertifikate für IP-Adressen sind ungültig, da der "Eigentümer" einer IP-Adresse i.d.R. nicht verifiziert werden kann. Die "gehören" ISP's. Falls das ein Self-Signed Zertifikat ist, musst Du es per GPO im richtigen Truststore (k.a. welcher) verteilen. In deinem Fall scheint aber die FW mit seiner ausgedachten Root-CA ein Cert erstellt zu haben. Das würde ich nicht machen. Hier solltest Du eine richtige eigene CA bereistellen. Alternativ das Root-Zertifikat der FW per GPO in die vertrauenswürdigen Stammzertifizierungsstellen importieren Ich bin mir sicher, dass die genaue Vorgehensweise in der Doku der FW steht.

Noch ein Boot, und alles wird gut, oder ;)

Nein, dass bedeutet, dass Das Dein "universeller" Lizenz-Key ist, denn DU bei jeder XP-Prof. Installation benutzen kannst. KMS und MAK gab es bei XP noch nicht. selbstverständlich musst Du aber trotzdem Lizenzen für den PC erwerben. Mal davon abgesehen, sollte man , 4 Monate vor Ende des Supports, von neuen Installationen Abstand nehmen.

z.B. könnte das Konto Users in der Domäne aus irgendwelchen Gründen gesperrt sein. Dann geht SSO natürlich auch nicht. Ich glaube nicht, dass es am IE liegt.

Nun, das ist nicht zwangsläufig ein "Tool" sondern ein ganzheitliches Konzept. Z.B. spielt hier auch eine Roll wie und wo die Daten gespeichert werden. Will der Kunde z.B. eine WORM-Speicherung ? usw. Mein Tipp: Suche Dir eine Fa., die sich damit und den Konzepten auskennt. "Billig" funktioniert hier nicht. ELO ist z.B. ein guter Ansprechpartner.

Ich für zuerst mal definieren, was eine "revisionssichere Archivierung" ist. Dann würde ich einen Anforderungskatalog/-Konzept erstellen. Dann suche ich nach einem Produkt...

Weil sie sich vor Gericht streiten und jeder noch auf seiner Meinung beharrt.

Zu 1: Ja, wenn die OEM bzw. SB-Lizenzen 2 wirklich 2 phys. CPU's abdecken. Zu 2: Von der DataCenter-Edition darfst Du beliebig viele virtuelle Instanzen erzeugen. U.U. sin die auch Downgrade-Fähig, wobeiu Du hier i.d.R. Volumen-Lizenzen brauchst. Die Produkt-Key der DataCenter-Edition lassen sich nicht für andere Windows-Server-Versionen/Editionen verwenden. Um ein Desktop-Windows zu virtualisieren benötigst Du sog. VDI-Lizenzen, die es nur für Vertragskunden gibt. In Deiner Planung ist es eh sinnfrei Windows 7 als Server zu missbrauchen. zu 3: Siehe 2 zu 4: für RDS-Zugriffe werden immer RDS-Cal's benötigt. PS: Device-Cals (pro Server) sind in der meisten Fällen die falsche Wahl. i.d.R. lizensiert man pro User für einen unbegrenzte Anzahl von Servern.

Wer generiert denn den Link auf die "Landing-Page" ? Im Zweifel die FW. Dann würde ich dort mal nachschauen oder den Hersteller fragen. Eventuell kann die FW auch SSO mit Kerberos, o.ä., dann müssen sich die User nicht mehr manuell anmelden.

Auf IP-Adressen stellt man keine Zertifikate aus. Die Zertifikate stammen am Besten von einer Windows-CA. Das notwendige Root-Zertifikat wird dann über das AD automatisch verteilt. Alternativ kann man das auch in einer Gruppenrichtlinie machen. Übrigens finde ich die Verwaltung der Zertifikate im Firefox ziemlich gaga. Das (und einige andere Dinge) disqualifizieren den für mich im Unternehmenseinsatz.

Prüfe auch mal, ob die User das richtige Papier-Format benutzen. Manchmal wird "benutzerdefiniert" verwendet, was seltsame Probleme verursachen kann.

Ich würde spontan schreiben: Das geht nicht. Eventuell klappt es mit einem HHTP-Proxy-Server und passender Proxy.pac. Auf Externen Webseiten sollte man übrigens möglichst mit relativen Pfaden arbeiten und niemals der Servernamen im Quelltext eine Webseite fest kodieren. Einen festen Servernamen darf, wenn überhaupt, nur das CMS dynamisch reinschreiben.

Dann ist das Kind in den Brunnen gefallen. Ich kann Dir nur dringend empfehlen, bei MS einen Support-Case zu öffnen und Dir dort helfen zu lassen. Weitere Experimente machen es womöglich noch schlimmer. Derartige Offline-Sicherungen bei DC's und vor allen Dingen Rücksicherungen sind bei DC's dringend zu unterlassen.

Hallo, hast DU ein konkretes Problem oder ist das nur eine allgemeine Frage ? Warum sollte man Bootrec auf einem DC benutzen, wenn man nicht gemacht hat ?

Und ich hätte mal bei HP geschaut, wenn ich wüsste, was der TO nun genau im Server stecken hat.

Was genau habt Ihr denn da in der Fa. "Kollege" zusammengebaut ?

@Necron, hier habe ich gewisse Zweifel. HP wird es sicher schaffen, aktuelle (getestete) Broadcom-Treiber zu liefern. Zumal HP dieses Feature z.T. in den techn. Daten erwähnt. Dazu müsste man wissen, welchen DL 360 der TO genau hat und welches genaues NIC-Modell.

Ich würde trotzdem auf einen richtgien Harsware-Raid-Controller verwenden. Die können mittlerweile auch SSD. Oder, vielleicht besser, einen guten externen Storage per ISCSI oder Fibre Channel.