olc

Hi Tron, grundsätzlich könntest Du Dir das beispielsweise mittels CAPICOM scripten. Aber im Prinzip ist certutil doch vollkommen ausreichend, Du leitest die Ausgabe einfach an ein "FIND" bzw. "FINDSTR" weiter und liest das ERRORLEVEL aus (zumindest in einer Batch-Datei, das Prinzip ist jedoch auch bei Scriptsprachen dasselbe). Wurde der gewünschte String (etwa die Seriennummer) gefunden, hast Du ein ERRORLEVEL==0, wurde es nicht gefunden, hast Du ein ERRORLEVEL==1. Zum Beispiel: certutil -v -store -user MY | findstr /I "135478900000852" IF "%ERRORLEVEL%"=="0" ( ECHO Alles klar. ) else ( ECHO Zertifikat nicht vorhanden. ) Viele Grüße olc

Hi Oli, zu Frage 1: Einen bestimmten Rechner zu einer bestimmten Zeit sperren geht meines Wissens nicht, Du kannst den Benutzer jedoch abmelden, siehe: HOW TO: Limit User Logon Time in a Domain in Windows Server 2003 Zu Frage 2 schau einmal hier hinein: https://www.mcseboard.de/windows-forum-ms-backoffice-31/bestimmte-computer-sperren-150455.html Viele Grüße olc

Hi, versuche es einmal hiermit (ungetestet): C:\> FOR /F "tokens=*" %i in ('dsquery computer "DN der zu durchsuchenden OU" -o dn -stalepwd 80 -limit 0') DO dsmove %i -newparent "DN der Ziel-OU" Viele Grüße olc

Hi, die Shares sind nicht da, weil der DC noch nicht "komplett" hochgestuft ist. Die Probleme verhindern also den Abschluß des Vorgangs, daher wird er also auch noch nicht als DC gehandelt und gibt die Shares nicht frei. Welchen DNS Server hast Du auf dem neuen DC eingetragen? Trage testweise (falls das nicht der Fall ist) einmal den 1. DC ein, der also vorher schon in der Struktur war. Die Schema Fehler sollte man auf jeden Fall im Auge behalten, ob sie später wieder auftreten. Falls nicht, hat das Forestprep seinen Dienst getan, falls doch kannst Du unter Umständen später in Probleme laufen. Viele Grüße olc

Hallo, was genau meist Du mit "DFS sichern"? Meinst Du DFSN, also die Namespaces etc. bzw. die Links dahinter oder meinst Du DFSR, d.h. replizierte Ordner? Viele Grüße olc

Hi, unter Vista / 2008 hat sich das ActiveX Control geändert, welches die Abfrage per SSL stellen möchte. Das "Problem" (sprich: Feature) liegt also auf der Client-Seite, nicht an der CA / dem IIS. Man kann dieses Verhalten umgehen - aber vorher einmal gefragt: Warum richtest Du denn kein SSL ein? Das verwenden von HTTP setzt die Sicherheit herunter und gerade bei einer CA sollte das doch eigentlich vermieden werden oder? Und das Anfordern eines SSL Zertifikats direkt auf einer CA sollte auch keine große Hürde sein. ;) Viele Grüße olc

Hi, wie gesagt - ich würde es nicht mit einem VPN lösen, sondern eher mittels BOT die erforderlichen Ports in beide Richtungen freigeben. Zwar ist das ganze dann als DMZ nichts mehr wert und Du läufst in massive Sicherheitsprobleme, aber dieses Thema hatten wir ja schon. ;) Viele Grüße olc

Hi, ergänzend noch ein Hinweis: Du wirst wahrscheinlich in keinem Buch eine komplette Übersicht über alle Gruppenrichtlinien bekommen, das sind seit Vista / 2008 ca. 2.500 Stück. Macht also m.E. nach nicht wirklich Sinn. Das oben von Dir genannte Buch bietet aus meiner Perspektive eher den "Einstieg" in das Thema und bespricht auch einige Gruppenrichtlinien und die dazugehörigen Konzepte. Im Vorwort wird auch explizit darauf eingegangen, daß eben nicht alle Einstellungen einzeln besprochen werden. Wenn Du ein wenig tiefer einsteigen möchtest, ist m.E. das folgende Buch zu empfehlen: Windows® Group Policy Resource Kit: Windows Server® 2008 and Windows Vista® . Umfaßt sicher auch nicht alle Bereiche, bietet aber an einigen Stellen einen etwas tieferen Einblick als das erstgenannte Buch. Das heißt nicht, daß das ein oder andere Buch schlecht ist, lediglich die Zielgruppe ist eine andere. Viele Grüße olc

Hi Patrick, nein, mach Dir keine Gedanken. Keiner macht sich lustig. Der einzige "Kritikpunkt" ist die fehlende Information, daß es ein RODC ist. Denn das verändert die Situation maßgeblich, wie die Kollegen ja schon schrieben und Du ja auch selbst schon bemerkt hast. ;) Mit der Information hätte sich das Problem sicher schon frühzeitig lösen lassen - aber gut, woher sollst Du wissen, daß das für uns wichtig gewesen wäre. Beim nächsten Mal einfach "alle" Informationen schreiben, die Du so auf dem Schirm hast. ;) Einen Hinweis noch dazu: Mindestens ein anderer Windows Server 2003 DC wird sich auch weiterhin höchstwahrscheinlich in der Site Polen registrieren, was die Ausbeute des "LOGONSERVER" auf den Clients auf 50/50 drückt, den RODC zu erreichen. Daher solltest Du auf den anderen Windows Server 2003 DCs (als auch wegen anderer Sachen auf den Clients) den folgenden Hotfix installieren (siehe "Issue 10"): Description of the Windows Server 2008 read-only domain controller compatibility pack for Windows Server 2003 clients and for Windows XP clients Viele Grüße olc

Hi, wenn sie wieder registriert werden, dann muß ggf. noch etwas umgestellt werden. Das wirst Du ja dann sehen. ;) LDAP, Kerberos und ggf. GC Einträge, korrekt. :) Viele Grüße olc

Hi, also vorausgesetzt, Du meinst jetzt wirklich die DNS SRV Einträge, dann kannst Du die Einträge problemlos löschen. Das Verhalten könnte durch die "automatic site coverage" hervorgerufen sein: How DNS Support for Active Directory Works: Active Directory Andere Einträge außerhalb des DNS solltest Du jedoch nicht löschen - dabei kann einiges "kaputt gehen". Viele Grüße olc

Hi Patrick, schau Dir in jedem Fall einmal die Grundlagen zum Thema an, sonst wird das hier schwierig. :) Sehr umfassend ist der Branch Office Guide für Windows Server 2003 zu dem Thema: Download details: Windows Server 2003 Active Directory Branch Office Guide Die registrierten DNS SRV Einträge für den DC findest Du in der _msdcs DNS Zone. Dort sind auch Site-spezifische Einträge - für die polnische Site sollte dort bestenfalls nur der polnische DC registriert sein. In den Sites and Services mußt Du den polnischen DC in die Site Polen verschieben, sonst registriert er sich nicht für diese Site im DNS (mal abgesehen von einigen "Spezialitäten", denn ein DC deckt standardmäßig Sites ohne DC ab, aber das ist ein anderes Thema). Also, noch einmal in aller Kürze zum besseren Verständnis: 1. Site für Polen einrichten. 2. Subnetz für Polen einrichten. 3. Polnischen DC in den AD Sites & Services in die polnische Site verschieben. 4. Subnetz Polen mit Site Polen verknüpfen. 5. NETLOGON Dienst auf dem polnischen Server neu starten. 6. _msdcs DNS Zone prüfen, ob in der polnischen Site im DNS nur die SRV Einträge des polnischen DCs registriert sind. Viele Grüße olc

Hi Patrick, ist der DC der entsprechenden polnischen Site zugeordnet bzw. hast Du auch das Client Subnetz mit dieser Site verlinkt? Falls nicht, solltest Du das nachholen. Falls doch, schau einmal in der DNS Zone in den Sites nach, welche DCs sich für die entsprechende Site eingetragen haben. Viele Grüße olc

Hi, auch wenn Du jetzt hier inkognito schreibst, mußt Du den Ton nicht weiter fortführen, den schon der verkappte Aufruf hatte. Ich habe meine Meinung dazu gesagt, die läßt sich sicher auch nicht durch diese niveaulosen Beleidigungen Deinerseits ändern. Es macht - denke ich - keine Sinn, ernsthaft auf Deine Beiträge hier zu antworten, denn dann würde der Thread hier auch noch vollkommen abgleiten. Daher lasse ich das einfach mal und wünsche viel Erfolg mit dem Unterfangen. Von dem, was ich bisher in meinem Arbeitsalltag erleben durfte, wirst Du mit dieser Art und Weise sicher nicht mit dem Vorhaben durchkommen. Du erreichst damit eher das Gegenteil. Denn genauso, wie Dir das egal ist, ist es auch den Herstellern, wenn diese mit einem solchen "Pranger" konfrontiert werden. Viele Grüße olc

Guten Abend, Ich denke schon, daß das funktioniert. Zumindest ist mir in der Vergangenheit noch nie ein Problem mit den Freigaben untergekommen. Aber ich habe im Moment kein IPCop System zum Testen. Meines Erachtens eine ganz schlechte Idee. Einen Server für Daten / Backup und gleichzeitig als Web / FTP Server für den Zugriff von außen zu nutzen, ist ein Verbrechen. ;) Laß die Finger davon, damit kannst Du wirklich auf die Nase fallen... Na ja, "sicher" ist die Virtualisierung leider auch nicht. Aber wenn es denn unbedingt sein muß, ist es besser, als die derzeitige Konstellation. Insgesamt würde ich es jedoch (auch bei knapper Hardware) auf ein extra System packen. Auch wenn es erst einmal teuer scheint - wenn Deine Daten / Kundendaten verloren gehen oder "öffentlich" werden, dann sind die Kosten in vielerlei Hinsicht höher. Etwa über WebDAV oder FTP / SFTP. Aber wie gesagt, ich würde das gar nicht so lösen. Viele Grüße olc

Hi, ich vermute, daß Du den Server nicht im orangenen Netz betreiben kannst. Ich bin mir im Moment nicht sicher, inwieweit hier Stateful Packet Inspection ausreichend ist. Du müßtest also eher BOT nutzen und einige Ports auch vom Server zu den Clients freigeben. Der TCPDUMP zeigt nur die HTTP Zugriffe, die sind meines Erachtens im Moment nicht relevant. Wichtiger wären die Netzwerkzugriffe auf den Server. Wie gesagt, ich denke, daß es mit dem orangenen Netz nicht funktionieren wird. Dort wird das Problem liegen. Bevor Du nun weiter nach einem Problem suchst, was schon geklärt ist, würde ich vorschlagen, daß Du Dir einen Switch besorgst und den Server mit in das grüne Netz hängst. Falls es dann immer noch Probleme gibt, dann schauen wir weiter. Aber ich würde vermuten, daß das nicht der Fall ist. ;) Insgesamt vielleicht noch einmal die Grundsatzfrage zu dem Vorhaben: Was möchtest Du genau damit erreichen? Warum stellst Du den Server in die DMZ? Viele Grüße olc

Hi, die "Checksummenfehler" liegen meist an Netzwerkfunktionen wie "TCP Offloading" etc., die kannst Du also im Normalfall getrost ignorieren. Wenn am Server gar keine Sicherheitsmeldungen beim Zugriff auf das Share im Security Protokoll geloggt werden, kommt nichts an. Das war auch nach der Fehlermeldung zu erwarten. Schalte einmal konkret den Firewall-Dienst auf Client und Server ab und versuche den Zugriff noch einmal. Zusätzlich könntest Du testweise einmal einen Client auf die "Server Seite" stellen, das Subnetz anpassen und den Zugriff nochmals versuchen. Wie genau hast Du den Zugriff am IPCop eingestellt? Nutzt Du die Standard Mechanismen mit grünem und gelben Netz (in welchem Netz steht der Server?) oder nutzt Du BOT als AddOn? Viele Grüße olc

Hi, was steht im Sicherheitsprotokoll des Servers? Wird der Logonversuch protokolliert? Ist vielleicht auf dem 2003er Server eine Firewall aktiv? Oder eine Firewall auf den Clients, die Zugriffe nach außen blockiert? Die Freigabe der Verbindungen am IPCop zeigt in beide Richtungen und nicht nur in eine Richtung als "one-way ticket"? Zieh doch einmal einen Netzwerktrace und schau einmal hinein, was genau beim Zugriff passiert. Viele Grüße olc

Hi, gib doch testweise einmal alle Ports frei - wenn es dann geht, weißt Du, daß es an den Ports liegt. Dann könntest Du ggf. einen Netzwerktrace ziehen und prüfen, welche Pakete nicht durchkommen. Ggf. liegt es auch am Protokoll, es wird ab und an zwischen UDP oder TCP unterschieden. Probieren könntest Du auch noch den Zugriff über die IP-Adresse des Servers, nicht über den Namen. Dann wird kein Kerberos verwendet, sondern NTLM. In der Aufstellung oben fehlt u.a. auch die Freigabe für Port 88 UDP / TCP (Kerberos). Bei dem Thema: wenn es sich um eine Domänenumgebung handelt, müssen noch weitere Ports freigegeben werden. Daher solltest Du in jedem Fall in das oben genannte Dokument schauen, es sind dann noch einige Anpassungen vorzunehmen. Eine Firewall in solchen Konstellationen ist halt immer so eine Sache. Viele Grüße olc

Hi, der Fehler 131 bedeutet "ERROR_NETWORK_UNREACHABLE". Du mußt neben den Ports 137-139 TCP / UDP für Netzwerkfreigaben in jedem Fall Port 445 TCP und auch Port 135 TCP freigeben. Dazu kommen noch einige dynamische RPC Ports, bei Windows Server 2003 standardmäßig oberhalb von 1024. Damit solltest Du nicht zu knapp sein, auch wenn Du den Zugriff einschränken willst oder mußt. Siehe dazu auch: Service overview and network port requirements for the Windows Server system Viele Grüße olc

Hi, hast Du das oben angesprochene Logging einmal aktiviert und einen Blick hinein geworfen? Viele Grüße olc

Hi Leute, ich halte mich im Normalfall aus solchen Diskussionen heraus, weil sie meist nichts wirklich fruchtbares bringen. Aber mir stößt das ganze hier schon ein wenig übel auf, so daß ich mich doch dazu hinreißen lasse, zwei Zeilen zu schreiben. Ich bin absolut bei Euch - solche Software kennt wahrscheinlich jeder von uns, mögen tut sie keiner. Ich wäre auch dafür, daß man das in irgend einer Form "öffentlicher" macht, vielleicht kann man damit etwas erreichen. Aber der Ton, in dem der Aufruf und auch einige Beiträge hier gehalten sind, ist meines Erachtens absolut fehl am Platz. Das ganze dann noch mit einer zusätzlichen "Wunschliste" zu verknüpfen, macht das ganze nur noch absurder. Sowas in der Art hatten wir in der Vergangenheit schon, das nannte sich dann Hexenverbrennung bzw. Inquisition. Da haben dann sicher 100% objektive "Richter" darüber entschieden, wer eine Hexe oder ungläubig war. Ich gebe Euch Recht - gerade bei Nischensoftware sind Alternativen rar gesät. Nur ist der Preis genau das Druckmittel, daß man gegen die Hersteller geltend machen kann und muß. Da nützen öffentliche "Hetzlisten" wenig, sondern nur ein seriöses Vorgehen. Und ganz ehrlich - genau diese Seriösität fehlt mir persönlich bei der Lesart des Aufrufs und der Beiträge dazu. Man kann auf solche Programmierung sicher nicht nur mit Kopfschütteln reagieren, man muß etwas tun. Dann aber doch bitte mit etwas mehr Niveau. Viele Grüße olc

Hi, vielleicht hilft Platz 1 der Suchergebnisse von Tante "G"? JSI Tip 4829. Domain Administrator can't create a GPO and link it to an OU? Viele Grüße olc

Hi, ok, also hat das Vertauschen des primären DNS Servers doch etwas gebracht. Hat sicher nur etwas gedauert, da der NETLOGON Dienst zyklisch die DNS SRV Einträge registriert, nicht direkt nach so einer Umstellung. Vermutung ist also, daß der DNS Server des "lightdc1" nicht korrekt läuft, das solltest Du Dir also noch einmal anschauen. Einen Grund dafür muß es ja geben. ;) Du mußt die Reverse Lookup Zone nicht eintragen, Du kannst aber. Das ist immer von den Anforderungen abhängig - aber wenn Du es bisher nicht benötigt hast, sehe ich jetzt keinen Grund, es "einfach so" zu tun. Viele Grüße olc

Hi pastors, wenn hast Du vielleicht irgendwelche Filter (Item-Level Targeting) definiert? Unter Umständen sind ja auch die EInstellungen der Druckerzuweisung selbst nicht korrekt. Schalte doch einmal das GPP Logging and Tracing ein, vielleicht bekommst Du einen Hinweis, was das Problem ist: Computer Settings --> Policies --> Administrative Templates --> System --> Group Policy --> Logging and Tracing --> Printer ... wählen. Am besten den Pfad für die Logdateien ändern, %COMMONAPPDATA% ist "doof". ;) Viele Grüße olc