Data1701
-
Gesamte Inhalte
1.679 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von Data1701
-
-
@ Dr. Melzer
Merci, ich habe mich nur "drangehängt" weil die Thematik passte, aber so ist es auch vollkommen OK.
@NilsK
Das Thema I/O-Last ist mir bekannt. Es stellt sich wirklich nur die Frage, darf ich es Lizenzrechtlich. Dann kommt das Thema, erhalte ich Support von MS und/oder vom Backupsoftwarehersteller, hier also Symantec. Außerdem muss ich ketzerisch Fragen: "Installiert MS keinen AV-Schutz auf seinen Hyper-V Hosts ?"
Leider habe ich nichts gefunden was die Begrifflichkeit "Ausführung der Software zum Verwalten und Warten von Betriebssystemumgebungen auf dem lizenzierten Server" etwas eingrenzt.
Wir können ja mal Frau Irene Kisse fragen :-). Vielleicht wurde dort schon ein salomoisches Urteil gesprochen.
Gruß Data
-
Hmh,
sehr intressant.
• Falls Sie alle fünf zulässigen Instanzen gleichzeitig ausführen, darf die in der physischen Betriebssystemumgebung ausgeführte Instanz der Serversoftware ausschließlich zu Folgendem genutzt werden:o Ausführung der Hardware-Virtualisierungssoftware
o Bereitstellung von Hardware-Virtualisierungsdiensten
o Ausführung der Software zum Verwalten und Warten von Betriebssystemumgebungen auf dem lizenzierten Server.
Da stellt sich mir die Frage, wie sieht es dann auf einem DATACenter-Server aus, dort gibt es ja praktisch keine "Instanzengrenze" außer die Hardwareimmanente.
Des Weiteren würde ich gerne wissen, ob es eine Art "Whitelist" für Software auf der physikalischen Maschine gibt. Es ein Virenscanner schon ein Dienst der nicht laufen "darf". Wie sieht es z.B. mit einer Software wie BackupExec aus ? Diese SW ist ja gerade dazu entwickelt den Hyper-V incl. aller Gastsysteme zu sichern, fällt das unter "Serverwartung" oder darf das auch nicht installiert werden, wenn die max. Anzahl an Instanzen betreibt ?
Gruß Data
-
So, langsam blicke ich durch.
Intressant war auch der Artikel:
Faktoren, die das Abschneiden des Protokolls verzögern können
Faktoren, die das Abschneiden des Protokolls verzögern können.
Wie sieht denn Dein Notbremsskript aus ? Würde mich mal intressieren.
So wie ich es bverstanden habe, kann man gar nicht vorhersagen, wann die LOGs abgeschnitten werden, oder.....
Das mit dem Skript ist mit Sicherheit eine super Sache, nur würde ich vom SQL erwarten, dass er das sleber hinbekommt.
Die riesen LOGs machen dei DB auch nicht gerade schneller.
Gruß Data
-
@ Dr. Melzer
Nur die Begrifflichkeit (TS-Lizenzen) passt nicht, sonst stimmte alles.
CALS für Server, TS-CALs für die RDS-Dienste.
Gruß Data
-
Lese ich mir morgen durch.
Ich bin der Meinung, dass die LOGs sehr groß wurden, da auf beiden Server die LDF-Datei das Datum 01.02.2010 trug und auf einem Server 25 GB auf eine anderen 100 GB groß war.
Ich war der Meinung, dass SQL, ähnlich dem EX-Backup die LOGS auto. abschneidet.
Habe den Artikel noch nicht studiert, wenn ich den gelesen habe und noch Fragen habe, dann werde ich mich noch einmal hier melden.
Gruß Data
-
??
Du brauchst nur soviele TS-Lizenzen wie User via TERMINAL-Server zurgreifen.
Ein DC der 20 Clients bedient bedeutet ein Kauf von 20 Server Cals - DC-Lizenzen gibt es nicht. Wenn Du 100 Server hast und nur 20 Clients, benötigst Du auch nur 20 Server - Cals, jedoch 100 Server-Lizenen.
Wenn jetzt 4 Leute eine TS-Applikation auf dem DC öffnen benötigst Du nur 4 TS-Lizenzen und nicht 20.
Soweit klar ?
Gruß Data
-
Sorry, habe was vergessen:
Nächtliches Full-Backup, dann im Abstand von 4 Stunden jeweils ein LOG-Backup, in BE (Transaktionsprotokolle sichern).
Gruß Data
-
@NilsK
Mal bitte für Doofe. SQL ist nicht mein Ding.
Studio öffnen - Neue Abfrage ? Nur Text habe ich nicht gefunden, aber meintest Du diese Ausgabe ?
Name=DB1
1459.81 MB
User=
DBID=42
created=Sep 9 2009 S
Status=ONLINE, Updateability=READ_WRITE, UserAccess=MULTI_USER, Recovery=FULL, Version=611, Collation=Latin1_General_CI_AS, SQLSortOrder=0, IsAutoCreateStatistics, IsAutoUpdateStatistics
Comptibilty=80
BackupExec-Logs sind grün, deshalb habe ich den Anwuchs der LOG-Files auch gar nicht bemerkt.
Event-Log für o.g. DB (LOG-Backup):
Das Protokoll wurde gesichert. Datenbank: DB1, Erstellungsdatum(-zeit): 2009/09/09(15:54:14), Erste LSN: 508:11530:1, Letzte LSN: 508:15399:1, Anzahl der Sicherungsgeräte: 1, Geräteinformationen: (FILE=1, TYPE=VIRTUAL_DEVICE: {'DB1_00__8f98ee60_a19b_4bd3_830d_8a66235d5033_'}). Diese Meldung dient nur zu Informationszwecken. Es ist keine Benutzeraktion erforderlich.
Event-Log für o.g. DB (Full-Backup):
Der E/A-Vorgang für die DB1-Datenbank hängt. Es ist keine Benutzeraktion erforderlich. Wenn der E/A-Vorgang jedoch nicht umgehend fortgesetzt wird, sollten Sie die Sicherung möglicherweise abbrechen.
gefolgt von:
Der E/A-Vorgang für die DB1-Datenbank wurde fortgesetzt. Es ist keine Benutzeraktion erforderlich.
gefolgt von:
Die Datenbank wurde gesichert. Datenbank: DB1, Erstellungsdatum(-zeit): 2009/09/09(15:54:14), gesicherte Seiten: 1, Erste LSN: 508:11231:101, Letzte LSN: 508:11274:1, Anzahl der Sicherungsgeräte: 1, Geräteinformationen: (FILE=1, TYPE=VIRTUAL_DEVICE: {'BE_SQLAgent-DB1__30d4e15d_4b5e_40dd_997a_fe31fe33e7ac_'}).
Das wars. Eigentlich alles i.O.
Gruß Data
-
Mahlzeit,
ich habe hier ein Problem, dass ich mir nicht erklären kann. Seit dem 01.02.2010 werden anscheiend die LOGs auf den SQL-Servern nicht mehr auto. gekürzt. An diesem Tage wurde "nur" ein IE8 Patch installiert, nichts SQL relevantes.
Das SQL Studio zeigt mir schön wann die letzte Datenbank- bzw Logsicherung war, allerdings werden die LOGs nicht abgeschnitten. Ich kann natürlich händisch rangehen, aber das ist ja keine Lösung.
Soweit ich weiß, wurde an den SQL nicht gemacht bis auf das IE-Patch. Gesichert wird mit BackupExec, da wurde kein Patch installiert, davon abgesehen schneidet ja nicht BackupExec die LOGs ab sondern der SQL-Server, BE markiert nur die LOGs zum abschneiden.
Hat jemand einen Einfall, was hier schief laufen könnte.
Gruß Data
-
@NilsK
Yep, das schwebt mir vor..... Die Anforderungen werden gestellt.
Max. Ausfallsicherheit für min. Geld :-)
Gruß Data
-
Nun, da muss ich dir leider recht geben..... :cry:
Oracle, no way. Geht nicht, dann wird es wohl doch ein Fail-Over-Cluster....
Es gibt doch auch die Möglichkeit die Logs via Transaktionsprotokollversand auf einen Stand-by-Server abzulegen, oder ?
Das ist aber wahrscheinlich nur ein Versand, übrigens wie werden Logs da truncated (?) ein offline Server kann ich ja nicht sichern und bei einer Sicherung werden die logs ja abgeschnitten, und geht nicht online wenn die primäre Inszanz ausfällt oder ?!
Gruß Data
@ Lian
Merci, schaue ich mir gleich mal an.
Es muss ja auch nicht immer eine SAN sein, kann man die Datenbanken doch auch lokal vorhalten... Eine Server mit 12 SAS-Platten ist je kein Problem mehr.
Gruß Data
-
Boardmittel sind für mich immer Bestandteile des Serverproduct gepaart mit der Applikation.
Also die Boardmittel von Server 2008R2 und SQL 2008.
SAN ist schön, aber auch teurer und SAN-Replikation ist noch teurer.....
Gruß Data
-
Ich glaube ich habe schon gefunden was ich nicht wollte ....:
Ich bin davon ausgegangen, dass ich die Datenbanken mit Boardmittel replizieren kann.
Aber um Deine Frage zu beantworten, ich hätte gerne ein SQL-Cluster gebaut welches halt nicht als Single-Point-of-Failure die SAN hat, sondern schön wäre es wenn ich sowhl Server wie auch die Datenbanken im Cluster hätte (2 Nodes).
Gruß Data
-
Mahlzeit,
mal eine Gretchen-Frage, was würdet Ihr vorziehen:
SQL - Failovercluster oder Multi-Site-Cluster, wobei Multisite nicht geographisch getrennt zu betrachten ist, sondern "nur" zwei verscheidene Gebäude auf einem Gelände.
Hat jemand da Erfahrungen ?!
Gruß Data.
-
Noch einmal einen Nachschlag :-),
Durch das Release von Forefront Threat Management Gateway entzerrt sich die Lage etwas.
Ich habe mich gegen den ISA in der DMZ immer etwas gewehrt, da ich nicht noch ein Kiste haben wollte, die quasi nur "eine Aufgabe" hat.
Das Threat Management Gateway kann ja nun endlich out-of-the-box das, wofür sonst andere Produkte eingesetzt wurden. HTTP Antivirus, Exchange EDGE Server Integration möglich....
Da könnte ich mir glatt vorstellen zwei Server in der DMZ zu ersetzen und dann das Threat Management Gateway als Reverser-HTTPS-Proxy zu nutzen.
Mal schauen...
Trotzdem, wenn ein Produkt den Namen "Gateway" trägt, also Remote Desktop Gateway, dann gehört es eigentlich in die DMZ, nur was nicht ist, ist halt nicht.
Gruß Data.
-
@ NorbertFe
Aber nur in der Enterprise CAL aus einer SA bezogen.
Für Antigen benötigte ich (wenn ich mich recht erinnere) immer das Produkt, z.B. Antigen for Exchange mit oder ohne Anti-Spam und zusätzlich CALs. So war es unter Sybari, unter MS habe ich Antigen nie lizensiert.
@LukasB
Yep, hast ja recht. UM ist Bestandteil der CAL nicht des Servers.
Es gibt ja eigentlich keine "Enterprise" oder "Standard" Installation, der Lizenzkey bestimmt die Möglichkeiten, was dann natürlich eine Umstieg von Standard auf Enterprise erleichtert.
@BrainStorm
Wenn ich die 100 DBs sprege melde ich mich... :D
Voerst werde ich mit 6-10 auskommen.
Danke für Eure Hinweise. Schönen Tag noch.
Gruß Data
-
Sorry,
Nein. Ob du Exchange Standard oder Exchange Enterprise einsetzt hat _nur_ und ausschliesslich Einfluss auf die Anzahl möglicher Databases (5 Standard, Unlimitiert Enterprise).Meine Aussage bezog ich nur auf die CALs. Habe es jetzt aber kapiert.
Eine Enterprise-CAL über eine SA mit einer gewissen Laufzeit, "lizensiert" FPE mit.
Einem Select fehlt ja "quasi" die Laufzeit wie bei einer SA, deshalb gilt Enterprise-CALs plus FPE CALs für die Laufzeit, oder Standard CALs plus FPE CALs für die Laufzeit, wenn man keine Ent-Feature nutzt.
Serverlienzierung muss natürlich stimmen. Mehr als 5 DAGs und/oder UM (z.B.) = Enterprise Server.
Es gibt keine Standard oder Enterprse Installation, der Server wird immer gleich installiert unterscheidet sich nur durch den Product-Key, der dann die Features freischaltet.
Merci und schönen Abend noch.
Gruß Data
-
Habe ich bereits seit unserem Ex2k eingesetzt und kann nichts negatives sagen...
Mit 2010 soll jetzt Forefront f. Exchange kommen. Habe ich richtig verstanden, dass "nur" CALs benötigt werden, also nicht wie bei ANTIGEN Cals + Serverprodukt ? Ich muss kein Serverprodkut mehr kaufen egal wieviel HT-Server ich betreibe ?!
Und wenn ich Ex-Enterprise einsetze, dann habe ich Forefront f. Exchange schon dabei ? Sonst Standard-Server + FFSE CALs ?!
Antigen musste ich immer für x-Monate kaufen, Forefront auch ? Also Monate x Cals x Preis = Kosten.
Gruß Data
-
Also ist die Lösung noch immer:
a. Gateway intern legen
b. Auf AD-basierende CAPs und RAPs verzichten.
Schade.
Gruß Data
-
Moin,
hatte viel um die Ohren und habe dabei irgendwie diesen Thread vergessen.
Ich versuche es noch einmal.
...zwischen Forwarding von RDP ins interne Netz und Veröffentlichung von Port 443 (über welchen die RDP-Requests getunnelt werden), welches über den ISA läuft und nicht einfach weitergeleitet wird, gibt es doch Unterschiede.Meine Aussage zu 3386 war überspitzt und sollte als solches auch verstanden werden. Sicher eine 443er-Veröffenlichung ist nicht mit dem 3386 forwarding zu vergleichen, nur hätte ich gerne den Port 443 über das Gateway veröffentlicht, ohne einen ISA-Server dafür in die DMZ zu stellen.
Das ist halt was ich von einem "Gateway" erwarte.
Und vom VPN sind welche Ports offen?Alle, da die PCs sich ja in meinem virtuellen privaten Netzwerk befinden. Das gilt aber nur für PCs der eigenen Unternehmung die unserer PC-Hygiene unterliegen (WSUS - Antivirenschutz). Fremd-PCs können nur via RDP bzw. RemoteApp rein.
Hört sich nach einer Aufgabe für den ISA-Server an.Ein ISA muss nicht Domainmember sein und kann die genannten Vorgaben erfüllen.
Ich hoffe, du verzeihst mir diesen kleinen Seitenhieb, aber wie hast du Memberserver, die nicht in der Domäne sind?
Seitenhieb OK ;), natürlich kleiner Tippfehler, Workgroup-Server, KEINE Memberserver.
Ja? Ich nicht. Erklär es mir.Vielleicht solltest du dir die Geschichte mit der von dir genannten Abbildung nochmals anschauen und dann überlegen, warum z. B. auch Port 3389 von der DMZ ins interne Netz weitergeleitet wird! Könnte ja vielleicht damit zu tun, dass kein ISA eingesetzt wird.
Nun, ich erkläre es gerne, weil man eine "relativ" schlechte Umsetzung nicht noch weiter breitreden möchte. Einfach mal einen Pfeil vom Gateway an der Firewall vorbei ins interne Netz zeichnen und auch sonst seiner Dokumentationspflicht nicht nachkommen. :(
Der Port 3389 wird über das Gateway nach innen geleitet, ist ja auch OK, sonst würde das ganze Konstrukt ja nicht funktionieren. Aber die AD-Zugehörigkeit mal eben mit "einem Pfeil" abhandeln ist nicht die feine Art.
Wenn du eine bessere Lösung hast, dann nutze sie. Anderenfalls steht es dir natürlich frei, eine bessere Lösung zu entwickeln. Deine Beschwerden zeigen nur, dass du dich nicht mit dem ISA beschäftigt hast (und lieber falsche Annahmen hier einbringst), aber sie helfen dir auch nicht weiter.Also auch wenn ich es mal so klar sagen muss ;), ich habe mich mit dem ISA beschäftigt, so ungefähr seit dem Jahr 2000.....
Es geht mir doch auch gar nicht darum, dass ich den ISA schlecht reden will. Das Produkt ist wirklich fein in manchen Bereichen, mit Sicherheit könnte ich auch hier alles damit erschlagen, allerdings muss ich dann wieder Geld in die Hand nehmen für Hard- und Software.
Ein Gatewayprodukt gehört in die DMZ und nicht in das interne Netzwerk, sonst muss ich es nicht Gateway nennen. Es ist nun einmal mein Standpunkt, dass ein SSL-Bridging via RDS-Gateway begrüßenswert gewesen wäre und nicht mit einem Zusatz-Produkt wie z.B. ISA. Ein Tunneling der SSL-Anfragen direkt nach innen ist eine Krücke aber keine Lösung.
Ich muss mir den Server 2008 R2 noch einmal genauer anschauen, aber ich habe irgendwo gelesen, dass das RDS Gateway unter 2008 R2 kein Memberserver mehr sein muss. Leider finde ich den Link dazu nicht mehr werde ich aber sofort nachliefern wenn ich diesen finde. Leider habe ich noch kein Best Practice für Server 2008 R2 gefunden.
Wenn dem dann wirklich so ist, dann spricht dass eigentlich nur dafür, das MS und auch andere Kunden die gleiche Ansicht vertreten wie ich :cool:.
Gruß Data
-
Ich glaube wir sprechen aneinander vorbei.
a. Gateway gehört für mich in die DMZ. Sonst könnte ich auch direkt 3386 forwarden auf die Server die ich benötige.
b. OWA wird bei mir gar nicht geforwarded. Zugriff auf eMail etc, geschieht nur über VPN, Konzernrichtlinie
c. Die Konzernrichtlinie schreibt auch vor, das jeder Zugriff auf das interne Netz in der DMZ gepuffert werden muss. Das betrifft SMTP, HTTP, FTP, Black-Berry etc.
Jede der unter c. genannten Kompenten ist kein Domänenmitglied, übrigens wir sprechen immer von 2008 Meberserver.
Dein Vorschlag verstehe ich sehrwohl. Nimm einen ISA-Server und puffere damit die Anfragen. Das ist für mich ein Krücke. Ich muss ja auch keinen ISA-Server in die DMZ packen um SMTP-Anfragen zu puffern oder ?! Das Design der Exchange-EDGE-Komponete erlaubt es ohne den ISA-Server ein max. an Sicherheit zu bekommen. Warum wurde das beim TS-GW nicht ähnlich gemacht, dass ist die Frage die ich mir stelle...
Als Kunde muss ich die "schlechte" Umsetzung durch den Zukauf eines weiteren Produktes kompensieren.
Des Weiteren hat TS-GW noch weitere kleine "Bugs", die dieser Komponenete nur ein ausrreichend bescheren.
Was passiert, wenn das Passwort in der Domäne abläuft und der User versucht sich über das TS-GW einzuklinken. Die TS-CAP verhindert das, das TS-GW gibt aber keine Möglichkeit zur Änderung des PW.
Veröffentlichung der benötigten Dienste und Anwendungen prädestiniert. Die benötigten Ports für die Kommunikation mit der Domäne sind nur auf der internen Schnittstelle geöffnet und nicht aus der DMZ erreichbar.Da muss ich mir keinen Link durchlesen, mir ist schon klar was Du vorhast und wie es funktioniert, sorry das ich das so klar sagen muss.
Schaue Dir mal genau die Doku für die Impelementierung des TS-GW an.
Download details: TS Gateway Step-By-Step Guide
Seite 39, das Schaubild. So sieht es bei uns aus. Der Pfeil vom TS-GW nach inner, geht "neben" der Firewall vorbei. Die Jungs von MS wissen schon warum....
Gruß Data
-
Für was steht denn bei dir die Abkürzung ISA? Den ISA-Server von MS kannst du ja nicht meinen !
Meine Aussage bezog sich nicht auf das forwarden als solches, sondern auf die Masse an Ports die eine Memeberserver in der DMZ geöffnet haben will.
Gruß Data
-
Dann stell den RDGW ins LAN und Forwarde Port 443 und reg dich nicht auf
Dann kann ich Port 80 von meinem Internetantritt forwarden oder den Port 25 für SMTP forwarden....
Entschuldingung, aber wofür habe ich den ein zweistufiges Firewallkonzept ?! Wofür gibt es Honeypots ? Ne, sorry, da kommt MS nicht drum herum, sich für diese Implementierung maximal ein ausreichend abzuholen.
Ich hätte jetzt bei einem Aufbau mit einer zweistuffigen Firewall einen Radius Server in der DMZ erwartet - würde das die Sache nicht einfacher machen?Bringt nichts, da Du keine Radius-Requests seitens deines TS-GW hinbekommst. Das TS-GW frag über die TS-RAP und TS-CAP immer die AD ab und keinen Radius-Server, außnahme Du baust lokale TS-RAPS und CAPS.
Der Memberserver (TS-GW) selbst will natürlich auch noch ein bisschen quatschen und seiner AD mitteilen, dass er auch noch existent ist, sonst stirbt ja irgendwann sein Computerkonto.
Daher Domainmember in der DMZ = Immer ganz schlecht !!
Gruß Data
-
10 Fingerssystemtipper schauen nur auf den Bildschirm... ;)
Gruß Data
Virtuelle Instanzen auf Datacenter
in Microsoft Lizenzen
Geschrieben
@NilsK
Also anzunehmen dass auf Grund von fehlenden Dateidiensten der Hyper-V-Server "sicher" ist, finde ich etwas blauäugig. Da gibt es ja noch andere Möglichkeiten der Infizierungswege....
Das ist ja gerade die Frage. Fahre ich eine Entprise-Server aus host bin ich so lange auf der "sicheren" Seite wie ich nur drei Gastsystem mit der richtigen Windows-Version betreibe, kommt jetzt das vierte Gastsystem hinzu was dann. Ich möchte halt gerne Wissen ob jemand den Ausspruch "Ausführung der Software zum Verwalten und Warten von Betriebssystemumgebungen auf dem lizenzierten Server" konkretisiert hat.
Gruß Data