NilsK

Moin, Norbert hat schon Recht. Du solltest dir jemanden dazuholen. Am Ende sparst du damit ganz sicher. Gerade wenn Fragen wie ActiveSync, Außenanbindung, Terminalserver usw. ins Spiel kommen, gibt es doch schon eine ganze Menge, was man falsch - oder zumindest nicht so gut - machen kann. Und ein Tipp dazu: Nimm niemanden von dem Lizenzhändler, der dir die simplen Fragen nicht beantworten kann ... Gruß, Nils

Moin, für 20 User benötigst du 20 CALs für Windows und für Exchange. In deiner Liste sind 40 Windows-CALs, die dürften nicht nötig sein, 20 reichen ja. Die Exchange-Enterprise-CAL benötigst du nur für einige Zusatzfunktionen wie das Exchange-eigene Archiv, Unified Messaging und zentrale Ordnerverwaltung. Nutzt du diese Funktionen nicht, kannst du die Enterprise-CAL weglassen. Office wird pro Arbeitsplatz lizenziert. In der Exchange-CAL ist Office bzw. Outlook nicht enthalten. Gruß, Nils

Moin, geht hier problemlos ... (OL 2013 gegen Ex 2010). Gruß, Nils

Moin, ja, dieses Vorgehen würde vermutlich am wenigsten Ausfallrisiko und am wenigsten Downtime erzeugen. Gruß, Nils

Moin, nein, wann genau die Anmeldung geöffnet wird, ist noch nicht bekannt. Ich gehe aber davon aus, dass wir hier zu den ersten gehören, die davon erfahren. :) Gruß, Nils

Moin, du hast "im Prinzip" Recht. Allerdings sind in der DDCP bereits Überwachungseinstellungen definiert, sodass ein separates GPO dort u.U. nicht die Ergebnisse erzeugt, die man haben möchte. Um den Artikel aufzurufen, suche ich immer nach "dandelions vcr" ;) [Dandelions, VCR Clocks, and Last Logon Times: These Are a Few of Our Least Favorite Things - Hey, Scripting Guy! Blog - Site Home - TechNet Blogs] https://blogs.technet.com/b/heyscriptingguy/archive/2010/01/27/dandelions-vcr-clocks-and-last-logon-times-these-are-a-few-of-our-least-favorite-things.aspx Gruß, Nils

Moin, da es hier zumindest in der Beschreibung etwas durcheinander geht, fangen wir erst mal mit den Basics an: [Die Anwendung von Gruppenrichtlinien steuern | faq-o-matic.net] http://www.faq-o-matic.net/2014/04/07/die-anwendung-von-gruppenrichtlinien-steuern/ Du sagst, "seit einiger Zeit" würden keine GPOs "mehr" angewendet. Es hat in derselben Konstellation also mal funktioniert? Wenn ja, was hat sich seither geändert? Sind evtl. Berechtigungen an GPOs oder an AD-Objekten geändert worden? Hat es Änderungen in der Infrastruktur gegeben? Die fehlerhafte Standortangabe, die du erwähnst, kann bedeutsam sein, muss sie aber nicht. Finden sich in den Eventlogs der DCs und der Clients Hinweise auf AD-, DNS- oder GPO-Probleme? Gruß, Nils

Moin, so ohne Weiteres (leider) erst mal gar nicht. Die administrativen Zugriffe, die dich interessieren, kannst du in der Default Domain Controllers Policy im Computerzweig definieren. Die Protokolleinträge finden sich dann im Security-Eventlog des jeweiligen DC. Wohlgemerkt: Jedes einzelnen DC; um eine Gesamtansicht zu erhalten, musst du also alle DCs überprüfen. Zusätzlich stehst du dann noch vor dem Problem, dass das Security-Eventlog sehr unübersichtlich ist, weil zu einem einzelnen Zugriff oft zahlreiche Einträge gehören. Das musst du dann also auch noch auswerten bzw. filtern. Seit Windows Server 2008 kannst du dann noch das erweiterte Logging aktivieren und so die Detailtiefe erhöhen - du siehst dadurch z.B. bei Änderungen den "alten" und den "neuen" Wert. Auch das richtet man in der DDCP ein, allerdings an etwas anderer Stelle. Lösen musst du dann in jedem Fall das Log Management - also die Datenmenge und die Auswertung. Hierzu gibt es auch kommerzielle Werkzeuge. Gruß, Nils

Moin, mal ganz nebenbei gefragt: Mit was für Lizenzen arbeitest du denn da? Und wer nutzt das Ganze hinterher? Gruß, Nils

Moin, vor allem musst du dich von dem Gedanken verabschieden, dass die virtuellen Netzwerke in Hyper-V so funktionieren würden wie in VMware Workstation. Die Szenarien für beide Produkte sind völlig unterschiedlich. Ein vSwitch in Hyper-V hat auch keine IP-Adresse. Ebenso verteilt er keine IP-Adressen an Gäste und führt keine Adressübersetzung und kein Routing durch. Die Konfiguration, die in dem oben verlinkten Video gezeigt wird, ist für Heim- oder Testnetzwerke machbar, in der professionellen Serverwelt lässt man sowas bleiben. Gruß, Nils

Moin, darüber hinaus erscheint es mir etwas unortrhodox, ausgerechnet Management und Live Migration zu koppeln. Das Management-Netz nutzt du, um die Hosts zu verwalten sowie für deren Anbindung an AD und WSUS. Die Live Migration hingegen findet nur zwischen den Hosts statt, da willst du normalerweise möglichst wenig anderen Traffic. Ohne näher draufgeschaut zu haben, käme mir als Skizze Folgendes in den Sinn: Team 1: VM-Netz, vSwitch drauf, keine Konfig im Management-OS 2 Karten ohne Team, aber mit MPIO für das SAN (vermutlich iSCSI) - i.d.R. alles außer IP abschalten, eigenes iSCSI-Netz, kein Routing, kein DNS/WINS 2 Karten oder ein Team für Cluster, CSV und Live Migration - Protokollbindungen weitgehend belassen, aber ein eigenes Netz und i.d.R. kein Routing, kein DNS/WINS 1 Karte oder Team für Management - normale Konfiguration Das Management-LAN zu separieren, ergibt nur dann Sinn, wenn es auch tatsächlich ein separates Management-LAN gibt. Das ist in vielen mittleren Umgebungen nicht der Fall - dann könnte man das Management über dasselbe Netz laufen lassen wie die VMs. Denkbar wäre auch ein großes Team aus sechs Karten für VM, Cluster und Management mit mehreren vNICs in der Parent Partition und Separation über VLANs und Bandbreiten-Garantien (geht nur per PowerShell). Das iSCSI würde ich auch in dem Fall über zwei separate Karten mit MPIO laufen lassen. Gruß, Nils

Moin, ja, aufnehmen kannst du den Server. Und ja, du kannst ihn hinterher auch hochstufen. Die nötigen Schritte dazu führt der Server-Manager automatisch aus (Schema erweitern, Forest und Domäne anpassen). Den Betriebsmodus kannst du aber erst dann hochsetzen, wenn die 2003-DCs deinstalliert sind. Gruß, Nils

Moin, mal ganz abgesehen davon - wie willst du denn die Daten auf den NAS-Büchsen synchron halten? Mir scheint das doch noch nicht recht durchdacht ... Warum nicht die User zu den Daten holen statt die Daten zu den Usern? Mit einer Terminalserverumgebung lässt sich die Arbeit evtl. über beide Standorte gut zentralisieren. Gruß, Nils

Moin, prima, danke für die Rückmeldung! Gruß, Nils

Moin, der Hinweis ist unnötig kompliziert geraten. Eigentlich sagt er nur: Dieser Server nutzt sich selbst als DNS-Server. Wenn du jetzt das AD entfernst, hat er keine DNS-Daten mehr und kann damit auch nicht mehr als DNS-Server antworten. Du musst daher die lokale IP-Konfiguration so ändern, dass der Server einen anderen DNS-Server fragt. Also alles sicher an der Stelle. Aber warum willst du /forceremoval machen? Reicht dcpromo nicht aus? Gruß, Nils

Moin, da fängt es schon mal ganz schlecht an, wenn du in Exchange kein Profi bist. Wenn ihr tatsächlich sowas aufbauen wollt, braucht ihr Profis. Glaub mir. Gruß, Nils

Moin, sehr hübsch in diesem Zusammenhang der Titel dieses Threads: Microsoft beschlagnahmt?! Ich glaub auch. Gruß, Nils

Moin, vielleicht ist der File Server Resource Manager hier hilfreich. [Generieren von Speicherberichten] http://technet.microsoft.com/de-de/library/cc731206%28v=ws.10%29.aspx Einfache Lösungen dürften bei dem angegebenen Volumen zu viel Last erzeugen. Gruß, Nils

Moin, Dukel hat völlig Recht: Dein Skript wird von oben bis unten abgearbeitet (es gibt darin ja keine Verzweigungen). Da du insgesamt elf Insert- bzw. Update-Statements hast, von denen jedes eine Ergebniszeile erzeugt, bekommst du auch elf Meldungen zurück. Die Meldung "1 Zeile betroffen" heißt, dass das betreffende Statement in der Tabelle, auf die es sich bezieht, eine Tabellenzeile hinzugefügt bzw. geändert hat. In Dukels Beispiel ist die Tabelle oder View "dbo.tm_stueckliste_pos" um eine neue Zeile erweitert worden. Das ist hier also relativ einfach zuzuordnen, indem du durchzählst. Gruß, Nils

Moin, lizenzrechtlich ist es egal, wie viele Accounts oder Mailboxen man anlegt - es zählt ohnehin die Anzahl der User (= natürliche Personen) oder der Endgeräte, je nach CAL-Zuweisungsmodell. Technisch ist es auch kein Problem, denselben Account durch mehrere User zu verwenden. Das sollte auch bei gleichzeitiger Nutzung eigentlich kein Problem sein (hier korrigiere man mich, falls das bei einer Exchange-Mailbox doch problematisch sein sollte). Bleibt also nur die organisatorische Ebene. Gruß, Nils

Moin, okay, und was genau ist jetzt deine Frage? Das Skript enthält ja eine ganze Reihe von Update- und Insert-Anweisungen. Jeweils hinter dem Kommando siehst du, welche Tabelle (oder View) dadurch bearbeitet wird. Wenn das ganze Skript ausgeführt wird, solltest du pro Statement eine Ergebniszeile ("47 rows affected") sehen. Da du von zwei Ergebniszeilen sprichst, ist wohl nicht das ganze Skript ausgeführt worden. Die Ausgabe, welche Tabelle betroffen ist, ist nicht vorgesehen. Wenn du das für Debuggingzwecke brauchst, müsstest du selbst Textausgaben in das Skript einbauen. Gruß, Nils

Moin, die Definition von "unternehmenskritisch" ist bei dem Supportangebot, das wir hier diskutieren (und das nur für Partner gilt - es geht hier übrigens um kostenlosen Support) ziemlich eindeutig festgelegt. Ich finde die Definition auch sehr nachvollziehbar und völlig legitim. Wenn bei einem Kunden "der Betrieb steht", weil ein Microsoft-Produkt ausgefallen ist, kann der Partner kostenlosen Support bekommen. Ein Backup, das anscheinend schon seit Wochen nicht funktioniert, fällt ausgesprochen deutlich nicht in diese Kategorie. Dafür muss man dann eben den normalen, kostenpflichtigen Support in Anspruch nehmen. Diese Diskussion führt zu nichts mehr. Wir können das hier beenden. Gruß, Nils PS. In was für einer Gegend lebst du, dass dort 500 EUR Stundensatz verlangt werden?!

Moin, unterbrochen wird die Produktion durch den Crash, nicht durch die fehlende Vorsorge. Anscheinend lässt sich der Kunde ja auch nicht am Weiterproduzieren hindern. Aber das ist eine Diskussion, die dann andere führen müssen. :D Gruß, Nils

Moin, poste doch bitte mal dein Kommando. Normalerweise wirkt ein INSERT exakt auf die angegebene Tabelle. Zwar gibt es die Möglichkeit, abhängige Datensätze zu manipulieren (z.B. Löschweitergabe), bei einem INSERT wäre das aber sehr unüblich. Das würde dann i.d.R. per Trigger gesteuert. Allgemein ist es aber, wenn du auf Datenbankebene manipulierst, durchaus sinnvoll und je nach Situation erforderlich, sich ausgiebig mit der Datenbank selbst und mit der dahinterliegenden Geschäftslogik zu befassen. Das kann auch schon mal sehr viel Zeit in Anspruch nehmen. Gruß, Nils

Moin, ah, OK, danke für die Info. Das ist in diesem Fall dann aber wohl nicht anwendbar, denn eine nicht funktionierende Datensicherung dürfte nicht als "unternehmenskritisch" gelten. Das gilt nur für Fälle, in denen die Arbeitsfähigkeit des Unternehmens unterbrochen ist. Da das Problem ja schon eine längere Zeit besteht, ist das nicht gegeben. Gruß, Nils