Beiträge von MichaelB

Hallo, wenn ich auf dem Meeting Server einen Konferenzraum anlege und diesen betrete, erscheint oben Links der Hinweis "Waiting for you to start the call...", da ich ich der Besitzer des Raumes bin.

Nun möchten wir den Meeting Server IT Abteilungsintern testen und dorthin unsere tägliche kurze Telefonkonferenz auslagern. Um Audio und Video zu aktivieren müsste ich, da ich den Raum angelegt habe jeden Tag A/V freigeben.

Gibt es eine Einstellung die es ermöglicht jedem beliebigen User, der den Konferenzraum betritt die A/V Funktionalität zu aktivieren ?

Die Übernahme der vpuserinfo habe ich mittlerweile verworfen. Stattdessen starten wir mit einer leeren Liste. Der Sametime Server bietet ja die Möglichkeit die Namen einer "migirierten" vpuserinfo auf LDAP Schreibweise zu ändern, allerdings verbleiben die Gruppennamen/Kontakte in dem Format idXXXXXX:Gruppenname. Schnappt man sich einen Agenten und ändert dies in cn=Gruppenname, werden die auf dem alten Server hinzugefügten Gruppen aufgelöst, allerdings kommt es in einigen Fällen weiter zu Problemen und mit einer Teils manipulierten vpuserinfo möchte ich aus Support Gründen auch nicht arbeiten.

Ich setze das Thema dennoch einmal auf erledigt, da es auch nach Aussage des IBM Supports anders nicht lösbar ist.

Wandler, hat euer neuer Sametime Server den gleichen Namen und hast du das bereits gelöst ? Die Konvertierung der Namen ist wie zuvor genannt kein Problem, allerdings habe ich entweder

- doppelte Gruppen, wenn ich den (korrekten) Namen der neuen Servercommuntiy im Client angebe (cs.firma.com)
oder
- wechselnde kuriose Fehler, wenn ich den DNS Eintrag der alten Servercommuntiy auf den neuen Sametime Server zeigen lasse.

Dazu gibt es die Option auf der Community Seite unter "Server Verwalten" -> "LDAP-Verzeichnis" -> "Namensänderungsaufgaben" bestehende Usernamen via einer hochgeladenen csv Datei zu ändern. Um auf LDAP Schreibweise zu ändern, musst du eine csv Datei mit dem Inhalt "LDAP" erstellen (ohne Hochkomma) und diese auf der Seite hochladen. Im Anschluss musst du dann im Domino Verzeichnis die Datei "stnamechange.cmd" starten. Im Anschluss sind die Namen geändert. Funktioniert wohl auch gescheduled.

Einen Haken hat die Sache - bei mir erscheinen die Gruppen doppelt - die stehen allerdings auch schon in der originalen vpuserinfo.nsf doppelt drinne. Wenn ich mich zu dem neuen / anders benannten SametimeServer verbinde erscheinen die Kontakte doppelt.

Falls da noch jemand eine Idee hat....:-)

Da hatte ich wohl Tomaten auf den Augen. Wenn ich mich mit meinem User an dem neuen Sametime Server anmelde wird ein neuer Eintrag in der View "Storage" angelegt. Dabei ist der "richtige/alte" Eintrag, in dem Format : CN=Vorname Nachname/OU=Abteilung/O=Firma angegeben und der "falsche/neue" Eintrag in dem Format : CN=Vorname Nachname,OU=Abteilung,O=Firma.

Kann das daran liegen, dass ich mich auf dem neuen Server via LDAP und auf dem alten via Domino Directory authentifiziere ?

Also in der View Storage befinden sich in beiden Datenbanken die gleiche Anzahl an Usern (1111), wobei keine davon doppelt aufgeführt ist. In den anderen Views kommen einige User immer mal wieder doppelt vor - die waren allerdings noch nicht mit dem neuen Server verbunden.

Hallo, ich habe einen neuen SametimeServer (8.5.1) installiert. Dieser repliziert bereits die vpuserinfo.nsf mit dem alten Server aus. Wenn ich mich allerdings mit dem SametimeClient an diesem Server anmelde, erscheinen nur die Kontakte, die ich dort manuell hinzugefügt habe. Gibt es denn dort noch weiteres zu beachten ? Mehr Hinweise habe ich leider nicht gefunden.

Danke und Gruß

Mike

Zitat

Also den Fehler kenne ich wenn entweder das Single Sign On nicht richtig funktioniert

Juhuuuu es klappt

Ich habe das vorhandene LtpaToken das ich für iNotes nutze in iLtpaToken umbenannt, die Website Config angepasst, aus der View "$WebSSOConfigs" alle anderen Einträge gelöscht, eine neue LtpaToken Konfig angelegt, im SametimeServer Dokument hinzugefügt und neu gestartet.

Danke für den Hinweis !

Ich hatte zuvor einen falschen DNS Domain Namen in der LtpaToken Konfiguration angegeben und in der Domino Konsole beim Starten des HTTP Tasks eine Fehlermeldung (~Invalid Single Sign On Configuration) erhalten. Das habe ich korrigiert und nun erscheint diese Fehlermeldung nicht mehr.

Das mit dem Hostnamen (RZ2DSCS02v) beim Verbindungsaufbau finde ich seltsam, da ich in der Sametime Console beim Anlegen der Config ausschließlich und nach bestem Gewissen den FQDN verwendet habe, um evtl. DNS Probleme auszuschließen.

Ich habe aber nun einmal in meiner Testumgebung eine fehlerhafte Web SSO Config angelegt und erhalte (glücklicherweise) beim joinen eines Meetings die gleiche Meldung wie im Live System. Da habe ich nun zumindest nun einen Ansatz um den Fehler zu beheben.

OK, danke. Ich habe nun eine Web SSO Confíguration angelegt, den Sametime Server dieser hinzugefügt und in die SSO Configuration (Name DSLTpa) in dem Sametime-Serverdokument aktiviert. (Multiple Servers (SSO))

Ich erhalte beim Starten des Servers auch keine Meldung des HTTP Task, dass eine fehlerhafte SSO Konfiguration exisitert. Allerdings kann ich nur als anonymer User dem Meeting beitreten. Anbei einmal das Java Logdfile des Clients. Was mich noch wundert ist, dass der Client u.a. auf den Namen des Sametimeservers zugreift, statt ausschließlich den FQDN zu verwenden.

Falls jemand noch einen Ansatz hat - ich bin für jeden Hinweis dankbar.

Alles klar, danke. Ich habe gerade einmal "Single Server" Authentication eingerichtet, allerdings tritt der Fehler noch immer auf :-?

In der Testumgebung hat das alles so reibunglos funktioniert......

Benötige ich denn eine SSO Konfiguration, wenn ich mich an einem Sametime Server via HTTP authentifiziere und im Anschluss auf dem selben Server auf die stconf.nsf zugreife, um an einem Meeting teilzunehmen ?

Ich habe nämlich das gleiche Problem - als Anonymer User kann ich jedoch dem Meeting beitreten !?

Hallo, ich nutze eine globale Policy, die Mailsettings enthält, die über die Zeit gewachsen sind. Nun möchte ich an die ausgehenden Mails bestimmter Benutzergruppen eine Fußzeile anhängen. Sehe ich das richtig, dass es dazu reicht eine neue Explizite Mailpolicy zu bauen, überall den "Inherit" Haken zu setzen und diese den Usern zuzuordnen, damit die Einstellungen aus der globalen Policy ebenfalls übernommen werden ?

Danke und Gruß

Michael

Die betroffenen Server laufen glücklicherweise bald aus der Wartung.

Wäre aber interessant zu erfahren, was Dell entgegnet, wenn wir ihnen mitteilen würden, dass wir die betroffenen Server tauschen möchten, weil der Redirect einer Website nicht funktioniert

Der Redirect funktioniert übrigens auch dann nicht, wenn ich einen der funkionierenden Server (davon gibt es zwei aus dieser Serie) auf einen der Problemserver image. Da diese demnächst aber ohnehin getauscht werden, lohnt da eine weitere Suche nicht mehr.

Es ist zum Mäusemelken......

Der Browser weigert sich glänzlich den MetaRefresh auf die MailDB auszuführen und ich hab diesen auch schon auf das wesentliche reduziert :

<meta http-equiv="refresh" content="2; url=http://cl3-webmail.firma.com/Pfad/Zur/MailDB/db.nsf" />

Mit allen anderen Browsern auf dem Server (IE6,7, FireFox) funktioniert das. Ich habe die HTML Seite die beim Redirect erzeugt wird einmal statisch auf dem gleichen Domino Server abgelegt und wenn ich diese Seite direkt aufrufe, wird der MetaRefresh ausgeführt (ist auch erlaubt in den Security Einstellungen). Hab auch schon den Meta Refresh durch JavaScript ersetzt.

Kurioserweise funktioniert der Meta Refresh anderer Seiten.

Das tritt also nur auf Dell (Terminal)Servern einer bestimmten Serie mit dem IE8 auf, nachdem der Domino Server dem Browser nach der Authentifizierung eine Website mit einem Meta Refresh auf die MailDB übergibt. Auch im Kompatibilitätsmodus funktioniert das nicht.

Kann ich denn den Logging Level des HTTP Tasks erhöhen ?

Die Server stammen alle aus dem gleichen Image und kurioserweise funktioniert der Redirect nur auf Dell Servern einer bestimmten Serie nicht - das ist aber bisher das einzige Problem, das wir mit diesen Servern haben

Hallo, ich habe auf Basis der iwaredir.ntf eine redirect-db auf einem Domino Server (8.5.1) eingerichtet.

Von manchen Terminal Servers aus funktioniert der Redirect nicht.

Ich authentifiziere mich und im Anschluss passiert nichts weiter.

Benutze ich den Zurück Button um zu meiner Startseite zurückzukehren und im Anschluss den VorwärtsButton um wieder eine Seite vorwärts zu gehen (zu der iwaredir.nsf) werde ich auf Grund der noch gültigen Anmeldeinformationen redirektet.

Hat da jemand eine Idee was das sein könnte ?

Gruß

Michael

Hast du das gelöst, indem du den Sametime Server auf HTTPS umgestellt hast ?

Sofern die Pfade der repliken identisch sind, kannst du auf beiden Servern im Serverdokument den gleichen Hostnamen eintragen.

Intern legst du im DNS den Host mit der internen IP Adresse an. Extern im DNS halt mit der externen IP.

Sofern du dich vor dem Öffnen der weiteren DB ein zweites mal authentifizieren musst, kannst du SSO einrichten :http://www.tecchannel.de/serve…1655/web_sso_fuer_domino/

edit : ticken zu langsam

Das funktioniert sofern folgende Einstellung im Security Tab des Serverdocumentes gesetzt ist......