oernst

Hallo zusammen, wie in der Betreffzeile bereits angedeutet, versuche ich den Exchange 2010 über den Systems Center Operations Manager zu monitoren. OS: Windows Server 2008 R2 SP1 (auf allen Servern) Exchange: 2010 SP1 SCOM: Operations Manager 2012 SP1 Nachdem einige Probleme bereits behoben wurden, vermute ich die Wurzel des restlichen Übels an Einstellungen im Exchange, bzw. Berechtigungen. Via dem von Exchange 2010 mitgeliefertem Script "New-TestCasConnectivityUser.ps1" habe ich einen User extest_GUID erstellt. Dieser wird dann vom SCOM genutzt, um bestimmte Scripts laufen zu lassen. Nachdem ich endlos (u.a. im Technet) gesucht habe, hoffe ich, dass von euch vielleicht jemand bereits Erfahrungen mit dem SCOM und Exchange gemacht hat. Bei dem vom Exchange mitgelieferten Script erstellten User werden diverse Tests (z.B. "Test-OutlookConnectivity -Protocol:Http -TrustAnySSLCert:$true -MonitoringContext:$true") in der Exchange Shell ausgeführt. Über diesen User schlagen die Scripts allerdings mit dem netten Zusatz "Access Denied" fehl. Kennt vielleicht jemand das Szenario, oder hat bereits anderweitig mit dem extest_GUID User gearbeitet? Kerberos preauthentication ist im AD für den User deaktiviert (wird sonst alle 30 Sekunden gesperrt). Über entsprechende Anpassung von Berechtigungen konnte ich leider nix finden. Der Ansatz bzgl. Proxykonfiguration überprüfen fällt raus - es wird kein Proxy verwendet. Im Technet habe ich bereits von einem User gelesen, dass der MS Premier Support dazu rät, die Testscripts zu deaktivieren (Yeah, danke!) - allerdings büßt man hier deutlich Möglichkeiten zur Verfügbarkeitsüberwachung ein. Für jede Hilfe dankbar ;) **** edit: Im Security Log schlägt "Unknown user name or bad password." auf. Da es sich um einen Account handelt, bei dem automatisiert das Passwort geändert wird (Exchange Shell hat auch die Berechtigungen, gecheckt mit Test-ActiveSyncConnectivity -ResetTestAccountCredentials), ist das natürlich relativ schlecht... *** Gruß oernst

Oh sorry, hab das Subforum nicht gesehen... Habe leider auch nur die Infos, die ich da geschrieben hab :) Vermutlich Win7 Professional (hab ich bisher nur bei MSDNAA an der Uni gesehen). Aber das hilft schonmal weiter. Bzw. ihm nicht ;) Hatte ich mir aber schon gedacht. Danke erstmal! Gruß Örnst

Hallo an Alle! Ich habe eine kurze Frage zu dem Lizenzmodell bei Windows7. Ein Kumpel musste kurzfristig seinen Rechner installieren, hat dafür ein Installationsmedium aus dem Netz geladen (weiß nicht woher) und ohne Key installiert. In zwei/drei Tagen bekommt er von seiner Uni einen Key (MSDNAA-Programm). Nun meine Frage: Funktioniert die Key-Eingabe eines MSDNAA-Keys bei allen Win7 Installationsmedien? Bei XP war der Key-Algorithmus für OEM, Volume Lic. und MSDNAA/ Technet unterschiedlich und ein mixen nicht möglich. Bei Vista ging es dann angeblich, da alle Medien individuel lizenziert werden konnten. -> Win7? Wenn er jetzt alles installiert und in zwei Tagen von vorne anfangen muss, wäre das natürlich nicht so prickelnd :D Schonmal danke an alle Helfer ^^ Gruß Örnst

Hallo zusammen, ich denke ich habe den Fehler inzwischen gefunden. Obwohl die Execution-Policy auf den "speziellen" Servern auf "unrestricted" gestellt wurde, scheint er doch verzweifelt die in den Dateien vorhandene Signatur zu überprüfen. Da das Zertifikat domänenübergreifend (keine CA in der zweiten Domäne) verwendet wurde, habe ich zu Testzwecken zunächst "remotesigned" gewählt und die (alte) Signatur dringelassen. Allem Anschein nach hat das zu der 5-10 Sekunden Verzögerung geführt. Nachdem die Signatur entfern wurde, liefen die Skripts wieder direkt an. Schade, dass man vorher nirgendwo in PS, Logs oder Debugging die Signaturprüfung gesehen hat :) Gruß Örnst

hast du vielleicht die komplette VHD oder den inhalt der VHD blockbasiert kopiert? in diesen fällen kann es bei virtualisierungsplattformen (hyper-v, vmware, virtualbox, [...]) zu einem problem mit den guids kommen. beim kompletten kopieren einer vm fällt das eher auf, da der hypervisor in diesen fällen meistens alarm schlägt. guid probleme gibt es bei sowas übrigens nicht nur bei platten, sondern auch bei NICs und und und... gruß örnst -------------- zack - zu spät ;)

Um alle getrennt auf deine physikalischen Adapter zu verteilen - ja. So würde ich es machen, da du so deine Ressourcen vernünftig ausnutzt. Die letzten Posts waren ja eher Cluster-lastig :)

wieso machst du denn auch sowas bei einem RAS? ;) Würde einen eigenen DHCP-Bereich für die VPN-Clients erstellen und den RAS als DHCP-Relay diesen verteilen lassen. How to Use DHCP to Provide Routing and Remote Access Clients with Additional DHCP Options Ansonsten würde mir jetzt nur eine Scriptlösung einfallen, die erst die IP-Informationen ausliest und dann per NETSH deinen Vorstellungen entsprechende ändert... Gruß Örnst

Windows mail & doc Anlagen - WinBoard - Die Windows Community Sieht nach dem gleichen Problem aus :) Windows Mail hat anscheinend eine eigene Zuordnung der Programme mit Dateitypen.

Es wird wärmer :) Die Zuweisung ClusterIP<->Gruppeninhaber übernimmt der Clusterservice. Der DNS registriert nur die IP der Clustergruppe. IP-Adressen für die einzelnen virtuellen Switche zu verteilen ist nur notwendig, wenn dein Host auf die VM-Clients zugreifen muss. In dem Fall reicht allerdings eine Adresse aus dem jeweiligen Subnet aus (die Switche sind ja sowieso virtualisiert und Traffic geht über den Host). Die jeweiligen IP-Adressen müssen dem neuen virtuellen Adapter zugewiesen werden - der physikalische läuft "unkonfiguriert" im Hintergrund. Generell würde ich dir eine Schritt-für-Schritt-Anleitung empfehlen, wenn du noch nie einen Cluster von Grund auf gebaut hast. Hier ist sogar eine für Hyper-V :) Hyper-V: Using Hyper-V and Failover Clustering Der "Best Practices Analyzer" unter 2008/R2 hilft dir nach der Grundkonfiguration ebenfalls weiter :) Gruß Örnst

Achso - nein :) Jeder Host in deinem Clustersystem benötigt seinen eigenen Hostname & IP. Die Clustergruppe "Quorum" benötigt eine eigene IP. Sie wird dann nach außen hin publiziert und spiegelt den Inhaber der Gruppe wieder. Bsp.: Hostname a = server1 (ip 10.0.0.1) Hostname b = server2 (ip 10.0.0.2) clustername = cluster1 (ip 10.0.0.3) Je nachdem würde ein Mstsc auf "cluster1" den Remotedesktop desjenigen Servers geben, der die Clustergruppe mit dem Clusternamen "cluster1" beherbergt. Das Interconnect sollte nicht öffentlich erreichbar sein und hat demnach mit den geclusterten Anwendungen nichts zu tun.

Die Cluster-Ip-Adresse (virtuell) ist eine Ressource, die mit dem Netzwerknamen deines Clusters verbunden ist. Zusammen mit dem Quorum/ der Witness-Disk bilden sie eine Clustergruppe. Hier die Technetinformationen zu den Parametern: Specifying the Cluster Parameters: Networking and Communications; Server Clusters (MSCS)

Dedizierte Zuweisungen, um den Netzwerkverkehr einfach zu trennen. Optimale Performance, nicht optimale Verwaltbarkeit. Warum sollte er alle Verbindungen auf einer NIC laufen und den Rest vergammeln lassen? selbst der Support sagt, dass der Teamingtreiber höhere Fehleranfälligkeit hat (Chips/ FW, was auch immer). Clustering würde ich hierüber grundsätzlich nicht machen. Das mit dem Crossover seh ich ja noch ein. Aber bei zwei Servern (wie hier) sehe ich den Switch eher als Fehlerquelle. Wenn der (einzige) Gegenüber nicht erreichbar ist, wird es ihm auch herzlich egal sein, wenn der Adapter auf "not linked" steht. Könnte mir eher das Gegenteil vorstellen - wenn der Adapter down ist, wird er sofort versuchen, das Interlink übers Public zu machen?! Jopp, hat was :)

Hallo! Eine Netzwerkkarte würde ich generell nur als Interconnect verwenden - bestenfalls als direktes Crossover. Der Interlink hat einen automatischen Fallback auf das Public-Netzwerk, allerdings solltest du hierbei die Reihenfolge der NICs in den Systemeinstellungen beachten. Wenn du nicht mehr Maschinen als vorhandene NICs hast, empfiehlt sich eine dedizierte Zuweisung... Selbst wenn du mehrere virtuelle Netzwerkkarten auf einer physikalischen laufen lassen möchtest, kann ich persönlich nur von (Software) Teaming abraten. Die Erfahrung bezieht sich zwar nur auf HP-Server, aber sobald der Treiber nur den geringsten Fehler erkennt, schaltet er das komplette Team ab :) Gruß Örnst

Hi, welche iLo-Version hat denn das DL? Habe zwar hauptsächlich mit Bladeservern zu tun, aber die Proliants haben beim Starten das Bootmenu auf F11. DVD von deinem Rechner (Image oder PassThrough) kannst du über die iLo-Page auf zwei Arten einbinden: Internet Explorer (INTEGRATED Remote Console): Am oberen Bildschirmrand sollte eine Menüleiste erscheinen. Unter dem HDD-Symbol (Virtual-Media) kannst du die Optionen finden. Firefox o.ä. (Java Remote Console): Hier wird nur das Bild getunnelt. Im iLo gibt es einen gesonderten Punkt "Virtual Media" - hier kannst du per Virtual Media Applet ebenfalls Laufwerke/ Images einbinden. Die genannten Optionen sind für iLo2 - bei der alten Version ist es aber ähnlich. Gruß Örnst

Das würde ich so unterschreiben :) Es gibt eben neben dem normalen Alltagsbetrieb auch Fachkräfte, die sich auf solche Szenarien spezialisiert haben... Ob nun direkt von Microsoft oder anderweitig qualifizierte Techniker werden bestimmt kein Interesse haben, euch zu schaden. Gerade in Dingen wie z.Bsp. Berechtigungs- und Sicherheitskonzepten sollte man Leute zu sich rufen, die sich mit sowas langfristig beschäftigen. Der hätte bestimmt auch zu Dom-Adminrechten für den Help-Desk abgeraten :) Ich bin einer von mehreren Administratoren in meinem Betrieb. Da sich die Gesamtstruktur aber sehr weit ausgedehnt hat, gibt es eine klare Kompetenztrennung! Selbst wenn jemand gute Kenntnisse hat und googlen beherrscht, sollte man sich immer im Klaren sein, dass ein Mehraugen-Prinzip Fehler verhindert. Für viele Aufgaben sollte man sich entweder Spezialisten auf die eigene Gehaltsliste holen, oder Support von extern einkaufen. Von daher keine Scheu den Vorgesetzten klare Bedenken mitzuteilen... Wird auf Dauer eher dein Vorteil sein. Gruß Örnst

Kannst du das Gateway mit route change 0.0.0.0 mask 0.0.0.0 <<dein_eigentliches_GW>> denn abändern?

Hallo! Im DNS werden nur die dem Standort entsprechenden DCs per SRV-Eintrag im Standort gelistet. So wird dem Client an Hand seines Standortes der nächstgelegene (bestenfalls gleicher Standort) DC zugewiesen. Für Standorte ohne DC kann ein DC eines anderen Standortes explizit zugewiesen werden. Das ändert allerdings nur die SuchREIHENFOLGE für diesen Standort. Generell sollte bei korrekter Konfiguration (vor allem DNS und Netzwerk) ein Fallback auf andere DCs der Domäne möglich sein, falls der Standortangehörige nicht erreichbar ist. Ab NT 6.0 wird die Auswahl des Anmeldeservers standardmäßig per Zufallsprinzip betrieben, falls kein DC am Standort verfügbar ist. Frühere Versionen arbeiten mit Kosten, Prio und Gewichtung. Hier solltest du einige Informationen finden: http://blog.dikmenoglu.de/PermaLink,guid,ad2ea4b3-0374-4048-8b3d-43623c176328.aspx Vor allem eine Ausgabe über NSLookup via type SRV und "_ldap._tcp.dc._msdcs.<<DOMAIN>>" sollte dir alle verfügbaren DCs auflisten... Vielleicht helfen dir die Infos ja weiter :) Gruß Örnst

Hallo! Also den "Scansoftware"-DC könnt ihr OS-seitig nach Image, Systemrestore von einem anderen Gerät und HEX-Editor wohl getrost in die Tonne treten. Wurde zwar schonmal gefragt, aber hab keine Antwort von dir gelesen: WELCHE DCs??? ALLE untereinander? Nur der Problemfall mit den anderen??? In diesem Fall kannst du noch versuchen, ihn (in seinem äußerst angeschlagenen Zustand) zu de-promoten (aus DC mach Member) und hoffen, dass der Assistent das Metadata-Cleanup übernimmt - vermutlich aber eher nicht. FSMOs habt ihr hoffentlich auf "gesunden" DCs. Danach kannst du ja wieder einen Server frisch aufsetzen und ihn als DC promoten -> dieser sollte dann wieder normal bei der Replikation mitspielen, sofern ihr das AD nicht schon grundlegend beschädigt habt. Sollte es beim De-Promoten, bei der Übertragung der Masterrollen oder selbst nach der Prozedur zu stetigen Fehlern kommen, wirst du spätestens externe Hilfe in Anspruch nehmen müssen - da kann ich mich den anderen nur anschließen. Sieht leider düster aus... Ein DC ist kein Anwendungsserver! Gruß Örnst

nein, daran liegt es leider auch nicht... ich habe mit den grundeinstellungen, mit exportiertem profil und mir noprofile probiert :(

Hi, hab ich vergessen zu schreiben. Alle Versionen sind 2.0. Probiert hab ichs auf den 64-BIT Maschinen auch mit beiden (32/64 BIT) Powershell.exe. Die Build Versionen sind abhängig vom OS (6.0 oder 6.1 beim R2) - aber daran liegt es ja leider auch nicht :( Alle Maschinen laufen auf der Execution-Policy "remotesigned" und sehen das Script als Zone "Intranet" an... Zertfifikatsabfragen sind es also auch nicht... Für weitere Ideen bin ich sehr dankbar ^^ Gruß Örnst

Hallo zusammen, ich habe ein Problem, was evtl. auch noch schwierig nachzustellen ist. Zurzeit arbeiten wir an der Umstellung unserer Nagios-Scripts von VBS auf Powershell. Die Scripts funktionieren soweit auch - also daher alles ok. Die Powershell startet auch schnell genug. Das Problem ist, dass ein Script BEVOR es ausgeführt wird, erstmal 5-10 Sekunden stehen bleibt. Wenn die Powershell aufgeht, kann man direkt mit den ganzen CMDlets arbeiten und bekommt prompt auch Ergebnisse. Sobald man eine ".ps1" ausführen will, überlegt die PS anscheinend erst einmal ein paar Sekunden. Durch eine Stopwatch-Funktion kann ich die Ausführungszeit des Skripts selbst mit 60-70ms ausschließen. Jetzt wird es etwas tricky: Das Problem tritt nicht auf allen Servern auf! Egal ob 2008, R2, 32/64 Bit - es lässt sich nicht an einem System festmachen. Den Ursprung habe ich auch schon gefunden: im eventvwr werden bei einem Powershell-Script 10 Vorgänge protokolliert. Vom 9. auf den 10. Vorgang entsteht diese Verzögerung ("Zustand wurde von Available in Stop geändert", Modullebenszyklus - ID 400/403). Bei den meisten Servern braucht er von Schritt 9 auf 10 ca. 500ms - auf den Problemservern bis zu 10 Sekunden :confused: Gegoogelt etc. habe ich schon ohne Ende, aber noch kein brauchbares Ergebnis gefunden... HILFE! :) Gruß Örnst

Hallo zusammen! Wir haben aktuell ein Problem bei unserer AD Migration. Die Umstellung erfolgt von 2003 auf 2008 (Server OS, Funktionsebene bleibt erstmal 2003 pur). Das Problem ist, dass wir momentan noch NT4 Domänen im Einsatz haben und diese vorerst auch nicht ohne weiteres abschalten können. Diese NT4 Domänen sind per bidirektionaler Vertrauensstellung an unsere 2003 pur Domäne angebunden. Das funktionierte auch alles wunderbar, bis wir 2008er DCs in unsere Domäne aufgenommen haben. Jetzt schlägt die Authentifizierung zwischen den beiden Domänen fehl, sobald ein 2008er abgefragt wird. Vermutlich wegen der Kryptografie-Netlogon Dienste (siehe KB-Link unten). Das Workaround aus dem KB-Artikel hat bei uns leider nicht funktioniert. Wir würden gerne versuchen, der NT4 Domäne nur 1-2 Vertrauenspartner anzugeben (2003), um uns ein wenig Zeit zu verschaffen, bis wir die NT Domänen abschalten können. Hat hier jemand eine Idee? Bzw. einen weiteren Ansatz, die Vertrauensstellung auf 2008 anzubinden? Wir sind schon über die "Ausgewählte Authentifizierung" gestolpert, aber wir finden nirgendwo, ob nur von Member-Servern etc. die Rede ist, oder ob auch DCs spezifisch angegeben werden können. Diese müssten ja eigentlich als "Verbund" sofort zur Verfügung stehen(?). Stelle ich mir auch sehr aufwendig vor, eine Whitelist zu erstellen, wenn man andersrum nur EINEN Blacklist Eintrag für das 2008er OS hätte... The Net Logon service on Windows Server 2008 and on Windows Server 2008 R2 domain controllers does not allow the use of older cryptography algorithms that are compatible with Windows NT 4.0 by default PS: PDC-Em. ist ein 2003er DC. Für Lösungsansätze wäre ich sehr dankbar :) greetz Örnst

Wird der Laptop vllt. per ACL auf dem Gateway geblockt? Mach mal einen Portscan (z.B. mit nmap) auf den Gateway und auf etwas dahinter (z.Bsp. google.de - DNS geht ja laut deiner Aussage). Wie wärs denn mit einem flüchtigkeitsfehler: PROXY-Einstellungen??? vergleich das mal mit anderen Maschinen. in der CMD XP -> "proxycfg" Win7 -> "netsh winhttp show proxy"

Eine Alternative zu "dsadd" ist der befehl "NET USER /ADD %user% %pw% /yourdomain". Ist vllt. ein wenig einfacher zu handlen, falls du keine bestimmte OU ansprechen willst. "dsadd" bietet allerdings mehr Optionen. Ich nehme mal an, dass dein Chef kein Administrator ist, sonst würde er das selbst tun können. Wenn das so ist: nur Rechte zum Erstellen von Objekten im AD! Kein Domänenadmin! Das kann schnell schiefgehen... Auch wenns der Chef ist. greetz örnst

Hallo! Meines Wissens nach geht es wirklich nur mit L2TP per PSK oder Zertifikat. Dann bist du auch dank IPSec auf der sicheren Seite. PPTP macht eine reine Benutzerabfrage - bei sicherheitskritischen Sachen eher unangebracht. Je nach Szenarion wäre es vllt. ratsam, NAP (Network Access Protection) einzusetzen - damit könntest du nicht nur Domänenmitgliedschaft etc. abfragen, sondern auch, ob der Pattern des Antivirus o.ä. auf dem neuesten Stand ist. Ansonsten landen die "Einwähler" eben in einer Quarantänezone. In dieser Quarantänezone können Update-technische Kriterien nacherfüllt werden, Domänenmitgliedschaft etc. aber nicht. greetz örnst