Knaeckebrot93

Hallo zusammen, aktuell haben wir das Problem, dass ein User sich darüber beschwert das die Text und Symbol Größe auf seinem Laptop zu klein sind, wenn er über Remotedesktop mit dem Terminalserver verbunden ist. Gibt es möglichkeiten bei Windows Server 2008 die Textgröße für jeden User einzeln zu konfigurieren? Was habe ich für Möglichkeiten? Mir wurde berichtet, dass bei Server 2008 die einzige Möglichkeit sein soll die Auflösung des Clients runterzudrehen, auf Vollbild zu skalieren und sich dann per RDP auf den Terminalserver zu verbinden. Gibt es da wirklich keine anderen Möglichkeiten? Durch das runterdrehen der Auflösung wird natürlich auch alles unscharf. In Server 2012 kann ich für jeden User die Textgröße der einzelnen Elemente Konfigurieren, bei 2008 finde ich diese Option aber nicht.

Es geht sich eigentlich nur darum ein aktuelles Lizenzverzeichnis mit allen Office Lizenzen zu erstellen. Ich habe auch schon einiges an Lizenzmanagment Software ausprobiert (z.B. Docusnap), allerdings konnten auch diese keinen Office 2003 Produkt Key auslesen. @Nobbyaushb Stimmt, habe grade nochmal nachgelesen. Es wird bei SLP wohl nur eine ID für den OEM Hersteller im Bios ausgelesen. Ist diese ID korrekt, wird Office wohl automatisch aktiviert. Nur der richtige Key muss doch wohl irgendwo abgelegt werden, ich muss diesen doch auch bei der Installation angeben. Irgendwie macht es mir Microsoft echt kompliziert an den Key zu kommen :( . @testperson Wieso habe ich nur mit dem Key keine gültige Lizenz? Ich kann doch jederzeit Office 2003 mit einem unserer vielen Key aktivieren, ich benötige eben nur den Key. Wir haben ja auch noch alle Lizenzen inkl. COA, es weiß nur keiner auf welchem Rechner welcher Key verwendet wurde, deshalb sollen die Keys einmal Inventarisiert werden. Wir haben halt noch unmengen an Office 2003 Keys warum sollte ich jetzt auf eine neue Version umsteigen, ich sehe da einfach keinen Grund für? Von Office 2013 kann man sogar nur die ersten 4 Zeichen des Keys auslesen, bringt mir auch nichts. Auf allen Online PCs wird ja auch eine aktuelle Version (2013) eingesetzt, aber es geht hier um ein komplett abgeschottetes Netzwerk ich sehe da Sicherheitstechnisch einfach keinen Grund für umzusteigen. Außerdem hat man dann wieder 20 User, die Funktion XY nicht finden können, weil Sie eben ewig mit 2003 gearbeitet haben und daran gewöhnt sind.

Es werden nur Dokumente unter den PCs ohne Internet Zugriff ausgetauscht. Bei Übertrag eines Dokuments aus dem Netz mit Internetzugriff in das Offline Netz muss vom Mitarbeiter eine Freigabe von der GF eingeholt werden und der Admin überträgt dann die Datei über einen dafür vorgesehenen Server. Das Offline Netz ist per Firewall komplett vom anderen Netz abgeschottet. Das ganze wurde schon so gelöst, dass da kein Sicherheitsrisiko besteht, darum geht es hier aber auch nicht :) .

Hi, einige der Rechner haben noch XP am laufen, die meisten sind aber auf Win7. Ich habe das Kommando eben auf einem PC mit Windows7+Office2003 ausprobiert, nach dem abschicken der Zeile wird mir allerdings kein Wert zurückgegeben. Die Eingabe von Get-WmiObject SoftwareLicensingProduct | Where {$_.Description -like "*Office*"} wird scheinbar ohne jede Fehlermeldung ausgeführt, allerdings erhalte ich einfach keinen Rückgabewert :( . Wenn ich das ganze richtig verstanden habe setzt unsere Office Version das SLP Verfahren ein, wodurch in der Registry wohl nur ein generischer Key (71927-OEM-3671024-19933) abgelegt wird. Der richtige Key wird anscheinend nur im Bios gespeichert. Die Software License Crawler liest diesen dann wohl aus dem Bios aus. Das erklärt auch, warum bei einem remote registry scan mit license crawler der Produkt key nicht ausgelesen werden kann, bei einem lokalen Scan aber schon. Jetzt bleibt halt nur die Frage wie liest license Crawler den Key aus dem Bios aus? Gibt es da in Windows Schnittstellen, womit man eine solche Abfrage erstellen kann? Ich würde das ganze halt am liebsten immernoch per Script lösen, anstelle hier am Wochenende 2 Stunden durch die Firma zu rennen um die blöden Keys auszulesen :( .

Hallo, ich habe mir eben den Artikel nochmal ganz durchgelesen. Dabei fiel mir auf, dass hier wohl eine "Office 2003 Systembuilder with BCM NON-OSB" eingesetzt wird. Im Artikel oben wurde geschrieben, dass sich durch eine Systembuilder Version (SLP) die ausgelesenen Product Keys unterscheiden. Leider wird dort nicht aufgeführt wie es Programmen wie Jelly Keyfinder möglich ist den Key dennoch auszulesen. @ testperson Die Lizenzen wurden alle mal als OEM Version einzeln gekauft. Da die Rechner mit Office 2003 alle keinen Internet Zugriff haben gibt es da auch keine Sicherheitsbedenken. Office 2003 läuft stabil, und ich sehe jetzt keinen Grund auf eine neue Version umzusteigen, zumal das wieder Kosten nach sich ziehen würde.

Hi, das hilft aber nicht wirklich weiter, leider. Erstens ist das alles auf Windows bezogen nicht auf Office und zweitens wird auch da nirgends ein gültiger Pfad angegeben. Ich weiß, dass ich den Key mit dritt Software auslesen kann, die Frage ist nur woher nimmt die Software diesen CD Key. Ich möchte halt ein Script basteln, welches die Keys aller Computer remote ausliest, allerdings müsste ich dafür erstmal den korrekten Registry Pfad zum Schlüssel haben. Die dritt Software wie Jelly Keyfinder wird den ja auch irgendwo herbekommen, die Frage ist nur wo und wie :(

Hallo zusammen, ich versuche den Office 2003 Produkt Key aus der Registry auszulesen. Überall ist zu lesen, dass der Office 2003 Key unter "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\11.0\Registration\{90190000-002A-0000-1000-0000000FF1CE}\ProductID" zu finden ist. Leider ist Wert des Schlüssels ProductID definitv nicht der CD Key den ich zur Office Installation eingeben musste. Der ausgelesene Wert sieht so aus: 71927-OEM-3671024-19933 Der original CD Key dagegen besteht aus 5 blöcken mit je 5 Buchstaben/Zahlen. Mit extra Software wie z.B. Jelly Bean Key Finder, oder License crawler kann ich den korrekten CD Schlüssel auslesen(Es wird mir als Product ID von beiden Programmen der wert 71927-OEM-3671024-19933 ausgelesen, als CD Key wird aber von beiden Programmen der richtige Office Key angezeigt. Jetzt Frage ich mich, woher die beiden Programme den richtigen CD Key nehmen, weil unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\11.0\Registration\{90190000-002A-0000-1000-0000000FF1CE}\ ist aufjedenfall kein Schlüssel mit dem Wert des CD Keys vorhanden. PS: Wenn ich mit License Crawler die office lizenz eines remote Computers auslesen will, wird der Office key aufeinmal nichtmehr gefunden. Der Key wird von License Crawler nur bei lokalem Auslesen gefunden. Kann es sein, dass der CD Key garnicht in der Registry abgelegt wird, sondern irgendwo im Bios oder ähnliches? Ich kann mir das bei office 2003 kaum vorstellen, aber ich finde auch nach Stunden suchen nirgends den Office-CD Key in der Registry, bin mittlerweile jeden erdenklichen Office Schlüssel in regedit durchgegangen :( . Jemand eine Idee wo der Schlüssel sein könnte, bzw. wie License Crawler/Jelly Keyfinder den auslesen?

Edit: Ich markiere den Thread hier mal als gelöst, da es hier ja eigentlich um etwas anderes ging und mache hier http://www.mcseboard.de/topic/208871-office-2003-product-key-aus-registry-auslesen/ weiter.

Guten Tag, ich möchte mit der Software Docusnap eine Inventarisierung unserer Office 2003 Lizenzen durchzuführen. Unter "workstation"-"Software" kann ich mir nach erfolgter Inventarisierung aller Workstations die installierte Software auf einzelnen workstations anzeigen lassen. In dieser Ansicht gibt es auch einen Tab "Lizenzschlüssel" worin für Windows 7 und Office 2013 die korrekten Produkt keys angezeigt werden. Leider ist das Feld Lizenzschlüssel bei allen Office 2003 Installationen leer (Key wird nicht ausgelesen). Deshalb frage ich mich nun, ob es mit docusnap möglich ist benutzerdefinierte Abfragen zu schreiben, welche sich den Office 2003 Key aus der Regestry der workstations holen und diesen anschließend in die Dokumentation einfügen. Evtl. gibt es ja auch andere Lösungen, wie z.B. das deployen eines scripts mittels docusnap, welches den Schlüssel ausliest? Hat hier jemand Erfahrung mit docusnap und kann mir sagen, ob es für mein Problem eine praktikable Lösung gibt? Ich stehe da momentan leider etwas auf dem Schlauch....

Hallo, wir haben in der Firma freigegebene Postfächer im Einsatz, welche bei den Mitarbeitern über Outlook 2013 eingebunden werden. Wenn nun ein Mitarbeiter, welcher das freigegebene Postfach eingebunden hat, eine Abwesenheitsnotiz über "Automatische Antworten" in Outlook erstellt und ein Kunde eine Mail an das freigegebene Postfach sendet erhält der Kunde die Abwesenheitsnotiz des Mitarbeiters. Wie kann ich das verhindern, dass der Kunde Abwesenheitsnotizen einzelner Mitarbeiter erhält, wenn er an das freigegebene Postfach eine Mail schreibt? Die Abwesenheitsnotiz sollte nur für die persönliche Mail Adresse des einzelnen Mitarbeiters gelten.

Ist das für einen reibungslosen Ablauf wirklich nötig? Wir sind halt eine kleinere Firma und da ist es kein großer Auwand bei den paar Clients mal ab und zu bei Änderungen das Zertifikat neu zu installieren. Wenn du mir jetzt aber sagst, dass die Probleme durch das Selbststignierte zertifikat entstehen könnten würde ich natürlich auch ein von einer öffentlichen CA unterschriebenes Zertifikat bestellen.

Also Zertifikatskette ist meiner Meinung nach keine vorhanden, ich bin bei Zertifikaten leider aber echt kein heller Kopf :( . Da das Zertifikat über die Exchange 2013 Weboberfläche erstellt bzw. installiert wurde und das Zertifikat bei allen anderen Domains die darin eingetrage wurden einwandfrei funktioniert denke ich mal es ist unnötig da weitere Zertifikatsketten einzutragen ( Wir haben in der Firma ja auch keine PKI o.ä.) . Der Haken im Analyser wurde gesetzt. Für 443 wurde eine Portweiterleitung am Router erstellt die auf den Exchange zeigt. Unterzeichnungs algorithmus ist : PKCS #1 SHA-1 mit RSA-Verschlüsselung <TLS 1.0 muss ich gleich mal nachgucken , habe jetzt nur grade für die nächsten 2 Std einen Termin.

Das Zertifikat ist selbstsigniert von einer CA im Unternhemen ( Wurde direkt über die Exchange 2013 Weboberfläche erstellt) . Ja der Exchange ist auf dem neusten Stand. PS: Ich habe beim Microsoft Connectivity Test den Haken bei Ignore trust for SSL Aktiviert, daher sollten meinem Verständnis nach ja auch selbstsignierte Zertifikate durch den Test akzeptiert werden.

Ich habe mich geirrt. Es wird über den Connectivitätstest erst versucht auf test.de zuzugreifen. Unter dieser Domain gibt der Test aus The "Autodiscover service couldn't be contacted successfully by any method." Anschließend versucht es der Test über autodiscover.test.de. Da auch dieser Punkt ein rotes Kreuz hatte dachte ich zunächst auch hierüber wäre kein Dienst erreichbar, allerdings wird darüber der Exchange erreicht und es gibt ein Zertifikatsproblem, dass sich wie folgt außert: Schritt 1: Attempting to resolve the host name autodiscover.test.de in DNS. The host name resolved successfully. Schritt 2: Testing TCP port 443 on host autodiscover.test.de to ensure it's listening and open. The port was opened successfully. Schritt 3: Testing the SSL certificate to make sure it's valid. The SSL certificate failed one or more certificate validation checks. Unterpunkte von Schritt 3: The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server autodiscover.test.de on port 443. The Microsoft Connectivity Analyzer wasn't able to obtain the remote SSL certificate. Additional Details: The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation. Es scheint sich also um ein Zertifikatsproblem zu handeln. Nun habe ich auf unserem Exchange nochmal nachgesehen und habe bemerkt, dass im Zertifikat statt "autodiscover.test.de" "AutoDiscover.test.de" eingetragen wurde. Sind Domains die in einem Zertifikat eingetragen wurde Case Sensitive, und könnte das bereits das Problem sein?

Hi, danke für deine Antwort. Auf Strato habe ich bereits zum testen die Subdomain autodiscover.test.de angelegt, welche auf unsere öffentliche IP Verweist. Der Microsoft Test bzw. OWA, Outlook etc. verwenden aus irgendwelchen Gründen aber trotzdem nur "test.de" anstelle von "autodiscover.test.de" für Autodiscovery.