Webbrauser

Hallo ihr zwei - danke für die Anteilnahme und die Links. Die habe ich allerdings auch alle schon durch. Vielleicht zu deiner Frage nach dem Grund: Ich finde es einfach extrem schön für die unterschiedlichen Netzteilnehmer eigene Subnetze zu bilden - da könnte ich jetzt einige fadenscheinige Gründe aufzählen aber letztlich gehts mir darum auf einen Blick zu erkennen in welchem Netz sich nun etwas befindet. Davon ab ist es beliebig erweiterbar. Ich habe aber gerade eben beim Spaziergang noch einen Gedanken gehabt: Auf dem Gigabit Switch sind momentan NUR Server Auf dem 10/100er Switch NUR Clients Die DMZ hängt schon direkt auf der Firewall (.. logisch,was? :-) ) Die Peripheriegeräte lass ich jetzt mal aussen vor und die Netzwerkgeräte brauchen keine DHCP-Adressen.. Ich könnte nun also meine Doppelten Gateways auf einem FW-Port überdenken und nochmal splitten bzw. dedizieren kurzum sagen ETH1 - Trusted - 172.26.1.254 /24 ETH4 - Trusted - 172.26.2.254 /24 So müsste dann ja der Watchguard-Eigene DHCP-Relay (auf beiden IFs einzustellen) funktionieren denn: Die Broadcastanfrage erreicht letztlich nur das jeweilige Gateway des Subnetzes- kann nun also in das an den DHCP-Server weitergeleitete Unicast Paket die GIADDR so setzen, dass es aus dem Subnetz 26.1 oder eben 26.2 kommt und so die jeweilige Antwort anfordern. Dafür müssten nur die jeweiligen Scopes am DHCP-Server vorgehalten werden damit für das jeweilige Subnetz ein DHCPOFFER erstellt wird... . Soweit die Theorie. Vielleicht habe ich euch mit dem vielen text auch einfach verwirrt - grundlegend ist meine Anforderung einfach: Ich möchte, dass der DHCP-Relay der Firewall die Anfragen aus allen daran angeschlossenen Netzen an den DHCP-Server (den einen) ausliefert und aus den daran unterschiedlichen Subnetzen ( 26.1 , 26.2 , 26.3 , 26.4 --- und so weiter) antworten bzw. leases liefert. Ich glaube aber, dass das Problem einfach darin gelagert ist, dass die Firewall momentan nicht erkennt aus welchem Netz die anfrage nun wirklich kommt da es keinen echte Terminierung in einem Subnet gibt weil alles momentan auf einem Port liegt. Ausserdem sind die Switche momentan "in Reihe" gesteckt. Also Aus sicht vom Client: Client->Switch->Gigabit Switch->Firewall ETH1 (172.26.1.254 , 172.26.2.254 , 172.26.3.254 ) Aus Sicht vom Server Server -> Gigabit Switch -> Firewall ETH1 (172.26.1.254 , 172.26.2.254 , 172.26.3.254 ) Wenn ich es zukünftig nun so mache: Server-> Gigabit Switch -> Firewall ETH1 - 172.26.1.0 /24 Client -> Switch -> Firewall ETH4 -> 172.26.2.0 /24 Dann sollte der Relay Agent doch auch raffen aus welchem Subnetz nun die Anfrage kam. Agree? Danke für eure Gedanken :-)

Ich glaube es hat etwas mit meinen multiplen Gateways und dem Anschluss der Watchguard zutun: Die Watchguard hat einen Uplink auf einen 16 Slot Gigabit switch (für Server) (VLAN-Fähig) Dieser Gigabit Swith widerum einen auf einen 16 Port 10/100 (für Clients) (Nicht VLAN-Fähig) Wie soll nun also der auf der firewall aktive dhcp-relay agent erkennen aus welchem Netz die Anfrage stammt um dem dhcp-server mittels Unicast um eine IP-Adresse aus jenem Bereich bitten Kann es sein, dass ich einen VLAN-fähigen Switch brauche? Helft mir mal beim Brainstorming :(

Ms scom? :-)

Hi! Sind gemeinsamkeiten zwischen den Usern die die VPN Verbindung nutzen erkennbar? Nutzen vielleicht alle ne Fritzbox ( heutzutage ja schon fast kein Zufall mehr ) und tunneln über Teredo? Und Angaben zur VPN Verbindung wären natürlich toll... PPTP, L2tp, IKEv2? Viele Grüße!

hat jemand an deinem exchange rumgespielt?

Danke für eure Hilfe :-)

Hallo miteinander, wie immer beginnt ein Thread mit dem Eingeständnis eines Problems - beinahe wie in einer Selbsthilfegruppe - ich möchte euch also bitten mir bei der Lösung des Problems zu helfen: Infos zum Aufbau: Es gibt aus logischen Gründen 6 verschiedene Subnetze 172.26.1.0 /24 (Server) 172.26.2.0 /24 (Clients) 172.26.3.0 /24 (Peripherie (Drucket etc.)) 172.26.99.0 /24 (Netzwerkgeräte) 192.168.200.0 /24 (DMZ 1) 10.0.0.0 /24 (DMZ 2) Es gibt ein für alle geltendes Gateway - dabei handelt es sich um eine Watchguard XTM 330 ETH0 - External \ static WAN IP ETH1 - Trusted \ 172.26.1.254 \ .2.254 \ 3.254 \ 99.254 ETH2 - External \ Dynamic WAN IP ETH3 - DMZ \ 192.168.200.254 \ 10.0.0.254 Was die mehreren Gateways auf einem Port angeht : Ich bin mir bewusst, dass das für jeden Sicherheitsverliebten Administrator eine Hölle sein muss diese Konfiguration zu sehen aber im ERSTEN Schritte ging es hier nur um eine logische Trennung - nichts weiter. Wo wir beim nächsten Problem wären: ETH1 geht an einen (layer-2) Switch ohne konfigurierte VLANs - Die Konfiguration hierfür steht noch (aufgrund eines Hyper-V-Clusters) noch aus ist aber für das vorherrschende Problem nicht relevant DHCP Snooping etc. ist NICHT aktiv. Problem: Mein DHCP Server ist der 172.26.1.3 - über diesen möchte ich auch für die Clients in 172.26.2.0 Adressen verteilen. Nun habe ich auf ETH1 der Watchguard "DHCP-Relay" aktiviert und die IP-Adresse des DHCP-Servers angegeben. In Ordnung - ich bin dann nach ein paar Minuten von selbst darauf gekommen, dass ein Broadcast schlecht routbar ist.... . Ich habe mir dann gedacht, dann nehme ich doch einfach meinen VPN-Server als DHCP-Relay. Dieser hat die 172.26.1.253 und dient mir momentan als einfache Bereitstellung eines PPTP-VPN. Dort habe ich den EINZIGEN LAN-Adapter (!) als Schnittstelle des DHCP-Relays hinzugefügt und die IP-Adresse auf ETH1 der Watchguard dementsprechend geändert. Siehe da - die Anfragen (welche auch immer) rasseln fröhlich ein werden aber gleichermaßen wieder gelöscht. Blick in die Ereignisanzeige - der DHCP-Server kann nicht erreicht werden. OK. Ich habe dann dem DHCP-Relay Agenten auch die IP des DHCP Servers mitgeteilt :o ... . Dort kommen aber, aufgrund des dortig konfigurierten Scopes, leider keine Anfragen an, da er lediglich 172.26.2.99 - 172.26.2.115 (Alles nur tests...) als Scope hinterlegt hat. Also dachte ich mir: Okay - dann leg eben noch eine zweite Zone an - nur um auszumerzen, dass es hier im Netz irgendeinen Switch gibt der die weitergeleiteten DHCPoffers killt. 172.26.1.66 - 172.26.1.68 Tada! Clients tauchen auf. Gut nun habe ich fleißig rumgespielt und festgestellt, dass ich wieder am Anfang stehe. Um erstmal zu verhindern, dass mir am Montag die Struktur um die Ohren fliegt habe ich die Watchguard als zentralen DHCP-Server konfiguriert und den auf dem Server deaktiviert. Klappt einwandfrei - Adressen aus 172.26.2.x werden wie konfiguriert verteilt. Nun dachte ich mir ich probier einfach von zuhause weiter und schau mir das ganze mal mit Wireshark etc. an - connectiere mich und stelle fest. Ich bekomme eine IP von meiner Watchguard, so wie es auch sein soll, komme aber nun an nichtsmehr dran. Ping auf IP\Name ergebnislos, rdp klappt nichtmehr. Ich bin mir nun ziemlich sicher, dass ich, wenn ich den Scope auf 172.26.1.x umstelle wieder fröhlich in meinem Netz umherschippern könnte - gehe ich also recht in der Annahme, dass ich hier meinen VPN-Server mit einer zweiten NIC in das entsprechende Subnet stellen muss? (börks) Nun zu meiner eigentlichen Frage: Ich bin kein Freund davon ein Netzwerkgerät DHCP spielen zu lassen und würde gerne für den Scope 172.26.2.99 - 172.26.2.115 meinen ursprünglichen DHCP-Server 172.26.1.3 nutzen. 1) Wieso klappt das mit einem DHCP-Relay nicht? 2) Wie krieg ich es hin, dass es klappt?

Hey.. ich stehe vor exakt demselben Problem... Eine Aussage zu der vorstehenden Frage wäre also hervorragenden :-) . Immerhin bin ich, zumindest der Logik folgend, schon soweit als das es unsinnig wäre einen KMS für ne Terminalserverinstallation zu nutzen. Offenbar zählt der KMS host nur die aktiven Installationen auf unterschiedlichen Hosts... . Sonst würde er schließlich in einer Domänenumgebung auf einem PC für jeden Nutzer office ebenfalls neu registrieren. Um Umkehrschluss hieße das nun - KMS Key auf Terminalserver = 1 Benutzte KMS Lizenz = die geforderten 5 werden nicht erreicht = Nach 90 Tagen kommt "der rote Balken" . Aber in einer Umgebung mit mehr als 20 Benutzern muss ich doch nicht wirklich mehr als 20x den MAK eintippen, oder?! Und Nein: Ich möchte nicht mit dem Office Customization Tool arbeiten... . Gibt es denn keine Möglichkeit über das VLSC an den Key für die Terminalservernutzung zu kommen?!

grüß dich! Ich hatte das Problem ebenfalls mal - da war da ein Problem beim dynamischen DNS-Update. Ich habe das Problem gelöst indem ich den DNS-Eintrag von dem dritten DC gelöscht habe - anschließend ein registerdns auf dem neuen DC ausgeführt habe und danach mit repadmin /syncall /force eine manuelle replikation angetriggert habe.. anschließend war alles tutti http://support.microsoft.com/default.aspx?scid=kb;de;229896

Hey, Danke für deine Rückmeldung :-) Ist es nicht genau das was SCCM macht, sobald ich in der direct Membership rule (got me!) als Systemressource den NetBiosnamen angebe? Ich war bisher in der Annahme, dass genau ein solcher Query die DB durchläuft. Mir wurden (!) auch zwei Stück zur Auswahl angezeigt. Aus Neugier habe ich dann im zweiten Anlauf (nachdem ich festgestellt habe, dass der den ich vorerst genommen hatte veraltet war) beide ausgewählt. Beide waren nicht obsolete und beide active. Ich kenne das bisher tatsächlich nur so, dass, z.B. durch Neuinstallationen o.ä. dann wenigstens ein Client ausgegraut (obsolete=yes) ist... . Okay, dann ist also ein Fehler durch das fehlerhafte DNS-Replikat (was ja ohnehin gefixt werden muss) auszuschließen. Sehr gut. Die Info, dass der Client den Server kontaktiert ist übrigens im allgemeinen mal sehr gut. Mal was anderes: Ich würde gerne auf 70-401 Zertifikatsjagd gehen - muss ich mich auf Multiple Choice oder auf Lab einstellen? Habe leider im Netz nichts dazu gefunden und bisher nur eine (popels-)Prüfung hinter mir... Eventuell hat ja einer von euch beiden die Muße mir da n kurzen Anriss zu geben :-)

...abgefahren...keine antwort ? :-(

Fehler gefunden: Ich habe zwei Rechner mit demselben Namen die ich für die Collection auswählen kann. Die GUID ist unterschiedlich; Die MAC dieselbe. Ich habe in geistiger Umnachtung die ältere Ressource genommen (Murphys Law) und mich gewundert warum nix passiert. Habe diese nun gelöscht und der aktuellen zugewiesen. Alles OK. Abgefahren.... Wie kann sowas passieren? Eigentlich sollte der "nichtmehr aktive" Client doch dann wenigstens ausgegraut sein?

Fehler die ich im execmgr gefunden habe: <![LOG[Failed to instantiate UI Server {C2F23AE4-82D8-456F-A4AF-A2655D8CA726} with error 80004005]LOG]!><time="15:53:34.536+-120" date="07-06-2010" component="execmgr" context="" type="3" thread="1032" file="uieventgenerator.cpp:164"> <![LOG[Cached CCM (user, session) is: (,-1).]LOG]!><time="15:53:34.536+-120" date="07-06-2010" component="execmgr" context="" type="1" thread="1032" file="usertoken.cpp:1138"> <![LOG[::GetSMSConsoleSessionId - No SMS console session found.]LOG]!><time="15:53:34.536+-120" date="07-06-2010" component="execmgr" context="" type="1" thread="1032" file="usertoken.cpp:135"> <![LOG[Failed to instantiate UI Server 2 {E8425D59-451B-4978-A2AB-641470EB7C02} with error 80004005]LOG]!><time="15:53:34.536+-120" date="07-06-2010" component="execmgr" context="" type="3" thread="1032" file="uieventgenerator.cpp:222"> <![LOG[Cached CCM (user, session) is: (,-1).]LOG]!><time="15:53:34.536+-120" date="07-06-2010" component="execmgr" context="" type="1" thread="1032" file="usertoken.cpp:1138"> <![LOG[::GetSMSConsoleSessionId - No SMS console session found.]LOG]!><time="15:53:34.536+-120" date="07-06-2010" component="execmgr" context="" type="1" thread="1032" file="usertoken.cpp:135"> <![LOG[Failed to instantiate Updates UI Server {2D023958-73D0-4542-8AD6-9A507364F70E} with error 80004005]LOG]!><time="15:53:34.536+-120" date="07-06-2010" component="execmgr" context="" type="3" thread="1032" file="uieventgenerator.cpp:279"> <![LOG[Cached CCM (user, session) is: (,-1).]LOG]!><time="15:53:34.536+-120" date="07-06-2010" component="execmgr" context="" type="1" thread="1032" file="usertoken.cpp:1138"> <![LOG[::GetSMSConsoleSessionId - No SMS console session found.]LOG]!><time="15:53:34.536+-120" date="07-06-2010" component="execmgr" context="" type="1" thread="1032" file="usertoken.cpp:135"> <![LOG[Failed to instantiate VApp UI Server {00AAB372-0D6D-4976-B5F5-9BC7605E30BB} with error 0x80004005]LOG]!><time="15:53:34.536+-120" date="07-06-2010" component="execmgr" context="" type="3" thread="1032" file="uieventgenerator.cpp:338"> Gestern aufgetreten --- Edit: Habe den Client einmal remote neuinstalliert. Jetzt ist das Log sauber - das Advertisement trotzdem noch nicht angekommen und die Daten noch immer nicht geupdated. Kann ich das irgendwie manuell anstoßen?

Übrigens: Die "Actions" wurden alle einmal angeworfen, in den Logs vom Client steht ausserdem, dass die IP geupdated wurde und alle Policys neu vom Server geladen wurden. Dennoch (auch nach mehrmaligem aktualisieren :-) ) erscheinen die ALTEN Settings unter "General" :-) .. das Advertisement ist darüberhinaus auch noch nicht beim Client angekommen und wird in keinem Log erwähnt :-(

Hallo boardgemeinde, ein kleines Problemchen hat sich bei unserer SCCM Installation eingeschlichen. Kurzer Anriss: zwei Standorte mit jeweils zwei DPs, Pakete sind verteilt, kommunikation mit dem installierten Agent funktioniert ohne Probleme. Nun ist der Client eine zeitlang nicht an gewesen und wird nun wieder genutzt. Ich setze also einen otto-normal ping auf die Maschine und stelle fest .. falsche IP. Hm, kurz im DNS nachgeschaut - ok ist auch falsch hinterlegt. Also den Namen aus dem DNS gelöscht - ipconfig /flushdns und schon funktioniert der Ping wunderbar. Jetzt habe ich allerdings BEVOR ich diese Pingproblematik herausgefunden habe schon ein Advertisement an eine Collection mit nur EINEM System losgeschickt ( und zwar dem mit dem fehlerhaften DNS-Eintrag) .. zusammengestellt wird die Collection als "System Ressource" mit der Suche nach "NetBios Namen" (jaja ich weiss :-) ) . In der Collection wird der Client hinzugefügt und das Advertisement angezeigt - Wenn ich mir nun die Eigenschaften für die Collection anzeigen lasse sind die Informationen vom Agent allerdings stark veraltet. .. Ich habe nachgelesen, dass die Informationen zum Subnet und zur IP vom hiesigen DHCP-Server gezogen werden mit anschließendem Ping auf die Maschine um dann die benötigten aktuellen Informationen abzurufen. Als Netzwerkermittlung ist Topologie, Client und Clientbetriebssystem angekreuzt - ich verwende kein SNMP! Wo liegt da der Fehler im Design? Muss ich nun wirklich 25 Stunen warten bis eine neue Frequenzermittlung durch ist und der Agent sich aktualisiert hat? Meldet sich der Server beim Client oder der Client beim Server? Klar könnte ich als workaround nun nach der Mac-Adresse suchen lassen und alles wär tutti.. aber das ist ja nicht Zielführend. Also kurz zusammengefasst: Wie funktioniert die Kommunikation zwischen Client (bzw. Agent) und Server? Warum ist der SCCM Server so sensibel was die fehlerhafte DNS-Einträge angeht - obwohl er doch die Daten vom DHCP abfragt. Vielleicht kann mir ja jemand helfen.. die Logs sind übrigens sauber.. Viele Grüße

Hi Leute, folgendes steht an: Eine ordentliche Diva Dialogics BRI-2M PCI 2.0 soll in einen HP ML350 eingebaut werden. Als Betriebssystem läuft (schon) SBS 2003. Wir möchten diesen Server mit der aktiven ISDN Karte nun eine Fax2email Lösung konfigurieren... hat in dieser Zusammenstellung jemand Erfahrungen machen können? Ich bin mir etwas unsicher wie ich die Strecke zur Telefonanlage ( denn genau da hört es bei mir auf ) realisieren soll\muss. Bisher wird ein normales Faxgerät genutzt..

Auslegungssache! :D

Gemacht - Ich warte dann mal ab und gehe Bescheid BSOD -> Blackscreen of Death

Intern haben wir einen WSUS laufen auf welchem die Updates vorqualifiziert werden - es sind also nicht ausnahmslos alle Updates installiert. Wohl aber die "ominösen" Novemberupdates die angeblich (..) für diesen BSOD verantwortlich sein sollen. Eventlog sagt leider garnichts - später dann nur, dass der Rechner nicht ordentlich heruntergefahren wurde (leider machen ein paar Agenten ihre Rechner dann einfach per langem drücken aus...) . Die Videotreiber habe ich gestern auf einem Client testweise aktualisiert - ich erwarte Rückmeldung. Danke für eure Antworten!

Hallo Mädels & Jungs, ich habe folgendes Problem vor der Brust - leider half mir die berühmte Suchfunktion auch hier nicht weiter - : Ein neu aufgesetzter Windows 7 Client (Domänenmitglied) vollführt seit ca. 2 Tagen merkwürdige Kunststücke. Nachdem er in den Sleepmodus gefallen ist und man ihn wieder weckt erscheint nur noch der Mauszeiger und ein schwarzer Hintergrund. Nach einem Reboot ist zwar das anmelden an der Domäne möglich - jedoch mit gleichem Resultat. Lediglich ein connect per rdp (adminkonsole) bewirkt, dass die Monitore ordentlich anspringen und man sich wieder anmelden kann. Nach einiger Suche bin ich auf den "Blackscreenfix" gestoßen und habe diesen installiert - ebenfalls ohne Erfolg. Meine Frage: Hatte bisher jemand in dieser Richtung dasselbe Problem und konnte es ggf. lösen? Ich möchte ungern neu installieren müssen (Da das Problem auf dem einen Client stellvertretend für 5 weitere geschildert wurde) :-( ... Eventuell hat da bereits jemand Erfahrungen sammeln können. Übrigens habe ich nur sporadisch entsprechendes Problem - teilweise läuft der Rechner auch ohne Probleme. Bisher konnte ich das Problem auch nicht auf bestimmte angemeldete User zurückführen....

Moin, gestern Abend mit ordentlich "Pumpe" probiert - zwar läuft das Enclosure kurzzeitig ein wenig Amok (bezogen auf die Lüfter :-) ) aber das ist ja nur verständlich.. Für alle die irgendwann eventuell vor dem selben Problem stehen sollten: es ist möglich, dass sleeve hot-plugged zu tauschen ohne, dass die Blades in irgendeinerweise in Mitleidenschaft gezogen werden :-) -closed-

ist ja auch nur ratsam .. is ja guuuhuuut :-(

Danke für deine Hilfe :-) .. Nur fürs Protokoll: Ich bin mir durchaus bewusst wie ich einzelne OA Module tausche. Ich wüsste nur gerne ob bereits schonmal jemand ein solches Problem hatte. Letztlich behalten beide OAs ja ihre Settings - lediglich die Verpackung (das Sleeve wovon ich immer spreche und womit offensichtlich nieman was anfangen kann) ändert sich... . Ich frage mich nur, ob das Enclosure dann völlig spinnt weil es eben keinen "Adminzugang" gewährleisten kann oder ob es das für den Moment garnicht merkt weil es HotPluggable ist ;-) ....

Nach diversem hin und her mit HP lief es darauf hinaus, dass das Sleeve einen weghat. ( Die OAs starten sich in unregelmäßigen Abständen neu ). Eine Erörterung des Fehlers ist an dieser Stelle aber unpassend... ich bitte also darum hier davon abzusehen. Also muss das eben getauscht werden :-). . Ich möchte nur wissen: Ist es möglich ein Sleeve mit BEIDEN OAs im laufenden Betrieb zu wechseln?

Könnte das Programm eventuell in der Kompatibilitätsansicht (rechtsklick auf entsprechendes Programm) für alle Benutzer mit Administratorenrechten ausgeführt werden? :-) -> rechtsklick aufs programm-> Kompatibilität -> "Einstellung für alle Benutzer ändern" -> Berechtigungsstufe-> Haken setzen