(MircoT) non ha senso che un fixup risolva il problema di autorizzazione, per altro su un solo db.. c'è qualcosa di sbagliato sotto. andrebbe vista la conf pezzo per pezzo.
quanto agli archivi vecchi: il link presente dentro alla posta apre quello indicato dalla policy, quindi quello nuovo.
quelli vecchi vanno aperti a mano dal workspace di notes.
sapendo che c'erano degli archivi locali (che andrebbero impediti da policy, in quanto, se il pc si rompe o lo rubano, perdo dei grossi pezzi di posta senza possibilità di recupero) bisognava mettere quegli archivi locali sul server in modo che poi la policy continuasse ad archiviare su quelli. bisognava incastrare un po' cose, ma si poteva fare. adesso devono rimanere separati, a meno che non si voglia copiare tutti i doc (cartella per cartella) dell'archivio locale sull'archivio sul server... una bella rottura.
(greghph) si ho riavviato il server
poi ho provato a fare un fixup prima del compact -a
su un DB ha funzionato....rimane il problema sempre su un altro db (tra quelli con la policy assegnata, e non vorrei avere lo stesso problema ad ogni db a cui assegno la policy ;-( )
altra domanda...mi son accorto che seguendo la procedura per l'archiviazione su server, se l'utente ha gia degli archivi "locali", quando tenta di aprirli, viene generato un errore di percorso file non trovato(infatti notes cerca di aprire il db dal percorso del server e non da quallo locale). il problema è risolvibile?
(MircoT) dopo aver modificato il doc del server, lo hai fatto ripartire?
quelle son cose che legge raramente. o alla partenza del server.
per altro il db di posta cifrato con l'id dell'utente non aiuta.
(greghph) niente da fare
ancora errore
(greghph) Ciao MircoT
si avevo dimenticato la S nel nome del gruppo ;-)
ti rispondo alle tue domande
l´archivazione come è impostata? (verso lo stesso server)
il db di posta è cifrato con l´id dell´utente? (SI)
nel doc del server/security c´è il gruppo localdomainservers nel campo degli autorizzati a creare nuovi db? (effettivamente mancava il gruppo localdomainservers nel campo Create databases & templates...riprovo e ti faccio sapere)
Thx
(MircoT) localdomainserver[B]s[/B]
l'archivazione come è impostata?
verso lo stesso server? verso server diverso?
il db di posta è cifrato con l'id dell'utente?
nel doc del server/security c'è il gruppo localdomainservers nel campo degli autorizzati a creare nuovi db?
(greghph) ciao MircoT
avevo gia controllato la presenza del LocalDoainServer nell ACL (UserType=Server Group; Access=Manager)
ma mi segnala lo stesso l'errore e non mi archivia le email dal db di posta
grazie
(MircoT) credo sia un errore "farlocco".
controlla che nell'acl dei db ci sia il gruppo localdomainservers e sia manager gruppo di server.
l'accesso full access non serve visto che con il comando da console è il server che esegue l'azione e non il tuo id.
(fmarzolo) Forse un po' tardiva come risposta, io ne ho fatto svariati senza problemi. Hai per caso modificato qualcosa nella configurazione? Hai un messaggio nella console alla partenza del task SMTP, oppure al tentativo di connessione con telnet (o putty) ?
(fmarzolo) Sono alle prese con questo messaggio di Traveler 9.0.1.18 in configurazione HADR con MS SQL Express.
[00E8:00AB-11D4] 28/08/2017 11.27.16 Traveler: MS SQL Server JDBC driver version mismatch detected for Java 1.8.0. Remove JDBC driver D:\Lotus\domino\Traveler\lib\sqljdbc4.jar from system, reconfigure with correct JDBC driver and restart. For more information see technote: http://www.ibm.com/support/docview.wss?uid=swg21999188
[00E8:00AB-11D4] 28/08/2017 11.27.16 Traveler: The overall status of IBM Traveler is Red.
il link proposto (Requirements for running IBM Traveler on Domino 9.0.1 FP8 and later releases) punta ad una pagina MS che consente il download del driver JDBC aggiornato con le relative istruzioni per l'installazione. Al termine si prende il driver "sqljdbc42.jar" e si mette in Domino\Traveler\lib.
Occorre ricordarsi di cancellare il precedente driver "sqljdbc4.jar".
Fatto l'aggiornamento però, il messaggio non se ne va.
Qualcuno è gia passato in questa situazione?
(greghph) ciao
ho seguito questa bellissima guida http://www.dominopoint.it/Dominopoint/dominopoint_blog.nsf/dx/2204200921.12.44CMEQJJ.htm per creare una policy di archiviazione
ho assegnato la stessa ad alcuni utenti ma lanciando il comando lo compact -a mail\nomedb.nsf (singolarmente sui db con policy assegnata) su alcuni mi da l'errore di autorizzazione
ho eseguito quindi l'accesso con full access administration ma niente...sempre su alcuni db segnala errore
la cosa strana è che comunque nella dyr "archive" crea sia il db a_ che il file di log l_
la release è 9.0.1FP5
grazie
(LucaP) Boh a me il sistema più semplice sembra lavorare con le Rest generiche se notifica il cambio.
(simone81) Ciao,
allora queste le ipotesi valutate per aprocciare il problema
soluzione 1 : Utilizzare il DB Resource e reservation per leggere gli appuntamenti e creare/editare appuntamenti dall'esterno.
NON FATTIBILE per via delle REST API, cioè il RRDB non espone le CalendarAPI. Lavorare solo con le DataService API è infattibile (non mi dilungo sui motivi)
soluzione 2: Utilizzare uno SharedCalendar. Questo espone le Calendar API (è un DB di tipo mail calendar VERO).
Le prenotazioni sarebbero create per conto del Chair che è l'utente a cui appartiene lo SharedCalendar. Io Simone creo un'appuntamento tramite SharedCalendar e il Chair non sono io. Viene riportato sul meeting Chair=utente Shared Calendar, sentby: Simone
Quindi si, utilizzando una utenza adoc (associata allo shared calendar) avrei la possibilità di interventire sui meeting, leggerli, crearli, editarli etc...
I problemi per la soluzione 2 sono:
- gli utenti aziendali devono adattarsi ad un nuovo modo di prenotare gli appuntamenti, non creandoli dal loro calendario personale, ma dallo shared calendar
(ho scoperto comunque che esiste un modo per fare uno shortcut del calendario sherato all'interno del calendario personale, in composizione l'utente deve fare New > Events for other Calendars > Calendario Condiviso. Bella possibilità, ma comunque una "novità" che non tutti potrebbero approvare)
- Io Simone che sto prenotando tramite SharedCalendar devo ricordare di mettere me stesso tra i partecipanti del meeting. Altrimenti la credo per gli altri attendees ma non per me. Molto brutto
- Io Simone che mi sono ricordato di mettermi tra gli invitati, ricevo comunque l'email dell'invito (certo!!! il Chair non sono io, è un altro!!!) e devo accettare l'appuntamento che io stesso ho creato. Bruttissimo!!!
Ho provato a "giocare" con le delegations e gli automatismi di autoprocessing sullo shared calendar, ma non risolvo in nessun modo questo brutto scenario.
Credo che valuteremo altre strade più "CUSTOM", abbandonando la possibilità di utilizzo delle REST...
(LucaP) IMHO se non hai un chair non puoi modificare.
Secondo me se metti un utente fittizio come partecipante puoi proporre altre date ma il è il chair che decide.
Non ho mai provato ma mi sorge qualche dubbio che anche su exchange o gmail [U]come utente normale[/U] si possano modificare le date di una riunione concordate da altri utenti al più possono proporre altre date.
Anche usando le REST API sarebbe una incoerenza.
Cmq qua c'è a descrizione dei campi e del processo
https://www-10.lotus.com/ldd/ddwiki.nsf/dx/cs_schema_toc
prova se modificando la risorsa i partecipanti vengono notificati che per domino è il modo corretto.
(simone81) "integrazione di un sistema esterno al sistema di reservations delle resources di un server Domino".
Sostanzialmente leggere e scrivere e creare reservations su risorse condivise (meeting room, attrezzatuture etc...).
Lavorando con le REST API non riesco a lavorare con le Calendar API perchè non sono esposte sul contesto del DB Room&Reservations DB.
Cercavo quindi vie alternative per ottenere ciò di cui ho bisogno.
Grazie
(LucaP) Scusa ma hai spiegato come vuoi fare una cosa ma non hai detto cosa vuoi fare esattamente.
(simone81) Ciao Luca, credo tu abbia centrato l'argomento, ma purtroppo non mi basta per risolvere.
Si è vero che dovrei lavorare sul calendario del Chair della reservation per riuscire a modificare un appuntamento, eliminarlo o crearne uno ex-novo.
Però ovviamente non potrò mai avere accesso ai calendari di tutte le utenze interne all'azienda.
Da quanto ricordo e per quanto mi stanno confermando anche in altre realtà aziendali, lo standard per gestire le risorse e le reservation è appunto il Resource Reservation Database.
Ma questo RRDB purtroppo non espone le REST Calendar API e ho già visto che lavorare su questo DB con le DAS, manipolando i campi è un delirio.
Ho fatto qualche prova e riesco anche ad editare o cancellare un appuntamento, ma non lavorando nel contesto di un vero e proprio Calendar DB con API non di tipo Calendar, mi vado a perdere tutti i meccanismi di Controllo disponibilità orari, notifiche agli utenti e quant'altro è insito all'interno di una vera applicazione Calendar. Io non vorrei integrarmi in questo modo e anche da alcune ricerche in rete ho visto che è decisamente sconsigliato.
Se un cliente ha impostato la configurazione delle risorse tramite il Resource & Reservation DB è molto difficile convincerlo a cambiare configurazione.
Una possibilità che sto valutando è mettere in piedi un DB che funga da Shared Calendar condiviso per la prenotazione delle risorse.
Ho fatto un test in ambiente lab e funziona come concetto: creo uno Shared Calendar dal quale posso prenotare le risorse. Imposto eventualmente le Access Delegation su questo calendario condiviso.
Con una utenza qualsiasi accedo allo shared calendar e effettuo una reservation per una risorsa. La reservation creata viene correttamente notificata agli attendees e va a finire all'interno del ResourseReservationDB. A questo punto però ho anche il calendario condiviso che mi contiene tutti gli appuntamenti e posso leggere e scrivere tramite REST Calendar API nel contesto di quel database.
Il Chair dell'appuntamento però è lo Shared...
(LucaP) Premetto che non ho mai usato le REST API
Per le calendar API dovrebbe funzionare come sul client o da Web,
Quindi per creare/modificare/cancellare una reservation devi farlo modificando la riunione nel database di posta del Chair in questo modo tutti i partecipanti verranno aggiornati.
In pratica ogni meeting ha un presidente e solo lui (o chi ha la delega sul suo Calendario) possono modificarlo con le relative notifiche ai partecipanti.
Nella logica di Lotus non ha molto senso che una stanza modifichi una riunione dell'amministratore delegato.
Se invece vuoi accedere al db delle reservation e manipolare gli oggetti in questo devi usare direttamente le DAS e sapere il significato dei campi (credo siano documentati) ovviamente sarà tuo compito notificare le modifiche ai partecipanti.
Credo che per fare questo l'utente usato debba avere acceso editor al DB.
Freebusy come dice il nome espone i dati di free e busy time dei partecipanti ma non server a manipolare la riunione.
IMHO se fai questo
"sto studiando un´integrazione di un sistema esterno al sistema di reservations delle resources di un server Domino. "
il modo corretto è mandare una mail formattata opportunamente al Chair che accetterà o declinerà oppure creare un utente fittizio che faccia da chair e da li mandare le proposte o le modifiche.
http://www-01.ibm.com/support/docview.wss?uid=swg27009325
(simone81) Ciao a tutti DominoMans,
sto studiando un'integrazione di un sistema esterno al sistema di reservations delle resources di un server Domino.
A partire da Domino 9.0.1 ho scoperto di recente che IBM mette a disposizione delle API REST da abilitare sul server. Sono:
- Data Services (gestisce in generale le operazioni sui documenti Notes)
- Mail Services
- [B]calendar Services[/B]
- Core Services
io mi sto concentrando sulle Calendar Services.
In ambiente LAB ho configurato un Domino server con 3 utenze Demo e relativi DB di posta e calendario.
1 Utenza di Admin con relativo calendario/email
Ho configurato le risorse creando un [B]Resource Reservation Database[/B]. Il template dal quale son partito è: StdR9ResourceReservation
Quindi da client Notes con una utenza riesco a fare una reservation di una resource (diciamo una meeting room ad esempio).
Questa reservation viene resa visibile all'interno di questo Resource e reservation Database.
Quindi ho abilitato lato server e anche lato DB R&R i servizi necessari (Data Service e Calendar Service) e riesco quindi a esporre le API REST.
Fin qui tutto bene.
Ora però devo capire come e cosa effettivamente richiamare per ottenere ciò che desidero.
Io ho bisogno ad esempio di creare nuove reserations dall'esterno a Domino e modificare reservation esistenti magari create da un utente interno a Domino (profilo aziendale).
Qui la scoperta: [U]Il Resource Reservatin Database [B]NON ESPONE[/B] il Calendar Service[/U]. Se do autorizzazioni all'utente Admin con tutti i privilegi possibili sul DB, riesco correttamente ad autenticarmi chiamando la Data Service API, ma assolutamente non la Calendar API che non è esposta.
Credo che la Calendar API sia solo disponibile nel contesto di un VERO mail-in database(calendar), come quello di un utente, e non per questo "atavico" Resource&Reservation DB.
Come me la posso cavare?
Su sistemi come Exchange o Gmail una risorsa è associata ad un vero e proprio indirizzo di posta e relativo calendario, quindi in maniera equivalente...
(LucaP) Come sarebbe a dire "load updall -R mail\names.nsf"
Sei sicuro che i due server siano nello stesso dominio e non cross certificati ?
Se non si fanno configurazioni particolare il names è nella root del server.
Altra cosa come viene fatta la completion nelle due sedi ?
se scrivi Magazzino F9 ti propone entrambi gli indirizzi ?
Hai controllato che gli shortname non siano uguali ?
(Gianluca_Boff) Niente da fare, viste aggiornate, ma ho sempre lo stesso problema. Ho verificato dentro la names, ma non trovo doumenti in cui compare l'indirizzo magazzino@xxx.com
(MircoT) no, crea l'indice esteso dalle proprietà del db.
non blocchi nulla.
(Gianluca_Boff) Giusto per non fare cose sbagliate, quindi lancio una load updall -R mail\names.nsf?
Ma non rischio di bloccare il server, credi sia meglio che la lanci in pausa pranzo?
Grazie
(MircoT) a questo punto indicizza il names.nsf e fai una ricerca per capire quali sono i doc con gli indirizzi giusti ed eventualmente i doc con l'indirizzo errato.
cerca sui doc persona, sui gruppi, sui mailin-db, sui doc di dominio.
potrebbe esserci qualcosa sul server di sede 1 che non viene replicato sul server di sede 2.
a volte si incasinano le history di replica e qualcosa non passa.
(Gianluca_Boff) nel notes.ini ho solo NAMES=names.nsf, quindi direi che non ci sono rubriche concatenate.
(MircoT) quello che c'è nel tab notes.ini settings del doc di conf del server non è esaustivo.
devi controllare il fiel notes.ini nella dir programma di domino.
cerca una riga names= e vedi cosa c'è dopo l'uguale.
(Gianluca_Boff) Le prove le ho fatto da 4 client diversi in sede2, per scrupolo però ho verificato uno dei client, non sono presenti contatti strani.
I parametri Directory assistance database name: e Name of condensed directory catalog on this server: sono vuoti quindi direi che non ho la directory assistance attiva e non ho una dir condensata.
Per la rubrica agganciata, sul tab NOTES.INI Settings non vedo parametri che a livello di nome facciano pensare a questa cosa, ma purtroppo ho ereditato i due server e non ho grandi conoscenze di domino.
(MircoT) hai fatto le prove dallo stesso client?
se hai usato client diversi, controlla i contatti normali e i contatti recenti del client "problematico"
altra cosa: per caso il server 2 ha la directory assistance attiva?
oppure una rubrica agganciata via riga names sul notes.ini
oppure una dir condensata configurata e attiva?
(Gianluca_Boff) Si, le rubriche sono in replica
(MircoT) i 2 server replicano tra loro la rubrica indirizzi dell'organizzazione (names.nsf)?