LANIAC

Hallo ThorstenM, besten Dank für Deine Antwort. Den Task "Delete Aged..." hatten wir bereits angeschaut und korrigiert, den "Clear Install Flag...." jedoch noch nicht. Wir haben diesen nun auch angepasst und beobachten das System nun eine Weile. Gruss LANIAC

Hallo ThorstenM, wir dachten wohl fäschlicherweise, dass die Clients welche mit den Einstellungen "Internet only" installiert werden sich nicht mehr zwingend periodisch bei der Domäne melden müssen und deshalb dieses Phänomen mit "Client=NO" dadurch behoben würde. Welcher Maintenance Task wäre denn deiner Meinung nach für sotwas verantwortlich? Besten Dank für Deine hilfe. Gruss LANIAC

Hallo ThorstenM, wir haben alle unsere gemanagten Geräte mit den Einstellungen "Intra+Internet" ausgerollt, weil wir dachten, dass diese Geräte in regelmässigen Abständen wieder an der dazugehörigen Domäne sind. Da nun jedoch diese Geräte über einen sehr langen Zeitraum keinen Kontakt zur Domäne haben und eigentlich nur via Internet verwendet werden, haben wir das Problem, dass in der SCCM Konsole diese Geräte nach einer gewissen Zeit den Status "Client=NO" anzeigen. Aus diesem Grund möchten wir die Geräte die bereits mit einem SCCM Client ausgestattet sind nun auf "Internet only" umstellen, ohne dass wir wieder alle Geräte zurückrufen müssen. Wir haben auch bereits die Zeitdauer für das Synchronisieren des Computerkontokennwortes erhöht, jedoch war dieser Erfolg nur von kurzer Dauer, da es wie bereits erwähnt Geräte gibt, die eine sehr lange Zeit nicht mehr an der Domäne sind. Auch kann es nicht die Lösung sein diese Synchronisation auszuschalten oder dann den Zeitraum auf mehrere Jahre zu erhöhen. Ich hoffe dies erklärt unsere Situation ein wenig. Hätten wir von Anfang an gewusst, dass diese Geräte praktisch nur noch via Internet genutzt werden, hätten wir natürlich schon von Anfang an die Clients mit anderen Einstellungen installiert. Wir möchten nun lediglich wissen, ob es im Nachhinein möglich ist, dies Remote zu ändern, ohne dass wir sämtliche Geräte wieder einziehen müssen. Besten Dank schon jetzt für die Hilfe von Euch. Gruss LANIAC

Hallo robbery, die zwei wichtigsten Gründe für einen RODC sind meiner Meinung nach die beiden folgenden: - Es sind nicht genügend gesicherte Räumlichkeiten vorhanden um einen DC vor unbefugtem Zugriff zu schützen - Es sind keine lokalen Administratoren in den Aussenstellen vorhanden Sollte als bei Eurer Umgebung beides gewährleistet sein, würde ich empfehlen einen DC anstelle eines RODC's zu platzieren. Sollte jedoch eine der beiden obigen Fälle nicht zutreffen, würde dies für einen RODC sprechen. Hoffe ein wenig geholfen zu haben. Gruss LANIAC

Hallo zusammen, nach Anleitung des folgenden Microsoft KB Artikels, kann man beim ccmsetup.exe mittels einem bestimmten Parameter während der Installation des SCCM Clients diesen als "Internet-Only" konfigurieren. How to Configure Configuration Manager Client Computers for Internet-Only Management Nun zu meiner Frage: Falls nun bereits schon eine grosse Anzahl an SCCM Clients installiert wurde, gibt es eine Möglichkeit diese im Nachhinein so zu konfigurieren, dass diese als "Internet-Only" Clients erkannt werden? Oder muss man hier tatsächlich sämtliche SCCM Clients deinstallieren und anschliessend mit dem obigen Parameter neu installieren? Besten Dank für Eure Ideen und Vorschläge bereits im Voraus. Gruss LANIAC

Ich denke so langsam aber sicher kommt etwas Licht ins dunkle. Besten Dank für all Eure Antworten! Folgender Auschnitt aus dem TechNet erklärt einiges: A scan request is passed to the Windows Update Agent (WUA). The WUA then connects to the WSUS server location listed in the local policy, retrieves the software updates metadata that has been synchronized on the WSUS server, and scans the client computer for the updates. A component of the Software Updates Client Agent detects that the scan for compliance has completed, and it creates state messages for each software update that had a change in compliance state since the last scan. The state messages are sent to the management point in bulk every 15 minutes. The management point then forwards the state messages to the site server, where the state messages are inserted into the site server database. Ich war bis anhin der Meinung, dass genau dies der ConfigMgr Client auf den jeweiligen Clients übernimmt. Das aber der "normale" WUA involviert ist, war mir nicht bewusst. Ich denke diese Update Scanfunktion hätte durchaus auch direkt in den ConfigMgr Client intergriert werden können aber da wurde bei Microsoft wohl gedacht wieso nochmals neu erfinden wenn schon vorhanden. Dieses ganze WSUS/SUP Konstrukt scheint mir ein wenig gebastelt und ich hätte eigentlich etwas aus einem Guss erwartet. Vielleicht sind jedoch unsere Ansprüche zu hoch. Was meint Ihr dazu? Findet Ihr dieses "Konstrukt" durchdacht? Besten Dank nochmals für Eure Hilfe Gruss LANIAC

@TorstenM Besten Dank für deine Antwort. Ich habe mir das erwähnte Technet Dokument ebenfalls schon angeschaut und bin einfach nach wie vor verwundert, weshalb dann ein "Fall 33" erwähnt wird: 33. Software Update Point -- > WSUS Synchronization Server Description UDP TCP Hypertext Transfer Protocol (HTTP) -- 80 or 8530 (See note 4, Windows Server Update Services) Secure Hypertext Transfer Protocol (HTTPS) -- 443 or 8531 (See note 4, Windows Server Update Services) Was ist dann ein "WSUS sync" Server? Ist dies nicht dasselbe wie der WSUS? Und wenn nun der WSUS und der SUP ja sowieso auf dem selben Server sind, weshalb müssen diese beiden dann via TCP/IP kommunizieren? Ich frage mich auch, weshalb in diesem Technet Artikel der SUP und der WSUS als zwei verschiedene Server abgebildet werden, wenn ja diese beiden sowieso zusammengehören? Ich habe, als die Clients mit dem Internet verbunden waren lediglich die bereits verfügbaren Updates installiert. Es scheint so, als hätte er den Scan Zyklus abschliessen können, während der Rechner kurzzeitig in der DMZ und nicht im Internet war. Irgendwie berfürchte ich, dass es lediglich eine Möglichkeit gibt den Port 8531 auf der Firewall nicht zu öffnen. Man müsste den WSUS auf einem zweiten Server installieren und dann die "Default Website" welche auf Port 80/443 läuft einrichten. Besten Dank nochmals für Eure Antworten. Gruss LANIAC

@WSUSPraxis wie bereits erwähnt gebe ich bei Unklarheiten zum Aufbau gerne weitere Details bekannt. Mein Problem besteht darin, dass ich nicht verstehe, weshalb Clients die sich vom Internet auf den SUP verbinden möchten dies via Port 8531 versuchen. Mir ist schon klar, dass der WSUS auf den Ports 8530/8531 läuft, wieso nun aber sich die Clients direkt mit dem WSUS verbinden möchten verstehe ich nicht. Weshalb muss sich denn das gesamte SCCM-System mit dem WSUS synchronisieren, wenn im nachhinein die Clients dann sich wieder direkt auf den WSUS verbinden? @TorstenM Da wie erwähnt alle Komponenten/Rollen auf dem selben System installiert wurden, mussten wir logischerweise eine "Custom Website" für den WSUS auf den Ports 8530/8531 einrichten weil die "Default Website" welche ja auf den Ports 80/443 läuft bereits für die "Primary Site" des SCCM-Systems gebraucht wurde. Ich sehe bei dieser Konfiguration keinen Grund, weshalb sich die Clients direkt mit dem WSUS in Verbindung setzen müssen ausser dies sei "by Design" so gewünscht. Ich hoffe Ihr stimmt mir zu, dass man so nur unnötigerweise einen weiteren Port auf der Firewall öffnen muss. Komischerweise kann ich dann den erwähnten Eintrag in der lokalen Richtlinie des Clients so anpassen, dass nicht mehr versucht wird die Updates direkt vom WSUS auf Port 8531 zu holen, sondern nun via 443. Ich habe nun mehrmals getestet, ob die Updates auf die Clients übertragen werden nachdem ich den Port von 8531 auf 443 (in der lokalen Richtlinie) geändert habe und siehe da, dies funktionierte Einwandfrei. Dieses Verhalten verwirrt mich nun, da es scheint, als sei es tatsächlich nicht nötig die Clients auf den Port 8531 zeigen zu lassen. Besten Dank für Eure Antworten.

Hallo zusammen, wir haben in unserer DMZ ein SCCM-System aufgebaut wo sämtliche Komponenten/Rollen auf einem einzelnen Server installiert sind. Dieses SCCM-System soll nun Clients in der DMZ sowie direkt vom Internet her bedienen können. Prinzipiell läuft das System einwandfrei bis auf ein kleines Problem/Unklarheit punkt "Software Update Point" in Zusammenarbeit mit dem "WSUS". Wenn wir nun Software Updates an Clients in der DMZ verteilen klappt dies ohne Probleme. Wenn wir nun aber Software Updates an unsere Clients im Internet verteilen wollen klappt dies nicht. Es wird zwar auf diesen Clients gemeldet, dass Updates verfügbar sind, diese können aber nicht heruntergeladen werden. Den Grund für dieses Verhalten haben wir bereits gefunden. Das SCCM System trägt in der lokalen Richtlinie des Clients fälschlicherweise unter "Specify intranet Microsoft update service location" zwar den korrekten SUP ein, jedoch mit der Portnummer 8531 anstelle von 443. Die Folge daraus ist, dass sich diese Clients direkt mit dem WSUS, welcher auf Port 8531 (SSL) läuft verbinden möchten anstelle direkt mit dem SUP. Da wir jedoch auf unserer Firewall diesen Port (8531) nicht öffnen können, müssen wir sicherstellen, dass die Clients auf den SUP und Port 443 verwiesen werden. Natürlich können wir dies mit einer Gruppenrichtlinie in welcher dieser SUP mit korrektem Port explizit angegeben wird lösen, wir fragen uns jedoch wieso dieser falsche Port überhaupt in die lokale Richtlinie eingetragen wird. Hat jemand von Euch Erfahrung mit einem SCCM-System wo alle Rollen auf einem einzelnen Server laufen? Kann es sein, dass das beschriebene Verhalten damit zusammenhängt? Haben wir eventuell etwas übersehen und falsch konfiguriert? Noch ein paar Eckdaten des Systems: - Windows 2003 Server mit SP2 - Microsoft SQL Server 2005 mit SP3 - SCCM 2007 R2 - Die Site läuft im Native Mode Ich bin für jeden Hinweis zu diesem Problem enorm dankbar und gebe gerne auch weitere Details des Systems preis, falls dies gewünscht ist. Besten Dank schon im Voraus nur schon fürs Lesen von diesem Beitrag. PS: Bitte hinterfragt nicht weshalb die Clients in der DMZ sind und weshalb alles auf einem System installiert werden soll. Mir ist durchaus klar, dass es sich hierbei nicht um ein "schönes" Szenario handelt, sondern Gewisse Sachen aus der Not entstanden sind. Also bitte keine Kommentare wie "Was machen denn eure Clients in der DMZ?" - Das ganze hat mehr oder weniger schon seinen Grund. Gruss LANIAC

Hallo Baba, ich würde wie es dongle vorschlägt mit PGP arbeiten, da du somit eine strikte Trennung von deinem Active Directory und den verschlüsselten Daten erhälst. Dies ist auch die einzige realisierbare Möglichkeit, die es Administratoren verhindert die Daten einzusehen oder deren Besitz zu übernehmen. Die GF würde ich informieren, dass beim Verlust eines Passwortes du keine Möglichkeiten mehr besitzt die Daten wiederherzustellen. Durch diese Massnahme lässt du dein Active Directory unberührt, so dass beim Verlust eines Passwortes nicht unvorhersehbare Probleme auftauchen können und die GF sollte auch zufrieden sein..... Gruss LANIAC

@CoolAce ....was soll das....???? dann könnte er sich ja auch selbst als User hinzufügen....... und was soll der Satz: "kleiner Nachteil sollte halt sein Zertifikat sichern" steckt da irgendeine vernünftige Aussage drin? Gruss LANIAC

PS: noch effizienter wird die ganze Sache wenn du zusätzlich noch einen DNS-Server installierst, weil du ja Windows 2000 im Einsatz hast und die Betriebssysteme ab Windows 2000 DNS im Gegensatz WINS (bald abgelöst aber immer noch nicht ganz) als primären Namensäuflösungsdienst verwenden. Jedoch ist DNS etwas komplizierter in der Konfiguration als WINS. Gruss und viel Erfolg LANIAC

.....wenn du jedoch ohne grosse IP-Adressänderungen alle deine Rechner in der Netzwerkumgebung sehen willst, kommst du um einen WINS-Server nicht herum weil: ohne einen WINS-Server in deinem Netzwerk, welches ja aus verschiedenen Subnetzen besteht (193.xxx und 200.xxx), die Hosts ihre Namen und derjenige der Arbeitsgruppe mit Broadcasts (alle Hosts "schreien wie wild aufs Netzwerk los") auflösen müssen. Da jedoch dein Netzwerk aus mehreren Subnetzen mit Routern "irgendwo" dazwischen besteht und Router keine Broadcast weiterleiten, werden die Hosts im Subnetz 1 diejenigen von Subnetz 2 und umgekehrt nicht sehen. also installierst du als erstes am besten einen WINS-Server. Du musst nach der Installation vorerst nichts spezielles konfigurieren, einzige Bedingung ist, dass der Server eine feste IP-Adresse besitzt. Danach musst du noch die IP-Adresse dieses WINS-Servers bei jedem von deinen Hosts auf der ensprechenden Registerkarte in den TCP/IP-Eigenschaften eintragen. Anschliessend sollten deine Hosts ihre Namen und die Arbeitsgruppenzugehörigkeit beim WINS-Server registrieren können und somit es sich ermöglichen sich gegenseitig zu finden. Gruss LANIAC Gruss

hallo torrid, kannst nicht versuchen etwas genauer zu erklären, wie denn nun "deine" Router konfiguriert sind (also vor allem welcher Router mit welchen IP-Adressen hängt an welchem Netzwerk)? Wieso sollte "dein" Router mit einem anderen nicht kompatibel sein? Wie sieht es nun mit dem DNS-Server (194.xxx) aus? Ist dies euer eigener DNS-Server oder derjenige des Providers. Sorry für die unendliche Fragerei aber ich muss versuchen mir irgendwie ein Bild deiner Konstellation zu machen.....Netzwerke können ja bekanntlich sehr kompliziert sein....aber das hast sicher auch schon selbst bemerkt...... ps: ich würde Gelegentlich die Geschäftsleitung darüber informieren, dass "euer" Netzwerk eigentlich nicht mehr den heutigen Standards und Sicherheitsanforderungen entspricht. Eine Änderung der gesammten IP-Adressierung würde zudem auch die Administartion vereinfachen, die ja jetzt im Moment doch ein wenig undurchsichtig ist. Zudem würde ich noch erwähnen, dass durch weniger "öffentliche" IP-Adressen widerkehrende Kosten gespart werden können (in meiner Firma erreiche ich meistens nur mein Ziel, wenn ich die Einsparung von Kosten aufzeigen kann). Ich hoffe du hast nicht das Gefühl ich will dir den "Schwarzen Peter" in die Schuhe schieben.....mir ist es schon bewusst, dass du dieses Netzwerk nicht aussuchen konntest. Gruss LANIAC

für das korrekte funktionieren von SMTP müssen ja auf dem DNS-Server MX-Einträge gemacht werden, so dass die Mails auch ans Richtige Ort gelangen........hast du solche MX-Einträge..? was für einen DNS-Service hast du bei deinem Provider (gar keiner, primärer oder sekundärer)? Gruss LANIAC