eXOs

Hallo zusammen, unsere Entwicklung kam auf mich mit einer Frage zu auf die ich keine Antwort weis: Beim Visual Studio 2013 ist es wohl so, dass eine Windows ID benötigt wird um die Lizenz zu nutzen. Wenn dort eine Windows ID eingegeben wird die nicht dem unternehmen zugeordnet ist ist Visual Studio im Demo Modus. Muss ich jetzt jeden Entwickler mit der Windows ID dem Unternehmen zuordnen? Viele Grüße Leo

Hallo Nils, hatte ich bissher ausgeschlossen, weil es ja wie gesagt einmal funktioniert hatte, werde das aber noch mal prüfen - Danke

Hi zusammen, ich habe hier mal ein Problem bei dem ich nicht weiter komme. Domainstruktur: 3 Standorte, hier in DE der übergeordnete Forest und 2 Domains (DE1 und DE2), zwei Niederlassungen im Ausland, davon hat eine den Domaincontroller hier (US1) und eine den Domaincontoller in der Niederlassung selbst (US2). Der Exchange Server steht in der DE1 Wenn ich nun versuche, auf dem Exchange Server ein neues Konto für einen User der Domain US2 anzulegen, erhalte ich die Meldung, dass für die Domain kein Domaincontroller gefunden werden kann. Das komische daran ist, dass ich bereits ein Konto für einen User dieser DOmain anlegen konnte. Hat irgendwer nen Tipp? Grüße Leo

Hallo zusammen, wir suchen schnellstmöglich einen System- / Netzwerkadministrator für alles was so anfällt. Stellenbeschreibung findet ihr (noch nicht, kommt aber die nächsten Tage) hier: Arbeiten bei Across Bei Interesse gerne PN an mich, dann informiere ich auch gerne aktiv sobald die Anzeige auf unserer Website online ist. Grüße Leo

Hallo zusammen und noch ein fohes neues Jahr euch allen. Im Grunde ist es egal was da getstet werden soll. Es geht nur darum, ob es sinn mach dies so auszuziehen. Ich denke sicherheitsstruktur sollte ich tatsächlich überdenken, bin aber soweit mit den Überlegungen, dass wir das so umsetzen - danke

Nein, es geht nicht um Domaintests. Wir sind eine Softwarefirma. Die Testserver/ Clients sollen zum einen leichter für alle erreichbar sein und zum anderen muss das system eben auch mal in einer domain getestet werden. Und wer die Testdomain kaputt macht bekommt eine auf den Deckel :-) Nein, die Leute sind EDV technisch schon fit, aber an der produktiven Domain soll auf keinen fall einer rummfummeln um was zu testen.

Hi zusammen, ok, nochmal die Fakten: Testdomain: - Jeder aus der Technik hat das recht systeme in die Domain einzubinden - Jeder aus der Technik hat lokale Admin Rechte in der Domain - Jeder aus der Technik muss ggf. Änderungen an der Domain machen können (Technik <> Admin) Produktivdomain: - Keiner außer der Admin und ich darf Systeme in die Domain einbinden - Nur wenige haben auf die Server Admin Rechte - Keiner außer der Admin und ich darf Änderungen an der Domain durchführen Der Zugriff soll aber direkt möglich sein, idealerweise eben mit den Daten der Produktivdomain - daher die Vertrauenstellung. Nun bin ich an dem Punkt das ich mir überlege, das Routing wegzulassen und das Subnetz mit der Subnetzmaske zu erweitern, dann setze ich im gleichen Netz die zweite Domain auf, erstelle eine Vertrauenstellung und dann habe ich doch genau das was ich will. Ich weiß nur nicht genau, wie elegant und unkompliziert das Ganze ist.

Hi dmetzger, danke für die Antwort. Das ist korrekt, aber ich hatte vergessen eine kleinigkeit zu erwähnen. Ich wollte grundsätzlich die Trennung der DOmains (Produktiv und Testdomain) durchführen - das ganze hatte keine so hohe Prio, die Testsysteme sind nicht in der Domain, eine eigene Domain dafür würde aber einigen Leuten das leben leichter machen. Da jetzt die IPs knapp werden habe ich das zum Anlass genommen diese Trennung gleich mit zu machen. Wären die beiden Domains im gleichen Subnetz möglich?

Hi zusammen, ich hätte da mal eine Frage. Wir haben hier langsam IP Adressen knappheit, ich möchte mir aber die Umstellung auf ein B Klassen Netz nicht wirklich antun. DIe Knappheit ist primär auf den starken Zuwachs von Testsystemen (VMs) die von verschiedenen Hosts erreichbar sein müssen zurückzuführen. Meine Idee wäre deshalb, eine zweite Domain - eben für die Testsysteme aufzuziehen. Ich habe mir das so gedacht, dass dann unsere produktive Domain im Netz 192.168.1.x läuft, die Testdomain im Netz 192.168.2.x. Mit dem Routing des W2k8 will ich dann das Routing zwischen den Netzen durchführen und eine Vertrauenstellung für die Authentifizierung einrichten. Dann müsste es ja möglich sein, aus der Produktivumgebung auf die Testsysteme zuzugreifen. Die Frage wäre aber dann noch, ob das auch ein Weg ist der zu empfehlen ist, oder ob besser in Hardare investiert wird die mir das Routing macht. Was denkt ihr?

Hi Dukel, danke für Deine Antwort. Daraus schließe ich dass es grundsätzlich möglich ist, mein Vorhaben zu realisieren. Nun geht es nur noch um das WIE. Aktuell teste ich noch und hierfür verwende ich eine dnydns domain. Aber grundsätzlich handelt es sich um 2 subdomains. Von dem her was Du schreibst würde ich sagen die Config passt: ticket.extern.de:443 -> 10.10.1.200:80 service.dyndns.org:443 -> 10.10.10.50:80 Das kann ich in der Config niergend so eingeben aber im Grunde würde ich behaupten dass es genau das tut. Vielleicht noch zur Info: Der ISA steht natürlich in der DMZ (10.10.10.x), das System auf das die "service" weitergereicht werden soll steht ebenfalls in der DMZ, das System fürs Ticket System steht im LAN. Könnte das schon Probleme machen?

Hi zusammen, wieder mal ein ISA Problem. Ich habe einen ISA 2006 der mir über HTTPS den Zugriff von außen auf unser Ticketsystem erlaubt. Definiert habe ich das ganze so, dass alles über port 443 an ticket.beispiel.de auf einen internen Server weitergeleitet wird auf dem eben das ticketsystem läuft. Nun haben wir einen zweiten Server der über HTTPS angesprochen werden soll. Jetzt wollte ich das Ganze ähnlich realisieren - alles über port 443 an service.beispiel.de wird an einen anderen internen Server weitergegeben. -> Nun ist das Ticketsystem nicht mehr erreichbar. Ich nehme an, dass es daran liegt, dass beide den gleichen Port verwenden - richtig? Wie könnte ich das mit dem ISA realisieren?

Ich nun wieder. Es ist mir nicht gelungen dieses Problem zu lösen. Ich habe daher einen Terminalserver in der Test Domain installiert und auf diesem war die Einrichtung des CRM CLients für Outlook kein Problem. Ich gehe daher davon aus, dass es tatsächlich mit dem Zugriff aus einer auf die andere Domain zu tun hatte. Ich überlege gerade ob es vielleicht geolfen hätte eine Vertrauenstellung zwischen den beiden Domains einzurichten - werde ich aber wohl nie erfahren da ich keine Zeit zum testen habe. Danke an alle die sich gedanken zu dem Thema gemacht haben

Hi zusammen, wir planen den Umstieg von unserer aktuellen CRM Software auf ein anderes Produkt und evaluieren derzeit Dynamics. Ich habe dazu eine Testdomain eingerichtet. Zum Testen selber greifen wir aber aus unser eigentlichen Domain über den CRM Webclient auf das CRM in der Testdomain zu - soweit alles gut. Nun wollen wir uns aber auch den Outlook Client anschauen. Hier habe ich nun ein paar Probleme. Angefangen hat es damit, dass er die URL zum Dynamics nicht gefunden hat. Im Browser funktioniert diese aber einwandfrei. Dieses Problem hatte ich, ein Kollege aber nicht und er hatte die Logindaten beim Login in den Webclient gespeichert. Dies hat dann auch bei mir das Problem mit der IP Adresse gelöst und die Verbindung funktioniert nun wohl, jetzt bekommen wir aber dannach eine Fehlermeldung: Fehler bei der Anforderung mit HTTP-Status 401: Unauthorized. Meine Vermutung ist nun, dass es mit den unterschiedlichen Credentials der beiden Domains zusammenhängt. Oder bin ich hier auf dem Holzweg. Selbst wenn das stimmt, hat jemand dennoch eine Idee wie ich das lösen kann?

Naja, wenn wir zusammenlegen :D

So, hat sich gelöst. - Unter Bridging ist der 80er, das ist also die Verbindung vom ISA zum Apache - Unter Listener ist der 443er, das ist also die Verbindung vom INet nach drinnen. Ich habe nun "einfach" die Regeln von neuem Konfiguriert. Zuvor war da schon mal was gemacht worden und ich habe versucht, an der bestehenden Regel was zu ändern.