Wolke2k4

Hallo zusammen, das sind meiner ersten Schritte mit Hyper-V und gleich stoße ich auf ein hoffentlich triviales Problem, zu dem ich im Netz aber aus mir nicht erfindlichen Gründen keine Ursache finden kann. Ich wollte auf einem W2K8R2 über Hyper-V einen virtuellen W2K8R2 bereitstellen. Leider zeigt mir das Setup der virtuellen Maschine an, dass die virtuelle Festplatte angeblich offline geschaltet sei. Habe schon einige Spielerein mit der virtuellen HD durch aber ohne Erfolg. Wo liegt der Fehler? Gruß Wolke

Hallo, folgendes Problem unter Windows 7 und Windows Server 2008 R2 (Terminal Services): Wenn man Bilder Drucken möchte geht der Druckdialog "Bilder drucken" auf. Über diesen Dialog wird logischerweise auch auf die Druckereinstellungen zugegriffen. Das Problem ist, dass die Druckereigenschaften in diesem Dialog nicht den Standarddruckeingeschaften entsprechen. Das Problem ist insofern ungünstig, da bspw. Kostenstelleneinstellungen hier nicht übernommen werden. Das Gleiche gilt für Farbeinstellungen Gleicher Effekt beim Druckdialog aus Outlook (2003) heraus. Hier verhält sich das System wie zuvor beschrieben und ignoriert die Standardruckereigenschaften. Hat jemand eine Idee, wie ich dem System beibringen kann die Eigenschaften auch beim Bild- und Outlook Druck zu übernehmen? Gruß Wolke

Danke für die Antworten, das Problem ist gelöst. Mein Vorgehen wie folgt: - Alle Server und Clients runterfahren - Sicherung beider DCs mittels Image - Registrykey Allow Replication With Divergent and Corrupt Partner nach Event ID 2042: It has been too long since this machine replicated: Active Directory erstellen - Server booten, Replikation schaut gut aus, Registrykey entfernen - Server erneut booten - Server die Nacht über alleine laufen lassen, Kontrolle am Morgen --> AD wieder ok, keine Replikationsfehler Das AD war hier wohl nicht so defekt wie es den Anschein gemacht hat. Wäre das in die Hose gegangen hätten wir die Images zurückspielen lassen und MS Support kontaktiert.

Hallo, ich benötige Hilfe zur folgenden Problemstellung: 2x W2K3 DCs: 1x mit SP2 1x ohne SP Der DC mit den FSMO Rollen (der mit SP2) bringt im Eventlog folgende Meldungen: Ereignistyp: Fehler Ereignisquelle: NTDS Replication Ereigniskategorie: Replikation Ereigniskennung: 2042 Datum: 25.09.2010 Zeit: 15:31:47 Benutzer: NT-AUTORITÄT\ANONYMOUS-ANMELDUNG Computer: DC1 Beschreibung: Es ist zu lange her, dass dieser Computer zuletzt mit dem genannten Quellcomputer repliziert hat. Die Zeit zwischen den Replikationen mit dieser Quelle hat die Tombstone-Ablaufzeit überschritten. Die Replikation mit dieser Quelle wurde beendet. Der Grund dafür, dass das Fortsetzen der Replikation nicht zugelassen wird, ist, dass die Sicht der beiden Computer in Bezug auf gelöschte Objekte sich nun ggf. unterscheidet. Der Quellcomputer hat ggf. noch Kopien von Objekten, die auf diesem Computer gelöscht (und in die Sammlung veralteter Objekte aufgenommen) wurden. Würde der Replikation zugelassen, könnte der Quellcomputer Objekte zurückgeben, die bereits gelöscht wurden. Zeitpunkt der letzten erfolgreichen Replikation: 2009-04-15 15:13:09 Aufrufkennung der Quelle: 062cf6c8-f6b8-062c-0100-000000000000 Name der Quelle: cccce171-bdfc-4e36-9779-1e0728ae4075._msdcs.name1.name2.net Tombstone-Ablaufzeit (Tage): 60 Der Replikationsvorgang ist fehlgeschlagen. Benutzeraktion: Ermitteln Sie, welcher der beiden Computer von der Gesamtstruktur getrennt wurde und nun veraltet ist. Sie haben drei Möglichkeiten: 1. Stufen Sie den/die Computer herunter, die getrennt wurden, oder installieren Sie ihn/sie neu. 2. Verwenden Sie das Tool "repadmin /removelingeringobjects", um inkonsistent gelöschte Objekte zu entfernen, und setzenn Sie dann die Replikation fort. 3. Setzen Sie die Replikation fort. Möglicherweise werden inkonsistent gelöschte Objekte eingeführt. Sie können die Replikation fortsetzen, indem Sie den folgenden Registrierungsschlüssel verwenden. Es wird empfohlen, zur Wiederherstellung des Schutzes den Schlüssel zu entfernen, sobald das System ein Mal repliziert hat. Registrierungsschlüssel: HKLM\System\CurrentControlSet\Services\nTDS\Parameters\Allow Replication With Divergent and Corrupt Partner Sowie davor noch die Ereignisse 1864 und 2092. Auf dem zweiten DC (der ohne SP) gibt es ähnliche aber nicht die gleichen Fehlermeldungen. Dazu die EventIDs 1837, 1586 und 1837 Nach ein wenig googeln bin ich offenbar nicht der Einzige mit solchen Problemen. Eine Lösungsfindung gab es bspw. hier mit Verweis auf die beiden Links (1. Link, 2. Link) Mein Problem ist jetzt, dass ich noch nicht so recht verstehe, was da gemeint ist. Wie z.B. finde ich heraus, welcher DC der "gute" DC ist? Und welche Lösung soll ich letztendlich anwenden? Ich hoffe, das mir jemand weiterhelfen kann. Gruß Wolke

Super danke für die Info. Das ist doch was ich gesucht habe. Mir ist nur noch nicht ganz klar, wie der Server dann über SMTP verschickt, wenn das über DNS gehen soll. Der nächste Smart Host müsste die Mails vom Exchange dann wiederum akzeptieren oder?

Hallo, folgendes Szenario. Ein Exchange 2007 Server wird öffentlicher Mailserver. Vor dem Mailserver steht eine Appliance, die den Mailverkehr nochmals auf SPAM und Viren filtert. Die Appliance ist transparent zwischen den Kommunikationsweg geschaltet. Der Exchange Server soll als MX im DNS im Internet registriert sein (mit einer IP die auf einem Router aufläuft, der dann den SMTP Port forwarded) und dementsprechend Mails annehmen können. Was muss ich am Exchange einstellen, damit dieser Mails vom Internet annimmt und darüber verschickt? Habe diesen Artikel gefunden, bin mir aber nicht sicher ob das zutreffend ist.

So wie sich das mir darstellt (habe es gerade getestet) handelt es sich um einen Bug im Office 2007. Ein Rechner mit Office 2010 kann nämlich problemlos speichern... Man hat zwar das Problem mit den temporären Dateien aber gut dafür lässt sich vielleicht noch eine Lösung finden. Das Problem mit Office 2007 bleibt weiterhin. Deswegen die Rechner umzustellen scheint etwas viel Overkill.

Ich glaube es ist müssig über die Auswirkungen bestimmter Aktionen der User zu diskutieren. Sinn meines Threads ist auch nicht dieses zum Thema zu machen sondern das eigentliche Problem zu beheben. Wir haben hier den Fakt, dass bei nicht aktivierter NTFS Berechtigung "Unterordner und Dateien löschen" keine MS Office Dateien (2007) mit vorgenommenen Änderungen in der selben Datei abgespeichert werden können. Alles andere ist für mich erst mal nebensächlich und uninteressant.

Ist es wirklich so ungewöhnlich? Jeder Admin hat es doch sicher schon mehrfach selber erlebt, dass User "aus Versehen" Ordner verschoben und sich später mit: "Meine Daten sind weg!!!!" gemeldet haben. Es geht hier primär darum sicherzustellen, dass niemand Dateien und Ordner selber löscht. Natürlich habe ich in den erweiterten Berechtigungen nachgeschaut. Geht ja auch nur dort, weil nur dort das Löschen Recht verweigert werden kann.

Würde ich auch so sehen. Ich glaube nicht, dass es meine Aufgabe ist beim Office noch zu schauen, welche Sachen im Hintergrund laufen, damit ich die Dateiberechtigungen von Windows erfolgreich umsetzen kann. Mich wundert auch, dass dieses Thema bisher offenbar kaum große Beachtung findet. Wahrscheinlich deswegen, weil viele (so wie ich bisher auch) nach dem "Alles oder Nichts" Prinzip Berechtigungen vergeben... Wer ist denn hier auch auf das Problem gestoßen? Gibt es überhaupt eine Lösung dafür?

Hallo Zusammen, folgendes Szenario. Netzlaufwerk für X Nutzer mit verschiedenen Ordnern. In bestimmten Ordnern sollen die Nutzer nicht das Recht haben Dateien und Ordner zu löschen. Die Logik gebietet, dass ich in den NTFS Berechtigungen die beiden Löschen Rechte entferne. - Der Test ergibt, dass ich die Dateien nicht löschen kann. --> OK so ist's gewollt - Neue Ordner und Dokumente kopieren und erstellen kann der User zwar prinzipiell aber diese umbenennen geht nicht. Es geht erst mit dem Recht "Unterordner und Dateien löschen" --> Was hat das dieses Recht mit dem Umbenennen von Ordnern und Dateien zu tun? - Lustig wird es, wenn Office Dateien geöffnet und bearbeitet werden. Die Änderungen lassen sich nicht abspeichern, ich müsste die Datei neu speichern. MSPaint und Notepad können aber sehr wohl mit Änderungen versehen werden. --> ?!?!?!? :confused: Hierzu die folgenden Hinweise aus dem Netz: Hinweis 1 Hinweis 2 Nun muss ich meine Vorstellungen von den Windows Berechtigungen wohl komplett umkrempeln und mir eingestehen, dass früher mit Vollzugriff alles viel einfacher war? Gibt es hierfür keine Lösung? Ich will doch einfach nur, dass die User alles dürfen außer Dateien und Ordner selbstständig löschen!

Danke!

Hallo, wie man in verschiedenen Quellen nachlesen kann, ist es nicht ungewöhnlich, dass der Winsxs Ordner bei Vista und Co. anwächst. Nun habe ich das Problem bei einem W2K8 Server. Der Ordner ist ca. 10GB groß Das Problem: Die vsp1cln.exe gibt es auf dem System nicht, der Ordner lässt sich somit nicht verkleinern. Mircosofts KB schweigt sich darüber auch aus. Hat jemand schon mal ein gleiches Problem unter W2K8 gehabt und lösen können? Gruß Wolke

Hallo, folgendes Problem: 1x W2K Server mit Exchange 2000 SP3 1x W2K8R2 Server mit Exchange 2007 SP1 kürzlich dazu installiert. W2K8R2 und Ex2007 SP1 in der jetzigen Konstallation sind ja nicht offiziell freigegeben. Daten auf dem Ex 2007 liegen noch keine (weder öffentliche Ordner repliziert noch Postfächer verschoben). Mein Vorhaben: Ex2007 deinstallieren, das System in neu auf W2K8 installieren. Meine Frage: Kann ich den Ex2007 einfach so aus der Domain deinstallieren oder zerschieße ich mir damit ggf. die 2000 Exchange Organisation? Gruß Wolke

Mit "Absolut korrekt" meinst Du jetzt nicht, dass ich das falsch sehe richtig? :D Weißt Du, ob der Inetorg Fix auf dem W2K noch laufen muss, bevor der W2K8 DC in die Domain integriert wird?

Deswegen ja das von mir beschriebene Vorgehen den neuen Server zunächst als W2K8 DC in die Domain zu integrieren. Während dieses Steps würde das AD bereits auf W2K8 Schema angehoben, die Domain W2K8 fähig gemacht. Die Voraussetzungen für Exchange wären dann doch gegeben oder sehe ich das falsch? Entscheidung des Kunden. Na ja kaputt gehen wird ja wohl nichts dabei...

Hallo, ich darf demnächst einen Exchange 2000 Server auf 2007 "wechseln". Im Netz gibt es ja einiges zu finden. Was mir noch nicht ganz klar ist sind ein paar Detailfragen, deren Antwort ich bisher noch nicht gefunden habe bzw. die sich mir aus den Artikeln nicht ganz ergeben. Ich beschreibe kurz das Szenario: 1x Exchange 2000 auf einem W2K DC, es ist der einzige DC! In das Netz soll ein Exchange 2007 installiert werden, alle relevanten Exchange 2000 Daten sollen übernommen werden. Mein Vorhaben sieht wie folgt aus: 1x neue Serverhardware mit Windows Server 2008 64Bit + oben drauf Exchange 2007 in die vorhandene Exchange 2000 Organisation installieren, Daten rüberziehen, fertig. Jetzt zu den offenen Fragen: 1. In den meisten How To's wird von einem W2K3 AD und Schema ausgegangen. In meinem Fall müsste ich AD und Schema von W2K auf W2K8 hochziehen. Ich würde bzw. müsste dies auch als erstes tun (noch vor Exchange). Besteht beim Aktualisieren des 2K ADs auf W2K8 noch die Notwendigkeit Rücksicht auf Inetorgpersonprevent zu nehmen? Gibt es sowas hier überhaupt noch (so wie beim Wechsel von W2K AD mit Exchange auf W2K3)? 2. Nimmt die Setuproutine des Ex2k7 automatisch die notwendigen Anpassung des 2000-er ADs und Schemas vor, ohne das ich dies vorher von Hand über die CMD machen muss oder muss ich in jedem Fall mit "Setup.com /PrepareLeagaxyExchangePermissions" usw. "manuell" durchführen? Die Kurzbeschreibung meiner Vorgehensweise hatte ich mir wie folgt gedacht: 1. Vorhandene W2K Domain auf Hinzufügen eines W2K8 DCs vorbereiten (adprep/forestprep, adprep/domainprep usw.) 2. neuen W2K8 mit dcpromo in die W2K8 Domain aufnehmen. FSMO Rollen auf den W2K8 Server verschieben, GC auf den W2K8 verschieben. 3. Exchange auf W2K8 installieren. 4. Postfächer und Public Folder übernehmen 5. Anpassung der Exchange Organisation 6. Entfernen des 2K Exchange aus der Organisation Gruß Wolke

Gekauft habe ich mir vor einer halben Ewigkeit dieses Buch. Sehr weit gekommen bin ich aber bisher nicht. Mein Problem ist leider auch die Zeit, von der ich nicht so viel habe. Aber Ich finde die Thematik trotzdem interessant und wichtig, wollte also erst mal hier einen Erfahrungsaustausch starten. Manchmal relativieren sich die Dinge, wenn man Meinungen und Erfahrungen von anderen liest/hört. Aber hier scheint es ja leider sehr dünn an Erfahrungen "besidelt"... Ansonsten gibt es haufenweise Bücher. Da hier aber offenbar niemand aus eigener Erfahrung eines empfehlen kann oder gar von eigenen IPv6 Erfahrungen zu berichten weiß, wird es schwer aus der großen Auswahl was brauchbares zu finden.

Also meine Überlegungen gehen derzeit dahin das Kundennetz umzustellen, weil es perspktivisch die sauberste Lösung ist. Das natten würde auch gehen, war bereits mein Gedanke. Ich habe dazu Supportteams von zwei Herstellern kontaktiert. Beide meinten, dass es so nicht geht, es müsse zwingend ein Router am WAN Standort aufgestellt werden. Über diesen haben wir jedoch keine Handhabe. Ich benötige also eine Lösung, die sich ausschließlich im Kundennetz abspielt. Kennt jemand relativ günstige Router, die für das Szenario geeignet wären?

Prinzipiell hast Du schon Recht. Deiner Aussage zu v6 halte ich aber entgegen, dass auch heute wohl kaum ein Unternehmen ein Class A von v4 wirklich effektiv ausnutzt (sozusagen vom Adressspace benötigt). Aber mal im Ernst. Weißt Du, ob und wie einfach eine Anbindung Deines v4 Netzes später an ein komplett umgestelltes v6 Internet funktioniert? Oder was wenn Services im Internet nur noch über IPv6 erreichbar sind und Du mit einmal vor dem Problem stehst auf diese zugreifen zu müssen. Weißt Du, ob Dein Unternehmen nicht irgendwann zwangsläufig auf die Notwendigkeit stößt v6 nutzen zu müssen? Nicht aufgrunde von Adressknappheit sondern aus anderen Dir und uns IPv6 Rookies jetzt nicht bekannten/vorhersehbaren Gründen. Mag sein, dass es für die Admins die nur ein Netz (ihr Netz) betreuen wenig Handlungsbedarf gibt. Schließlich kann man ein kleines bis mittleres Netzwerk kurz bis mittelfristig an neue Anforderungen anpassen und ggf. umstellen. Wir betreuen sehr viele Kunden. Das heißt ich muss mich nicht nur mit einem Netz sondern mit sehr viel verschiedenen auseinandersetzen. Klar wird der Hammer nicht um 12 auf den Tisch knallen und man wird sehr wahrscheinlich auch nicht in den Newsmeldung einschlägiger Seiten Schlagzeilen wie "Morgen muss Ihr Netzwerk IPv6 only sein!" finden. Trotzdem finde ich eine Auseinandersetzung mit dem Thema angebracht. Wenngleich eine interne Umstellung mittel bis langfristig nicht notwendig sein wird, wird dennoch die Notwendigkeit entstehen das interne Netz für die Kommunikation mit v6 anzupassen. Früher waren die Leute auch so naiv und dachten: WOW 400MB Festplatte, die bekomme ich nie im Leben voll!!!! Heute ist mein 8GB Stick ein altes Modell und ich muss sehen, wo ich Platz sparen kann. Das sich zu diesem Thema nicht viele Leute melden überrascht mich schon ein wenig. Die Frage, ob jemand sein Netz schon auf IPv6 umgestellt hat dürfte damit wohl in den Weiten des Internets verhallen... Wahrscheinlich liegt es einfach nur an der simplen Tatsache, dass wir, wie immer, jeden Tag mit wichtigeren Problemen zu kämpfen haben. IPv6 ist offenbar noch nicht genug "Must have" und sondern zu viel "Hex". Interessant in dem Zusammenhang diese Quellen: Quelle 1 Quelle 2 --> hab ich mir noch nicht näher angeschaut Vielleicht bringen sich noch ein paar Interessierte in das Thema ein...

Da gebe ich Dir prinzipiell recht. Der Umstand, dass man bei dem ganzen Lizenzrecht (nicht nur auf MS bezogen) Fehler begeht, die sich aufgrund der Komplexität zwangsläufig einschleichen ist ein echtes Problem. Dies könnte man nur duch technische Mechanismen wie es bspw. bei der Terminal Server Lizenzierung (per Device) eineindeutig ist lösen. Da gibt es einfach keinen Spielraum für Interpretationen (die sowohl Dr. Melzer als auch ich hier wiedergeben). Jedoch wäre dies zu erörtern nicht Gegenstand dieses Topics...

Schade, dass Du zu meinen Ausführungen keine sachlichen Kommentare Beitragen kannst. Statt sachlich auf meine Argumente (die nun mal offensichtlich nicht von der Hand zu weisen sind) zu antworten kommt ein sarkastischer Kommentar. Hat sich nicht viel geändert hier... schade.

Die sich hier auftuenden Grauzonen pauschal mit Aussagen wie: jedes Gerät muss eine Office Lizenz besitzen (bei angenommerner Office Nutzung über Terminal Server) halte ich für äußerst wackelig, da selbst Microsoft zu den oben genannten Szenarien keine eineindeutige Stellung bezieht (weder im White Paper noch in den Lizenzbestimmungen). Hier noch zwei Quotes aus dem White Paper. Since Microsoft Office is licensed through a device-based licensing model only, each desktop that is used to access Microsoft Office using Terminal Services must have a separate Microsoft Office license dedicated to it. Licenses for Microsoft Office cannot be shared across desktops to support concurrent use. Furthermore, with the 2007 release, generally only licenses obtained through Volume Licensing can be deployed to a network server for remote access. oder This licensing brief should answer most questions about how to license Microsoft Office in a Terminal Services environment. The general rule of thumb is "one license for each desktop accessing Microsoft Office," which is the per-device licensing policy. Schon klar, jedes Gerät, welches auf MS Office zugreift muss eine Office Lizenz besitzen. Logisch und technisch richtig ist aber, dass ich kein lizenzpflichtiges Gerät habe, wenn meine Nutzer das Office nicht starten können. Man nennt sowas auch Paradoxon. Demnach bin ich der Ansicht, dass der TO nur zwei Office/Visio Lizenzen benötigt..

Microsoft spricht in seinen Lizenzierungs White Paper aber nicht von "möglichen" und kann Zugriffen sondern nur von tatsächlichen Zugriffen! Die Aussage: Per-device licensing means a customer must obtain a license for each desktop on or from which the product is used or accessed. For example, when a desktop application is accessed remotely across an organization using Windows Server Terminal Services, a separate desktop application license is required for each desktop from which the application is accessed. ist eindeutig und weist auf die Lizenzierungspflicht hin, wenn das Office tatsächlich genutzt bzw. durch das Gerät im Zugriff auf den TS genutzt wird. Die Betonung liegt hier mit Absicht auf wird, nicht auf kann. Oder muss ich neuerdings für Geräte (egal ob Windows oder nicht) in meinem Netzwerk Windows CALs kaufen, nur weil die Möglichkeit besteht und es sein kann, dass sie auf einen Windows Server oder Windows Terminal Server zugreifen, diese aber nur für die lokale Arbeit gedacht und angewendet werden? Wohl eher nicht... Das Microsoft in seiner Darstellung und Erläuterung tatsächlich nicht eineindeutig ist vereinfacht die Thematik nicht gerade. Insofern sind die von den Vorrednern gemachten Angaben zur Lizenzierung meines Erachtens nach (teilweise) mit großer Vorsicht zu genießen. Was Microsoft in seinem White Paper und den Lizenzbestimmungen übersieht ist, dass paradoxerweise ein Gerät, welches den Zugriff auf das Office eines Terminal Servers ermöglicht nur dann zu einem lizenzpflichtigen Gerät werden kann, wenn das Office darüber auch tatsächlich genutzt wird und dies technisch in der jeweiligen Konstellation möglich ist. Beschränke ich bspw. für alle Nutzer in der Außenstelle A den Office Zugriff via NTFS Berechtigung, kann keines der Geräte lizenzpflichtig sein, da sich kein Nutzer anmeldet, der ein Gerät besitzt, über welches ein Office im Zugriff ist. Das Gerät entfällt somit im Sinne der Bestimmungen der Lizenzierungspflicht, weil über dessen Zugriff das Starten und Nutzen von Office nicht möglich ist, wenn sich ein Nutzer anmeldet, dem das Starten von Office nicht möglich ist. Das theoretisch die Anmeldung eines Nutzers in der Außenstelle möglich ist, der Zugriff auf das Office hat, ist ein vollkommen anderer Fakt. Die Lizenzbestimmungen können gleichwohl in diesem angenommenen Fall nicht als anwendbar betrachtet werden, da ich für die theoretisch angenommene 10fache Installation von Office (bei bspw. 5 gekauften Lizenzen, aber 10 PCs) auf normalen PC Arbeitsplätzen auch nicht zahlen muss. Eine weitere Frage, die desweiteren aufgeworfen wird ist, ob die Lizenz, die ein "TS Office fahiger Nutzer" in Verbindung mit seinem Thin Client in der Hauptgeschäftsstelle (für den Thin Client wurde eine Office Lizenz gekauft) bisher genutzt hat jetzt auf einen Thin Client (dem bisher keine Office Lizenz zugewiesen wurde) in der Außenstelle angewendet werden kann, WENN, sein altes Gerät in der Hauptgeschäftsstelle keinen Zugriff auf das Office hat. Denn die Problematik ist hier, anders wie bei PCs, das das Office auf dem Server, nicht aber auf dem Thin Client installiert ist und somit ja nicht physisch an diesen "gebunden" ist. Beim PC-PC Szenario würde man das Office vom alten PC deinstallieren (es wird dort nicht mehr benötigt und genutzt) und auf den neuen installieren. ...

Hallo, folgende Problematik: lokales LAN: 192.168.0.0/24 Ein über ein im LAN angeschlossener Router erreichbareres Zielnetz im WAN nutzt ebenfalls den IP Bereich 192.168.0.0/24. Das Problem: Auf das WAN Zielnetz soll vom LAN aus zugegriffen werden. Den Gesetzen des Routings zufolge wird dies nicht funktionieren, da die IP Kommunikation im lokalen Netz bleibt. Der WAN Router wird die Anfrage an die Ziel IP (bspw. 192.168.0.22) nicht über sein WAN Interface verschicken. Wer hat eine Idee für einen Lösungsansatz?