Ivan Salvade’

Il mio punto di vista su Virtualizzazione, Sicurezza, Messaggistica, Network Management…

  • Ivan

    248418_467427256623661_1655875885_n.jpg
  • Abbonati

  •  

    ottobre 2017
    L M M G V S D
    « gen    
     1
    2345678
    9101112131415
    16171819202122
    23242526272829
    3031  
  • Tag Cloud

Gestione dei futuri Service Pack da parte di Microsoft

Scritto da Ivan Salvade' il 25 febbraio 2014

Questo articolo non è basato su comunicati ufficiali da parte di Microsoft, ma su ”rumors” che ormai sempre più frequentemente ascolto a riguardo dei futuri Service Packs dei sistemi operativi Microsoft.

Sembra che Microsoft abbia ormai scelto di non produrre più interi Service Pack per i propri sistemi operativi (client e server), ma di offrire solo i singoli aggiornamenti che tipicamente ci arrivano il secondo martedì di ogni mese.

La scelta è stata presa per evitare di impegnare notevoli risorse umane nella creazione e soprattutto nel testing dei Service Pack, a discapito dello sviluppo dei nuovi prodotti.

Questa scelta può essere un beneficio anche per le grandi aziende, che tipicamente hanno già in essere un’infrastruttura automatizzata di distribuzione degli aggiornamenti (per esempio tramite WSUS o Configuration Manager), ma, nel caso di uscita di un intero Service Pack, sono spesso costrette a rifare completamente le immagini base di riferimento, ad eseguirne opportuno testing, e ad implementare una nuova fase di deploy/aggiornamento.

Infatti, già da tempo molta gente è in attesa di un nuovo service pack di Windows 7 (il Service Pack 2), ma di questo non esiste nemmeno l’ombra, neanche sul sito di Beta Connect.  E nessun service pack è mai stato creato neanche per Windows 8 o per Windows Server 2012.

Diverso è il discorso, invece, per i prodotti di backoffice : è da poco stato prodotto, per esempio, il Service Pack 1 per Office 2013, Exchange 2013, SharePoint 2013.  Sarà a breve disponibile a tutti, anche tramite Windows Update.

Vediamo se questi rumors saranno confermati nel futuro, oppure Microsoft continuerà a produrre i Service Pack per i sistemi operativi, magari a ridotta frequenza.

  • Share/Bookmark

Pubblicato in Cafè, Gestione dei Sistemi | Nessun commento »

Configuration Manager 2012 Support Center

Scritto da Ivan Salvade' il 12 febbraio 2014

E’ disponibile in versione beta dal 4 febbraio 2014 il Configuration Manager 2012 Support Center.

E’ un utilissimo strumento per raccogliere dettagliate informazioni sui client Configuration Manager installati nelle vostre reti, e per eseguirne il troubleshooting in caso di problemi.

Il tool è disponibile in libero download, previa registrazione, dal sito di beta testing di Microsoft, al seguente url :

https://connect.microsoft.com/ConfigurationManagervnext/Downloads/DownloadDetails.aspx?DownloadID=52192

Questo tool, creato da Microsoft, si affianca ad un altro utile strumento di terze parti, già da tempo presente sul mercato, il “Client Center for Configuration Manager”, la cui ultima release è disponibile gratuitamente al seguente url :

http://sccmclictr.codeplex.com

Anche il Client Center è utilissimo per la risoluzione dei problemi sui client, e permette l’esecuzione di una miriade di controlli e comandi in remoto sui client stessi : assolutamente consigliato!!

  • Share/Bookmark

Pubblicato in Gestione dei Sistemi, System Center Configuration Manager 2012 | Nessun commento »

Nuova certificazione Microsoft su Hyper-V e System Center

Scritto da Ivan Salvade' il 27 novembre 2013

Microsoft ha reso disponibile una nuova certificazione riguardante i propri software di virtualizzazione.

La certificazione si chiama : “Microsoft Certified Specialist : Server Virtualization with Hyper-V and System Center”.

Per ottenere la certificazione, è necessario superare il seguente esame, disponibile dal 05 novembre 2013 :

Exam 74-409 “Server Virtualization with Windows Server Hyper-V and System Center”.

Per la preparazione dell’esame, è già disponibile un intero corso ILT (Instructor Led Training) di 5 giorni, livello tecnico 300 :

MOC 20409 “Server Virtualization with Windows Server Hyper-V and System Center”

Sia l’esame che il corso trattano di argomenti aggiornati all’ultima release dei prodotti Microsoft inerenti la gestione di ambienti virtualizzati, e cioè Hyper-V 2012 R2 e la suite System Center 2012 R2.

Le informazioni sull’esame 74-409 si trovano al seguente link :

http://www.microsoft.com/learning/en-us/exam.aspx?id=74-409

Le informazioni sul contenuto del corso 20409 sono reperibili a quest’altro link :

http://www.microsoft.com/learning/en-us/course.aspx?ID=20409A&Locale=en-us

Buono studio :-)

  • Share/Bookmark

Pubblicato in Cafè, Corsi e Certificazioni | Nessun commento »

PPE Bootcamp live da Londra…

Scritto da Ivan Salvade' il 30 ottobre 2013

Mi trovo in questi giorni a Londra per partecipare ad un seminario Microsoft, il “Partner Practice Enablement Bootcamp”, seminario dedicato alla virtualizzazione e al cloud.

Speaker : Matt McSpirit, Senior Technical Product Marketing Manager di Microsoft.

Un estratto degli argomenti trattati :

  • le nuove features di Hyper-V in Windows Server 2012 R2
  • Gestione Cloud con VMM
  • Panoramica di System Center 2012 R2
  • Windows Azure
  • Soluzioni IaaS con Windows Azure Pack
  • Workplace Join, ADFS, Work Folders, RDS e altre novità di Windows Server 2012 R2
  • User & Device Management con CM 2012 e Windows Intune
  • …. tanto altro

Riproporrò in Italia questo seminario.  Ci sono già due sessioni programmate, realizzate in collaborazione con Pipeline : dal 12 al 14 novembre nella sede Microsoft di Peschiera Borromeo, e dal 20 al 22 novembre nella sede Pipeline di Padova.

La partecipazione è riservata ai Partner e gli inviti sono gestiti direttamente da Microsoft.

Un saluto da Londra …. :-)

Aggiornamento

News del 4 novembre : la sessione di Peschiera Borromeo risulta già completa.  Ci sono ancora posti per la sessione di Padova.

  • Share/Bookmark

Pubblicato in Cafè | Nessun commento »

Limitare l’uso di RAM su Exchange Server 2010

Scritto da Ivan Salvade' il 20 ottobre 2013

By design, in Exchange Server 2010 il servizio Information Store (store.exe) tende ad occupare quanta più memoria possibile sul server.

Questo è accettabile : l’uso della RAM, piuttosto che del paging su disco, non fa altro che migliorare le performance del server Exchange.

Però ho notato alcuni casi in cui l’utilizzo di RAM da parte di Exchange è addirittura eccessivo : in un caso limite, addirittura, la completa assenza di RAM libera sul server, causava il non corretto funzionamento del servizio “User Profile Service”, responsabile, tra le altre cose, delle fasi di logon e logoff degli utenti.  Il problema era grave, in quanto non era più possibile un logoff ordinato dell’utenza amministrativa, neanche dopo aver comandato un restart del server.   Il brutale workaround era quello di spegnere e riaccendere fisicamente il server.

In casi come questo, diventa necessario intervenire sul sistema, espandendo fisicamente la RAM del server, oppure limitandone l’utilizzo da parte di Store.exe.

Tecnicamente, la RAM usata da Store.exe è in gran parte dedicata al “Database Cache” : più è alta la cache del database, minori sono le operazioni di lettura sul database, e maggiore è il numero di database supportabili da Exchange.

La grandezza della Database Cache è indicati dai seguenti contatori di performance (rilevati su Exchange 2010 SP3), che riporto, per comodità di consultazione, sia in lingua italiana che inglese :

  • Database di MSExchange\Dimensione Cache del Database (MB) (Information Store)
  • Database di MSExchange\Dimensione Effettive della Cache del Database (MB) (Information Store)
  • MSExchange Database\Database Cache Size (MB) (Information Store)
  • MSExchange Database\Database Cache Size Effective (MB) (Information Store)

Il primo dei due contatori indica la dimensione della cache del database, così come ”comandata” dal default di sistema o da opportuni parametri di configurazione (che vedremo tra poco).

Il secondo dei due contatori indica l’effettiva dimensione della cache del database.

Ecco un esempio di monitoraggio dei due contatori, su un server Exchange 2010 SP3 con 24 GB di RAM, e la cache del database impostata tra 3 e 4 GB :

cache1.jpg      Fig. 1 : monitoraggio dei parametri (clicca sulla figura per ingrandire)

I parametri di configurazione della Database Cache si trovano in Active Directory, e sono gestibili tramite Adsi Edit.  Bisogna collegarsi alla Configuration Partition di Active Directory, e posizionarsi nel seguente nodo :

CN=InformationStore,CN=NomeServerMailbox,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=NomeOrganizzazione,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Dominio,DC=SuffissoDominio

Nelle proprietà dell’oggetto “CN=InformationStore”, troveremo i seguenti attributi :

  • MSExchESEParamCacheSizeMin
  • MSExchESEParamCacheSizeMax

Questi due parametri sono per default non impostati (<Not Set>) : questo significa che Store.exe gestirà in maniera completamente dinamica il consumo di RAM.  Quindi, salvo situazioni di richiesta di memoria da parte di altre applicazioni, è lecito attendersi che Store.exe espanda progressivamente il suo consumo di RAM, fino ad occupare tutta quella disponibile sul server.

E’ però possibile compilare questi parametri con opportuni valori, per garantire un controllo ottimale della grandezza della cache del database.

I valori devono essere assolutamente multipli di 32k (ovvero 32768 bytes), in quanto Exchange 2010 lavora con pagine di RAM da 32k (a differenza di Exchange 2007, che lavorava con pagine di RAM da 8k).

Esistono delle soglie minime (sotto le quali non bisogna assolutamente scendere) e delle soglie di default.  Sono riportate al seguente articolo TechNet :

http://technet.microsoft.com/en-us/library/ee832793.aspx

Rispettando le soglie stabilite dall’articolo, vediamo ora come è possibile regolare in maniera personalizzata la dimensione della cache.

Innanzitutto bisogna sempre lavorare su valori multipli di 32k.

Si decide a quanti Gb si vuole limitare l’uso della cache, si trasforma il valore in Kb, e si divide per 32 (ricordando che 1 GB=1024 Mb, e 1 Mb=1024 Kb).

Quindi, supponendo di voler limitare la cache a 8 Gb, il calcolo è il seguente :

8 Gb X 1024 = 8192 Mb X 1024 = 8.388.608 Kb / 32 = 262.144 (questo è il numero di pagine di RAM da 32 Kb da indicare ad Exchange).

Ora bisogna capire come impostare questo valore nei due parametri MSExchESEParamCacheSizeMin e MSExchESEParamCacheSizeMax.

N.B. : una volta modificati i parametri, bisogna sempre eseguire un restart del servizio “Microsoft Exchange Information Store” (”Archivio Informazioni di Microsoft Exchange”). Non serve un restart dell’intero server.

Lo scopo del mio esempio è impostare la grandezza della cache del database in modo che non superi gli 8 GB circa di RAM.

Eseguirò tre prove, con relativi campionamenti dei contatori detti in precedenza :

  1. Impostare solo il parametro MSExchESEParamCacheSizeMax
  2. Impostare entrambi i parametri uguali
  3. Impostare MSExchESEParamCacheSizeMax in modo che sia superiore a MSExchESEParamCacheSizeMin

Prova 1 : impostare solo il parametro MSExchESEParamCacheSizeMax  al valore 262.144

Ecco in Fig. 2 l’impostazione del parametro MSExchESEParamCacheSizeMax a 262.144 (cioè 8 GB di RAM di limite), lasciando il parametro MSExchESEParamCacheSizeMin non impostato :

cache2.jpg   Fig. 2 : un solo parametro impostato

Ed ecco in Fig. 3 l’esito del monitoraggio dei contatori, dopo un restart del servizio Information Store e un periodo di almeno 20 minuti per l’assestamento dei valori :

cache3bis.jpg    Fig. 3 : clicca per ingrandire

Si nota come entrambi i parametri si attestino intorno ai 14 GB, cioè più o meno al valore massimo raggiungibile su questo server.  In questa situazione, quasi tutti i 24 GB di RAM totali del server risultano in uso.   Non è quindi ciò che si voleva.

Prova 2 : impostare entrambi i parametri allo stesso valore

Ecco in Fig. 4 l’impostazione di entrambi i parametri al valore 262.144 (cioè 8 GB di RAM di limite) :

cache4.jpg Fig. 4 : parametri con lo stesso valore

Ed ecco in Fig. 5 l’esito del monitoraggio dei contatori, dopo un restart del servizio Information Store e un periodo di almeno 20 minuti per l’assestamento dei valori :

cache5bis.jpg   Fig. 5 (clicca per ingrandire)

In questo caso si nota come entrambi i parametri si attestino intorno ai 2 GB di RAM, che rappresentano all’incirca la dimensione minima possibile della cache del database su un server Exchange.   Quindi, anche in questo caso non abbiamo raggiunto i risultati previsti.

Prova 3 : impostare MSExchESEParamCacheSizeMax ad una valore superiore rispetto a MSExchESEParamCacheSizeMin

Ecco in Fig. 6 l’impostazione di MSExchESEParamCacheSizeMax a 262.144 (cioè 8 GB di RAM) e di MSExchESEParamCacheSizeMin ad un valore inferiore : 229.376 (cioè 7 GB di RAM) :

cache6.jpg Fig. 6 : msExchESEParamCacheSizeMax con valore superiore

Ed in Fig. 7 il solito esito del monitoraggio dei contatori, dopo un restart del servizio Information Store e un periodo di almeno 20 minuti per l’assestamento dei valori :

cache7.jpg      Fig. 7 : clicca per ingrandire

Questa volta si nota che la dimensione comandata della cache si assesta intorno ai 7 GB (il parametro MSExchESEParamCacheSizeMin) e quella effettiva intorno ai 9 GB (circa 1 GB oltre il valore del parametro MSExchESEParamCacheSizeMax) : questa grandezza massima, però, lasciando lavorare per parecchie ore il server Exchange, si attesterà mediamente intorno agli 8 GB previsti, come mostrato in Fig. 8 :

cache7b.jpg      Fig. 8 : clicca per ingrandire

Con questi settaggi raggiungiamo finalmente i risultati voluti, cioè la regolazione della cache del database tra due ben precisi valori (tra 7 e 8 GB, nel mio esempio).

La conclusione è quindi questa :  non è sufficiente compilare solo il parametro MSExchESEParamCacheSizeMax (come alcuni articoli su Internet riportano), ma devono essere compilati entrambi i parametri, ed in modo che MSExchESEParamCacheSizeMax sia superiore a MSExchESEParamCacheSizeMin.  Qualunque altra combinazione dei due parametri non porta ai risultati voluti.

Buona regolazione!!  :-)

  • Share/Bookmark

Pubblicato in Exchange Server 2010 | 2 Commenti »

Bloccare lo spam interno (dal proprio dominio di posta) in Exchange Server

Scritto da Ivan Salvade' il 7 ottobre 2013

Questo articolo si applica a : Exchange Server 2007, 2010, 2013

Capita spesso di ricevere mail di spam, dove l’indirizzo di posta del mittente rappresenta un’utenza vostra interna (es. Nomeutente@NomeVostroDominioDiPosta ) o addirittura rappresenta voi stessi (cioè ricevete spam da voi stessi!!!).

Questo capita perché gli spammer sono riusciti ad eseguire lo spoofing del vostro indirizzo di posta (o di quello di altre persone nella vostra azienda), inserendolo poi nelle intestazioni SMTP delle mail di tipo spam che essi lanciano.

Con i software antispam professionali, tipicamente, ci si difende agevolmente da questo tipo di spam.  Ma per chi vuole utilizzare esclusivamente i filtri antispam nativi (o altre impostazioni) di Exchange 2007/2010/2013, la difesa non è così immediata.

L’impostazione di default dei server Exchange è quella di ricevere qualunque mail proveniente dai cosiddetti “Domini Accettati” (”Accepted Domains”), inseriti nella configurazione del trasporto.  E il vostro dominio pubblico di posta è sicuramente configurato come ”Dominio Accettato”.  Inoltre, il Connettore di Ricezione che riceve mail da Internet è sicuramente configurato a non richiedere l’autenticazione ai mittenti delle mail (giustamente), altrimenti non si riceverebbero più mail dal mondo intero!

I Connettori di Ricezione di Exchange, però, hanno numerose altre autorizzazioni particolari, che si possono vedere e modificare solo con comandi di powershell.

Ecco un comando esemplificativo per visualizzare tutte le autorizzazioni assegnate ad un normale Connettore di Ricezione configurato per ricevere posta da Internet :

Get-ReceiveConnector “Nome Connettore” | Get-AdPermission | Ft User,AccessRights, ExtendedRights -Autosize

La particolare autorizzazione che ci interessa è la “MS-Exch-SMTP-Accept-Authoritative-Domain-Sender” assegnata all’identità speciale “Anonymous Logon”.  Questa autorizzazione permette a qualunque persona non autenticata (quindi anche agli spammer) di collegarsi al Connettore di Ricezione in oggetto, di dichiarare il vostro dominio di posta nell’intestazione SMTP “Mail From:”, e di essere comunque accettati.

Questa autorizzazione è assegnata ad un Connettore di Ricezione, quando esso è impostato a ricevere da Internet.

Ecco le autorizzazioni di “Anonymous Logon” su un connettore senza accesso anonimo :

rcv1.jpg   Fig 1 : se il connettore non ha l’accesso anonimo…

rcv2.jpg

Fig 2 :…. ecco quali sono le autorizzazioni di Anonymous Logon

Ecco invece come si presentano le autorizzazioni di “Anonymous Logon” su un connettore con l’accesso anonimo attivato :

rcv3.jpg   Fig. 3 : se il connettore ha l’accesso anonimo…

rcv4.jpg

Fig. 4 : …. ecco la presenza dell’autorizzazione “MS-Exh-SMTP-Accept-Authoritative-Domain-Sender”

Se un client di posta non autenticato tentasse ora di spedire mail insererendo un indirizzo di posta interno sia come mittente che come destinatario, gli esiti sarebbero questi (mail accettata!) :

rcv5.jpg

Fig. 5 : mail accettata

Il trucco per bloccare questo tipo di mail provenienti dall’esterno, sta nel rimuovere l’autorizzazione “ms-exch-smtp-accept-authoritative-domain-sender” ad “Anonymous Logon”.  Il comando per eseguire la rimozione è il seguente :

Get-ReceiveConnector “Nome Connettore” | Get-AdPermission -User “NT Authority\Accesso Anonimo” | Where {$_.ExtendedRights -Like “MS-Exch-SMTP-Accept-Authoritative-Domain-Sender”} | Remove-AdPermission

N.B. : nel precedente comando, l’identità speciale “Anonymous Logon” deve essere indicata esattamente come mostrato (cioè “NT Authority\Accesso Anonimo” se la lingua di installazione di Exchange è l’italiano, mentre deve essere indicata come “NT Authority\Anonymous Logon” se la lingua di installazione di Exchange è l’inglese.

Ecco l’esecuzione del comando :

rcv6.jpg

Fig. 6 : esecuzione del comando di rimozione dell’autorizzazione

Ed ecco ora il diverso comportamento per un client di posta non autenticato :

rcv7.jpg

Fig. 7 : mail rifiutata

Questa procedura riesce quindi a bloccare lo spam che utilizza indirizzi di posta interni “spoofati”.

Buon divertimento :-)

  • Share/Bookmark

Pubblicato in Exchange Server 2007, Exchange Server 2010, Exchange Server 2013 | 10 Commenti »

Conoscere i domain controller usati da Exchange

Scritto da Ivan Salvade' il 18 settembre 2013

E’ spesso utile conoscere i domain controller che un server Exchange sta utilizzando, in un certo momento.

Per esempio, durante una migrazione di Active Directory, durante la quale vengono installati nuovi domain controller, oppure vengono rimossi quelli vecchi, è utile sapere se Exchange ha già iniziato a contattare i domain controller nuovi.

Un comando di powershell utile a questo scopo è il seguente :

Get-ExchangeServer -Status | FL Name,Current*

Ecco l’esecuzione del comando in un ambiente con diversi server Exchange in esecuzione :

1.jpg      (Clicca sulla foto per ingrandire)

Il comando restituisce i domain controller utilizzati dai vari server Exchange.

Nella colonna “CurrentDomainControllers” sono riportati i domain controller utilizzati per eseguire le normali query LDAP a porta 389.

Nella colonna “CurrentGlobalCatalogs” sono riportati i domain controller con funzione di Global Catalog, utilizzati per eseguire query LDAP alla porta 3268.

Nella colonna “CurrentConfigDomainController” è riportato il domain controller scelto per eseguire letture e scritture sulla Configuration Partition di Active Directory : per esempio, la Configuration Partition di AD viene modificata in tutti i casi in cui si eseguono modifiche all’Organizzazione Exchange.

Ricordo che Exchange Server è in grado di gestire autonomamente il discovery dei domain controller, attraverso il proprio servizio DSAccess.  Quest’ultimo entra in esecuzione ogni 15 minuti circa, registrando nel log Applicazione gli eventi con codice 2080 contenenti l’elenco dei domain controllers trovati in rete.

  • Share/Bookmark

Pubblicato in Exchange Server 2007, Exchange Server 2010, Exchange Server 2013 | Nessun commento »

E ora cosa usiamo al posto di TMG (Threat Management Gateway)?

Scritto da Ivan Salvade' il 25 luglio 2013

Forefront Threat Management Gateway 2010 è ormai stato abbandonato da Microsoft (con un annuncio del 12 settembre 2012), sebbene il supporto continui fino al 14 aprile 2015, per chi dovesse averlo implementato in rete.

In molti scenari, TMG era caldamente consigliato soprattutto come Reverse Proxy, ovvero con il compito di rendere disponibili all’esterno particolari protocolli applicativi come SMTP, HTTP, HTTPS ecc., proteggendo nel contempo le comunicazioni grazie alle sue caratteristiche di Firewall, URL Filtering e Intrusion Detection.

Sono famose le implementazioni di TMG 2010 per il Reverse Publishing dei servizi di Exchange Server oppure di Lync Server : addirittura, nei corsi ufficiali su questi due prodotti, un intero modulo è dedicato alla configurazione di TMG a questo scopo.

E ora cosa possiamo utilizzare al suo posto?

Fatta salva la possibilità di utilizzare una miriade di terze parti (Kemp Loadmaster, Squid, Kerio Control, EServ, Ositis WinProxy…), volendo rimanere in campo Microsoft cosa possiamo scegliere?

Le soluzioni sono 2 : IIS ARR (Application Routing Request) e UAG (Unified Access Gateway) 2010.

IIS ARR (Application Request Routing)

Si tratta di un componente opzionale di IIS, installabile su Windows Server 2008, 2008 R2 e 2012.  Il componente permette ad IIS di gestire URL Rewrites, richieste di Reverse Proxy, bilanciamenti di carico e altre features ancora, soprattutto se fatto lavorare con un altro modulo di IIS, il URL Rewrite Module.

Il server IIS con ARR e URL Rewrite non necessita di essere installato in ambiente Active Directory.

Sommariamente, ARR e URL Rewrite, congiuntamente, garantiscono le seguenti possibilità :

  • regole di routing applicabili al protocollo http
  • meccanismi sofisticati di bilanciamento di carico, con possibilità di Client Affinity per redirezionare le richieste provenienti da un client ad uno specifico server, utilizzando i cookies
  • Host Name Affinity
  • regole di Reverse Proxy
  • regole di rewriting di URLs, tag HTML, variabili server, intestazioni HTTP
  • supporto per il Failed Request tracing di IIS

Il link per il download diretto di ARR 2.5, in inglese a 64 bit, è il seguente :

http://download.microsoft.com/download/A/A/E/AAE77C2B-ED2D-4EE1-9AF7-D29E89EA623D/requestRouter_amd64_en-US.msi

Il link per il donwload diretto di URL Rewrite Module, in inglese a 64 bit,  è il seguente :

http://go.microsoft.com/?linkid=9722532

Forefront Unified Access Gateway 2010

UAG ha qualcosa in più (e anche qualcosa in meno) rispetto a TMG.

UAG ha le seguenti funzionalità non presenti in TMG :

  • SSL VPN (ma la si può implementare direttamente su Windows Server 2008/R2/2012)
  • migliori possibilità di configurazione delle autenticazioni e del Single Sign-On
  • ILP (Information Leakage Prevention)
  • Endpoint Security (con le Endpoint Access Policies per il controllo dei client)

UAG non ha le seguenti funzionalità di TMG :

  • Proxy in uscita
  • Malware inspection
  • IDS (Intrusion Detection System)
  • Templates di configurazione delle reti

L’ultimo Service Pack di UAG 2010 (il Service Pack 3) ha introdotto le seguenti nuove features :

  • Supporto per il publishing di Exchange 2013
  • Supporto per il publishing di SharePoint 2013
  • Supporto per tutte le applicazioni della suite di Office 2013
  • Supporto per Windows 8
  • Supporto per RDC 8.0 in esecuzione su Windows 8

Se aggiungiamo il già esistente supporto per Exchange, Lync e SharePoint 2010, e il supporto per iOS 5 su iPhone e iPad, Android 4 e Windows Phone 7.5, direi che UAG è assolutamente in grado di sopperire all’assenza di TMG.

Ricordo comunque che TMG continuerà a ricevere supporto base fino al 2015, e supporto esteso ben oltre questa data : nella mia opinione, può anche non essere necessario avventurarsi di colpo verso altre soluzioni.

  • Share/Bookmark

Pubblicato in Gestione dei Sistemi, Sicurezza | Nessun commento »

Creazione di un IVR (Response Group) a più livelli in Lync Server 2010

Scritto da Ivan Salvade' il 5 luglio 2013

In Lync Server 2010, è possibile creare un IVR (Interactive Voice Response) tramite strumenti grafici oppure tramite comandi di powershell.

Il limite imposto dall’uso degli strumenti grafici è quello di poter creare solo 2 domande con un massimo di 4 risposte possibili per ogni domanda.

Se si volesse aumentare il numero delle domande e/o il numero delle risposte, non sarebbe più possibile utilizzare gli strumenti grafici, ma diventerebbe obbligatorio ricorrere ai comandi powershell.

Un IVR creato con comandi powershell, non è più editabile con gli strumenti grafici.

In questo articolo illustrerò come creare un intero IVR con una sola domanda, ma 6 risposte possibili, utilizzando comandi powershell.

La creazione di questo IVR potrà essere presa come esempio per creare IVR contenenti qualunque numero di domande e/o qualunque numero di risposte per ogni domanda.

L’architettura generale del mio IVR di esempio sarà la seguente :

  • Arriva una chiamata ad un numero aziendale associato al IVR
  • Il sistema verifica il giorno e l’orario di ricezione della chiamata, effettuando le seguenti scelte :
    • se la chiamata giunge in un giorno festivo, viene riprodotto un messaggio ”Call Center chiuso per festività”, e la chiamata è terminata
    • se la chiamata giunge in giorni feriali, ma al di fuori degli orari di lavoro, viene riprodotto un messaggio “Call Center chiuso, si prega di richiamare in orari di lavoro”, e la chiamata è terminata
    • se la chiamata giunge in giorni feriali e in orari di lavoro, viene riprodotto un messaggio di benvenuto, e il chiamante è invitato a scegliere una delle seguenti opzioni :
      • digitare 1 per parlare col reparto Vendite
      • digitare 2 per parlare col reparto Amministrazione
      • digitare 3 per parlare col reparto Assistenza Tecnica
      • digitare 4 per parlare col reparto Produzione
      • digitare 5 per parlare col reparto IT
      • digitare 6 per parlare col Centralino (Operatore)
  • In base alle scelte del chiamante, la chiamata è rediretta ad una delle code ”Vendite”, “Amministrazione”, “Assistenza”, “Produzione”, “IT”, “Operatore”, dove risponderanno gli operatori associati a quella determinata coda

I comandi utili alla creazione del IVR sono i seguenti :

New-CsRgsAgentGroup

New-CsRgsAnswer

New-CsRgsCallAction

New-CsRgsHoliday

New-CsRgsHolidaySet

New-CsRgsHoursOfBusiness

New-CsRgsTimeRange

New-CsRgsPrompt

New-CsRgsQuestion

New-CsRgsQueue / Get-CsRgsQueue / Set-CsRgsQueue

New-CsRgsWorkflow / Set-CsRgsWorkflow

Set-CsRgsConfiguration

Import-CsRgsAudioFile

Le operazioni da eseguire sono le seguenti, nel preciso ordine indicato :

  1. Creazione dei Gruppi di Agenti (i vari operatori interni che risponderanno alle chiamate)
  2. Creazione delle Code (mantengono in coda i chiamanti, finchè un agente non risponderà)
  3. Creazione delle Business Hours (ore di lavoro in cui gli agenti sono disponibili)
  4. Creazione degli Holidays (giornate in cui gli agenti non sono disponibili)
  5. Creazione degli Holiday Set (raggruppano gli Holidays, in modo da poterli associare più comodamente al IVR)
  6. Creazione dei Prompt (messaggi vari da riprodurre ai chiamanti)
  7. Creazione delle Azioni (operazioni da eseguire in base alle scelte/comportamenti dei chiamanti)
  8. Configurazione delle Azioni di Timeout e Overflow nelle Code
  9. Creazione delle Risposte (per comprendere le scelte dei chiamanti, e lanciare le Azioni corrispondenti)
  10. Creazione delle Domande (domande poste dal IVR ai chiamanti, per permettere loro di esercitare una scelta)
  11. Creazione della Default Action del Workflow (azione da eseguire se la chiamata al IVR giunge in orari di lavoro)
  12. Creazione del Workflow (il flusso di lavoro finale, completo di domande, risposte, azioni e interconnessioni tra di loro)

Nei seguenti comandi esemplificativi, si suppone che il server Lync di Front-End con il servizio RGS si chiami FE.contoso.com

N.B. : la maggioranza dei comandi seguenti memorizza i risultati in diverse variabili.  Le variabili sono create per poter essere poi utilizzate in comandi successivi.  Le variabili risiedono sempre in RAM, e verrebbero cancellate nel caso si chiudesse la sessione di Lync Powershell ove si stanno digitando i comandi.  Tenere quindi sempre aperta la powershell, altrimenti si perde l’intero lavoro eseguito fino a quel momento.

N.B. : legenda dei comandi :

in grassetto sono indicati i Cmdlet e i parametri, in corsivetto sono indicati i valori da inserire, che possono variare a scelta degli amministratori.  Con la dicitura “(oppure…. ” sono indicate variazioni possibili dei valori dei parametri

Creazione dei Gruppi di Agenti

Ogni gruppo conterrà le utenze abilitate a rispondere per conto di un certo reparto scelto dai chiamanti (Vendite, Produzione, ecc..).

I gruppi di agenti possono anche essere creati nella console di Gestione grafica di Lync.  Il comando powershell per la creazione dei gruppi è “New-CsRgsAgentGroup”, dotato di diversi parametri.

Con il parametro ”-RoutingMethod” si indica la modalità di instradamento delle chiamate alla coda : nel mio esempio ho scelto il valore “Parallel”, che instrada le chiamate contemporaneamente a tutti gli agenti di un certo gruppo (che siano disponibili e non già occupati o fuori linea).

Un parametro non usato nei miei esempi sottostanti, cioè il parametro “-AgentAlertTime”, permette di decidere quanto deve squillare il telefono degli operatori, prima di passare all’eventuale operatore successivo.  Il suo valore di default è 20 secondi.

Ecco i comandi per creare i 6 gruppi necessari al mio IVR esemplificativo :

$GruppoVendite=New-CsRgsAgentGroup -Parent “Service:ApplicationServer:FE.contoso.com-Name GruppoVendite  -ParticipationPolicy Informal (oppure Formal) -RoutingMethod Parallel (oppure LongestIdle, RoundRobin, Serial, Attendant) -AgentsByUri (”sip:UserVendite1@contoso.com”,”sip:UserVendite2@contoso.com“)

$GruppoAmministrazione=New-CsRgsAgentGroup -Parent “Service:ApplicationServer:FE.contoso.com-Name GruppoAmministrazione  -ParticipationPolicy Informal (oppure Formal) -RoutingMethod Parallel (oppure LongestIdle, RoundRobin, Serial, Attendant) -AgentsByUri (”sip:UserAmm1@contoso.com”,”sip:UserAmm2@contoso.com“)

$GruppoAssistenza=New-CsRgsAgentGroup -Parent “Service:ApplicationServer:FE.contoso.com-Name GruppoAssistenza  -ParticipationPolicy Informal (oppure Formal) -RoutingMethod Parallel (oppure LongestIdle, RoundRobin, Serial, Attendant) -AgentsByUri (”sip:UserAss1@contoso.com”,”sip:UserAss2@contoso.com“)

$GruppoIT=New-CsRgsAgentGroup -Parent “Service:ApplicationServer:FE.contoso.com-Name GruppoIT  -ParticipationPolicy Informal (oppure Formal) -RoutingMethod Parallel (oppure LongestIdle, RoundRobin, Serial, Attendant) -AgentsByUri (”sip:UserIT1@contoso.com”,”sip:UserIT2@contoso.com“)

$GruppoProduzione=New-CsRgsAgentGroup -Parent “Service:ApplicationServer:FE.contoso.com-Name GruppoProduzione  -ParticipationPolicy Informal (oppure Formal) -RoutingMethod Parallel (oppure LongestIdle, RoundRobin, Serial, Attendant) -AgentsByUri (”sip:UserProd1@contoso.com”,”sip:UserProd2@contoso.com“)

$GruppoOperatore=New-CsRgsAgentGroup -Parent “Service:ApplicationServer:FE.contoso.com-Name GruppoOperatore  -ParticipationPolicy Informal (oppure Formal) -RoutingMethod Parallel (oppure LongestIdle, RoundRobin, Serial, Attendant) -AgentsByUri (”sip:UserOperatore1@contoso.com”,”sip:UserOperatore2@contoso.com“)

Creazione delle Code

Per ogni gruppo di operatori, deve esistere una coda di attesa, nella quale vengono inseriti i chiamanti in attesa della risposta da parte di qualche operatore.

Anche le code possono essere create nella console grafica di Lync.  Per chi preferisse utilizzare powershell, il comando per la creazione è “New-CsRgsQueue”, dotato di diversi parametri.

Nei miei esempi sottostanti, ho utilizzato solo i parametri strettamente indispensabili (”-Name” e “-AgentGroupIDList”), ma ne esistono altri :

  • -TimeoutThreshold : quantità di tempo (in secondi) che una chiamata può rimanere in coda senza risposta, prima che si verifichi il Timeout.  A quel punto, l’IVR eseguirà l’azione stabilita dal parametro -TimeoutAction. Per default, non ci sono timeout relativi alle chiamate
  • -TimeoutAction : azione da eseguire se venisse raggiunta la soglia di timeout.  L’azione deve essere creata con il cmdlet “New-CsRgsCallAction” (vedi sezioni successive), e il default prevede l’azione “Terminate”
  • -OverflowThreshold : numero massimo di chiamate inseribili in una coda.  Se venisse raggiunto questo numero, sarebbe eseguita l’azione specificata dal parametro -OverflowAction.  Per default, non ci sono limiti.
  • -OverflowAction : azione da eseguire se venisse raggiunta la soglia di overflow. L’azione deve essere creata con il cmdlet “New-CsRgsCallAction” (vedi sezioni successive), e il default prevede l’azione “Terminate”
  • -OverflowCandidate : indica su quale chiamata agire se si raggiunge l’overflow di coda.  Le opzioni possibili sono “NewestCall” e “OldestCall”.  Per default, l’impostazione è “NewestCall”

Ecco i comandi per creare le 6 code necessarie al mio IVR esemplificativo :

$CodaVendite=New-CsRgsQueue -Parent “Service:ApplicationServer:FE.contoso.com-Name “CodaVendite” -AgentGroupIDList ($GruppoVendite.Identity)

$CodaAmministrazione=New-CsRgsQueue -Parent “Service:ApplicationServer:FE.contoso.com-Name “CodaAmministrazione” -AgentGroupIDList ($GruppoAmministrazione.Identity)

$CodaAssistenza=New-CsRgsQueue -Parent “Service:ApplicationServer:FE.contoso.com-Name “CodaAssistenza” -AgentGroupIDList ($GruppoAssistenza.Identity)

$CodaIT=New-CsRgsQueue -Parent “Service:ApplicationService:FE.contoso.com-Name “CodaIT” -AgentGroupIDList ($GruppoIT.Identity)

$CodaProduzione=New-CsRgsQueue -Parent “Service:ApplicationServer:FE.contoso.com-Name “CodaProduzione” -AgentGroupIDList ($GruppoProduzione.Identity)

$CodaOperatore=New-CsRgsQueue -Parent “Service:ApplicationServer:FE.contoso.com-Name “CodaOperatore” -AgentGroupIDList ($GruppoOperatore.Identity)

Creazione delle Business Hours

Servono a definire le ore di lavoro in cui il Contact Center è attivo (e quindi gli agenti sono disponibili).

Prima di creare le Business Hours, è necessario specificare i precisi intervalli di tempo nei quali l’IVR è effettivamente attivo (per esempio, dalle 09.00 alle 13.00 e dalle 14.00 alle 18.00).  Questa operazione si esegue utilizzando il cmdlet “New-CsRgsTimeRange” :

$AperturaMattina=New-CsRgsTimeRange -Name OrarioMattina -OpenTime “09:00″ -CloseTime “13:00″

$AperturaPomeriggio=New-CsRgsTimeRange -Name OrarioPomeriggio -OpenTime “14:00″ -CloseTime “18:00″

Se l’orario di apertura fosse continuo (es. dalle 08:00 alle 22:00), sarebbe sufficiente uno solo dei comandi precedenti.

Poi si crea l’effettivo oggetto “Business Hours”, nel quale si indicano anche le giornate precise di apertura, utilizzando il comando “New-CsRgsHoursOfBusiness”.

Questo comando ha un doppio parametro per ogni giorno della settimana : per esempio, MondayHours1 e MondayHours2 per il lunedì, TuesdayHours1 e TuesdayHours2 per il martedì, e via dicendo fino alla domenica.

E’ necessario utilizzare entrambi i parametri di ogni giornata se il turno di apertura è spezzato, mentre è sufficiente utilizzare solo il primo dei parametri di giornata (MondayHours1, TuesdayHours1, WednesdayHours1….) se il turno di apertura è continuo.

Se in alcune giornate il Call Center è totalmente chiuso, non indicare i parametri per quelle giornate.

Ecco il comando per creare gli orari di apertura spezzati, da lunedì a venerdì, per il mio IVR esemplificativo :

$AperturaIVR=New-CsRgsHoursOfBusiness -Parent “Service:ApplicationServer:FE.Contoso.com-Name IVRBusinessHours -MondayHours1 $AperturaMattina -MondayHours2 $AperuraPomeriggio -TuesdayHours1 $AperturaMattina -TuesdayHours2 $AperuraPomeriggio -WednesdayHours1 $AperturaMattina -WednesdayHours2 $AperuraPomeriggio -ThursdayHours1 $AperturaMattina -ThursdayHours2 $AperuraPomeriggio -FridayHours1 $AperturaMattina -FridayHours2 $AperuraPomeriggio

Creazione degli Holidays e degli Holiday Set

Al Response Group è necessario indicare tutte le giornate di festività nazionali.  Alle chiamate che perverranno in queste giornate, verrà riprodotto un messaggio del tipo “Call Center chiuso per festività”.   Ogni giornata festiva deve essere dichiarata con il comando “New-CsRgsHoliday”.  In questo esempio, ecco la dichiarazione di tutte le giornate festive italiane relative all’anno 2014 :

N.B. : il formato della data nei comandi seguenti dipende dalle impostazioni internazionali e dalla lingua del vostro server.  Se tutto è impostato sulle preferenze italiane, allora il formato data è esattamente quello riportato.  Se avete un server in inglese con le opzioni regionali impostate sul modello statunitense, giorno e mese devono essere invertiti.

$capodanno = New-CsRgsHoliday -Name “capodanno” -StartDate “01/01/2014″ -EndDate “02/01/2014″
$25aprile = New-CsRgsHoliday -Name “25aprile” -StartDate “25/04/2014″ -EndDate “26/04/2014″
$1maggio = New-CsRgsHoliday -Name “1maggio” -StartDate “01/05/2014″ -EndDate “02/05/2014″
$2giugno = New-CsRgsHoliday -Name “2giugno” -StartDate “02/06/2014″ -EndDate “03/06/2014″
$15agosto = New-CsRgsHoliday -Name “ferragosto” -StartDate “15/08/2014″ -EndDate “16/08/2014″
$1nov = New-CsRgsHoliday -Name “1novembre” -StartDate “01/11/2014″ -EndDate “02/11/2014″
$8dic = New-CsRgsHoliday -Name “8dicembre” -StartDate “08/12/2014″ -EndDate “09/12/2014″
$natale = New-CsRgsHoliday -Name “natale” -StartDate “25/12/2014″ -EndDate “27/12/2014″
$pasqua = New-CsRgsHoliday -Name “pasqua” -StartDate “20/04/2014″ -EndDate “22/04/2014″

Le giornate festive devono poi essere raccolte in un “set” di festività, che più avanti verrà agganciato al workflow finale.  La creazione del set di festività si esegue con il comando “New-CsRgsHolidaySet” :

$FestiviIVR=New-CsRgsHolidaySet -Parent “Service:ApplicationServer:FE.contoso.com-Name Feste2014 -HolidayList ($capodanno,$25aprile,$1maggio,$2giugno,$15agosto,$1nov,$8dic,$natale,$pasqua)

In ogni anno seguente, l’elenco delle festività dovrà essere aggiornato, inserendo quelle nuove ed agganciandole al workflow.

Creazione dei Prompt

Si tratta di file audio da riprodurre (oppure stringhe di testo letti da una voce robotica), utili allo scopo di fornire informazioni aggiuntive ai chiamanti (per es. “Benvenuti al Call Center di Contoso” oppure “Attendere in linea mentre la mettiamo in contatto con il reparto vendite”, oppure “Gli uffici sono chiusi. La preghiamo di richiamare tra le 08.00 e le 18.00″ …).

La procedura di creazione varia a seconda che si utilizzino files audio preregistrati, oppure stringhe di testo che la voce automatica dovrà leggere.

Nel mio IVR esemplificativo, suppongo di voler utilizzare i seguenti Prompt :

  • Prompt di benvenuto al Call Center (da riprodurre negli orari di apertura del Call Center; contiene la domanda principale del IVR)
  • Prompt di Call Center chiuso per festività (da riprodurre nei festivi)
  • Prompt di Call Center fuori orario di lavoro (da riprodurre negli orari di chiusura del Call Center)
  • Prompt di attesa (da riprodurre quando i chiamanti vengono messi in attesa in coda di risposta)
  • Prompt di risposta sbagliata (da riprodurre quando i chiamanti digitano una risposta sbagliata, cioè non compresa tra 1 e 6)
  • Prompt di risposta assente (da riprodurre quando i chiamanti non indicano risposte alla domanda del IVR)
  • Prompt di coda in overflow o tempo di attesa troppo lungo (da riprodurre se la coda a cui è rediretto un chiamante è già satura, oppure gli operatori non rispondono al chiamante entro una certa tempistica)

Ho deciso di pre-registrare nei files .WAV i primi quattro prompt, e di utilizzare un Text-to-Speech per gli ultimi tre prompt.  Questa scelta ha unicamente lo scopo di farvi vedere la creazione di entrambi i tipi di Prompt : voi potreste optare per l’utilizzo unico di files audio, per esempio.

N.B. : per evitare un errore del IVR con codice evento 31117 e una descrizione simile a questa :

(System.ArgumentNullException: Value cannot be null. Parameter name: alternateText at Microsoft.Speech.Synthesis.PromptBuilder.AppendAudio(Uri audioFile, String alternateText)

… è necessario inserire un Text-to-Speech anche nei prompt nei quali intendete utilizzare una registrazione audio.  Il Text-to-Speech verrà utilizzato solo se il file audio dovesse risultare corrotto e non riproducibile.

Cominciamo a creare i quattro prompt basati su voci preregistrate.  I files WAV devono essere posizionati in una cartella del Front-End (es. “C:\AudioFiles”). Si utilizzano poi i comandi “Import-CsRgsAudioFile” e “New-CsRgsPrompt” per la creazione dei prompt :

$AudioBenvenuto=Import-CsRgsAudioFile -Identity Service:ApplicationServer:FE.Contoso.com -Filename PromptBenvenuto.wav -Content (Get-Content C:\Audiofiles\PromptBenvenuto.wav” -Encoding Byte -ReadCount 0)

$PromptBenvenuto=New-CsRgsPrompt -AudioFilePrompt $AudioBenvenuto -TextToSpeechPrompt “messaggio di benvenuto e proposizione della prima domanda di scelta”

$AudioFesta=Import-CsRgsAudioFile -Identity Service:ApplicationServer:FE.Contoso.com -Filename PromptFesta.wav -Content (Get-Content C:\Audiofiles\PromptFesta.wav” -Encoding Byte -ReadCount 0)

$PromptFesta=New-CsRgsPrompt -AudioFilePrompt $AudioFesta -TextToSpeechPrompt “Siamo chiusi per festività. Si prega di richiamare in giornate feriali”

$AudioChiusura=Import-CsRgsAudioFile -Identity Service:ApplicationServer:FE.Contoso.com -Filename PromptChiusura.wav -Content (Get-Content C:\Audiofiles\PromptChiusura.wav” -Encoding Byte -ReadCount 0)

$PromptChiusura=New-CsRgsPrompt -AudioFilePrompt $AudioChiusura -TextToSpeechPrompt “In questo momento siamo chiusi. Si prega di richiamare in orari di lavoro”

$AudioAttesa=Import-CsRgsAudioFile -Identity Service:ApplicationServer:FE.Contoso.com -Filename PromptAttesa.wav -Content (Get-Content C:\Audiofiles\PromptAttesa.wav” -Encoding Byte -ReadCount 0)

$PromptAttesa=New-CsRgsPrompt -AudioFilePrompt $AudioAttesa -TextToSpeechPrompt “Siete pregati di rimanere in attesa della risposta degli operatori”

Ora creiamo i Prompt basati su stringhe di testo (Text-to-Speech : ci penserà la voce robotica di Lync a leggere la stringa ai chiamanti) :

$PromptErroreScelta=New-CsRgsPrompt -TextToSpeechPrompt “La risposta non è tra quelle consentite. Si prega di correggere la selezione”

$PromptNessunaScelta=New-CsRgsPrompt -TextToSpeechPrompt “Non è stata digitata alcuna scelta. Si prega di riprovare”

$PromptOverflow=New-CsRgsPrompt -TextToSpeechPrompt “In questo momento il Call Center è sovraccarico. Si prega di riprovare più tardi”

Creazione delle Azioni

Le Azioni rappresentano le operazioni che l’IVR deve eseguire all’accadimento di un certo evento. Esempi possono essere :

  • azione da eseguire se giunge al IVR una chiamata in giorni festivi
  • azione da eseguire se giunge al IVR una chiamata fuori orari di lavoro
  • azione da eseguire se giunge al IVR una chiamata in orario di lavoro
  • azione da eseguire se il chiamante esercita una certa scelta in risposta ad una domanda del IVR
  • azione da eseguire se un chiamante viene inserito in una coda che risulta già piena (overflow di coda)
  • azione da eseguire se un operatore non risponde ad un chiamante entro una certa tempistica (time-out di coda)

Le azioni si creano con il cmdlet New-CsRgsCallAction.  Il suo parametro più importante è “-Action“, che può avere i seguenti valori :

  • Terminate : termina direttamente la chiamata
  • TransferToQueue : trasferisce una chiamata alla coda specificata
  • TransferToQuestion : trasferisce una chiamata ad una domanda successiva posta dal IVR
  • TransferToURI : trasferisce una chiamata ad uno specifico SIP URI
  • TransferToVoiceMailURI : trasferisce una chiamata ad una segreteria telefonica (es. Exchange Unified Messaging)
  • TransferToPSTN : trasferisce una chiamata ad un numero telefonico PSTN (rete pubblica)

Si crea l’azione da eseguire se giunge una chiamata in giornate festive :

$AzioneFesta=New-CsRgsCallAction -Prompt $PromptFesta -Action Terminate

Si crea l’azione da eseguire se giunge una chiamata in orari di chiusura del Call Center :

$AzioneChiusura=New-CsRgsCallAction -Prompt $PromptChiusura -Action Terminate

Si crea l’azione da eseguire se la coda a cui è rediretto il chiamante è piena, oppure se gli operatori non rispondono al chiamante entro una certa tempistica (parametri impostabili nelle proprietà delle code) :

$AzioneOverflow=New-CsRgsCallAction -Prompt $PromptOverflow -Action Terminate

Si crea l’azione da eseguire se giunge una chiamata in orario di apertura del Call Center, e il chiamante sceglie l’opzione 1 :

$Azione1=New-CsRgsCallAction -Prompt $PromptAttesa -Action TransferToQueue (oppure TransferToQuestion, Terminate, TransferToUri, TransferToVoiceMailUri, TransferToPstn) -QueueID $CodaVendite.Identity    (questo parametro è obbligatorio se Action è impostato su “TransferToQueue”)

Si crea l’azione da eseguire se giunge una chiamata in orario di apertura del Call Center, e il chiamante sceglie l’opzione 2 :

$Azione2=New-CsRgsCallAction -Prompt $PromptAttesa -Action TransferToQueue (oppure TransferToQuestion, Terminate, TransferToUri, TransferToVoiceMailUri, TransferToPstn) -QueueID $CodaAmministrazione.Identity    (questo parametro è obbligatorio se Action è impostato su “TransferToQueue”)

Si crea l’azione da eseguire se giunge una chiamata in orario di apertura del Call Center, e il chiamante sceglie l’opzione 3 :

$Azione3=New-CsRgsCallAction -Prompt $PromptAttesa -Action TransferToQueue (oppure TransferToQuestion, Terminate TransferToUri, TransferToVoiceMailUri, TransferToPstn) -QueueID $CodaAssistenza.Identity    (questo parametro è obbligatorio se Action è impostato su “TransferToQueue”)

Si crea l’azione da eseguire se giunge una chiamata in orario di apertura del Call Center, e il chiamante sceglie l’opzione 4 :

$Azione4=New-CsRgsCallAction -Prompt $PromptAttesa -Action TransferToQueue (oppure TransferToQuestion, Terminate, TransferToUri, TransferToVoiceMailUri, TransferToPstn) -QueueID $CodaProduzione.Identity    (questo parametro è obbligatorio se Action è impostato su “TransferToQueue”)

Si crea l’azione da eseguire se giunge una chiamata in orario di apertura del Call Center, e il chiamante sceglie l’opzione 5 :

$Azione5=New-CsRgsCallAction -Prompt $PromptAttesa -Action TransferToQueue (oppure TransferToQuestion, Terminate, TransferToUri, TransferToVoiceMailUri, TransferToPstn) -QueueID $CodaIT.Identity    (questo parametro è obbligatorio se Action è impostato su “TransferToQueue”)

Si crea l’azione da eseguire se giunge una chiamata in orario di apertura del Call Center, e il chiamante sceglie l’opzione 6 :

$Azione6=New-CsRgsCallAction -Prompt $PromptAttesa -Action TransferToQueue (oppure TransferToQuestion, Terminate, TransferToUri, TransferToVoiceMailUri, TransferToPstn) -QueueID $CodaOperatore.Identity    (questo parametro è obbligatorio se Action è impostato su “TransferToQueue”)

Configurazione delle Azioni di Timeout e Overflow nelle Code

Ora che abbiamo creato tutte le azioni possibili, è possibile tornare sulle Code (già create precedentemente) per agganciare loro l’azione di Overflow/Timeout (cioè l’azione da eseguire se le code dovessero già essere piene e/o se gli operatori non rispondono entro il tempo di timeout impostato nelle code stesse).

Ecco i comandi per impostare l’azione di Overflow/Timeout sulle code (queste sono ancora memorizzate nelle variabili utilizzate nella sezione di creazione delle code) :

N.B. : il comando Set-CsRgsQueue serve a fissare definitivamente nel Front-End di Lync le modifiche sulle code.  Fino a quel momento, le modifiche risiedono esclusivamente in memoria (nelle variabili).

$CodaVendite.OverflowAction=$AzioneOverflow

Set-CsRgsQueue -Instance $CodaVendite

$CodaAmministrazione.OverflowAction=$AzioneOverflow

Set-CsRgsQueue -Instance $CodaAmministrazione

$CodaAssistenza.OverflowAction=$AzioneOverflow

Set-CsRgsQueue -Instance $CodaAssistenza

$CodaIT.OverflowAction=$AzioneOverflow

Set-CsRgsQueue -Instance $CodaIT

$CodaProduzione.OverflowAction=$AzioneOverflow

Set-CsRgsQueue -Instance $CodaProduzione

$CodaOperatore.OverflowAction=$AzioneOverflow

Set-CsRgsQueue -Instance $CodaOperatore

Creazione delle Risposte

Le Risposte devono essere create per permettere al IVR di comprendere la risposta digitata o pronunciata da un chiamante, ed eseguire le opportune azioni.  Per esempio, l’IVR deve capire se l’utente ha composto il numero 1 per scegliere la prima opzione (oppure se ha enunciato la parola “uno”), e in quel caso eseguire l’azione prevista per questa opzione.

Le Risposte si creano con il comando “New-CsRgsAnswer”.  I suoi parametri più importanti sono :

  • -DTMFResponse : indica il tasto da premere sul tastierino da parte del chiamante, per esercitare una scelta
  • -VoiceResponseList : indica la parola da enunciare da parte del chiamante, per esercitare una scelta
  • -Action : indica l’azione da eseguire.  Questa deve essere già stata creata con il comando New-CsRgsCallAction (vedi sezione precedente)

N.B. : non è obbligatorio inserire entrambi i parametri “-DTMFResponse” e “-VoiceResponseList” : è sufficiente almeno uno dei due.

Creiamo ora tutte le Risposte necessarie ad intercettare le varie opzioni di scelta (da 1 a 6) del mio IVR esemplificativo :

$Risposta1=New-CsRgsAnswer -DTMFResponse 1 -VoiceResponseList “uno” -Action $Azione1

$Risposta2=New-CsRgsAnswer -DTMFResponse 2 -VoiceResponseList “due” -Action $Azione2

$Risposta3=New-CsRgsAnswer -DTMFResponse 3 -VoiceResponseList “tre” -Action $Azione3

$Risposta4=New-CsRgsAnswer -DTMFResponse 4 -VoiceResponseList “quattro” -Action $Azione4

$Risposta5=New-CsRgsAnswer -DTMFResponse 5 -VoiceResponseList “cinque” -Action $Azione5

$Risposta6=New-CsRgsAnswer -DTMFResponse 6 -VoiceResponseList “sei” -Action $Azione6

Creazione delle Domande (nel mio esempio, una sola domanda)

La domanda da creare sarà quella (posta dal IVR) in cui viene chiesto ai chiamanti di scegliere le opzioni da 1 a 6.  Dopo la domanda, il sistema dovrà aspettare la risposta del chiamante, e poi eseguire l’azione appropriata.  La domanda si crea con il comando “New-CsRgsQuestion”.  A questo comando è necessario fornire almeno un Prompt (già creati precedentemente, che rappresentano la registrazione audio della domanda o il Text-to-Speech della stessa), e un gruppo di risposte supportate (già create precedentemente, che intercettano le risposte del chiamante ed eseguono le azioni previste in base alla scelta effettuata).  E’ possibile anche indicare un Prompt da utilizzare nel caso di risposte errate da parte del chiamante (per esempio se dovesse digitare 7, valore non compreso tra quelli possibili), e un Prompt da utilizzare nel caso di mancata risposta da parte del chiamante.

$Domanda1=New-CsRgsQuestion -Prompt $PromptBenvenuto -AnswerList $Risposta1,$Risposta2,$Risposta3,$Risposta4,$Risposta5,$Risposta6  -InvalidAnswerPrompt $PromptErroreScelta -NoAnswerPrompt $PromptNessunaScelta

Creazione della Default Action del Workflow

La “Default Action” del IVR è l’azione che deve essere eseguita quando giunge una chiamata negli orari di apertura del Call Center.  La Default Action deve semplicemente indicare al IVR di porre al chiamante la prima domanda contenente il primo livello di scelte (nel mio esempio, questa sarà anche l’unica domanda del IVR) :

$AzioneDefault=New-CsRgsCallAction -Action TransferToQuestion -Question $Domanda1

Creazione del Workflow finale

Ora siamo pronti ad inserire tutti gli oggetti creati nel Workflow finale, che darà vita al IVR vero e proprio.

Il Workflow si crea con il comando “New-CsRgsWorkflow”.  Eventuali successive interrogazioni/modifiche del workflow possono essere eseguite con l’utilizzo congiunto dei comandi “Get-CsRgsWorkflow” e “Set-CsRgsWorkflow”.

I parametri più importanti del comando “New-CsRgsWorkflow” sono i seguenti :

  • -LineURI : indica il numero di telefono a cui è raggiungibile il Call Center dall’esterno
  • -Active : indica se il Call Center deve essere subito attivo ($True) oppure no ($False)
  • -Anonymous : rende anonimi gli operatori che rispondono ($True) oppure visibili ($False)
  • -BusinessHoursID : indica gli orari di apertura del IVR (in questa caso verrà riprodotta la “Default Action”)
  • -DefaultAction : azione da eseguire in orari di apertura.  L’azione deve essere stata precedentemente creata con un comando New-CsRgsCallAction (vedi sezione precedente), e deve contenere un’azione di trasferimento (TransferToQuestion) alla prima domanda del IVR ($Domanda1 nel mio esempio)
  • -NonBusinessHoursAction : azione da eseguire in orari di chiusura.  L’azione deve essere stata precedentemente creata con un comando New-CsRgsCallAction
  • -HolidayAction : azione da eseguire in giornate festive. L’azione deve essere stata precedentemente creata con un comando New-CsRgsCallAction

$Workflow=New-CsRgsWorkflow -Parent “Service:ApplicationServer:FE.contoso.com” -Name “IVR aziendale” -Description “Il Call Center dell’azienda XXX” -PrimaryURI “sip:IVR@contoso.com” -LineURI “tel:+3902123456″ -DisplayNumber “0039 02 123456″ -Active $True -Anonymous $True -BusinessHoursID $AperturaIVR.identity -HolidaySetIDList $FestiviIVR.identity -HolidayAction $AzioneFesta -NonBusinessHoursAction $AzioneChiusura -DefaultAction $AzioneDefault -CustomMusicOnHoldFile $AudioAttesa

Set-CsRgsWorkflow -Instance $Workflow

L’ultimo comando mette in effettiva “produzione” l’intero workflow : supponendo il corretto inserimento del numero di telefono per raggiungere l’IVR (parametro -LineUri del workflow) e la corretta configurazione dei componenti Enterprise Voice di Lync Server (Dial Plans, Voice Policy, Routes, Trunk, integrazione con un Gateway IP), l’IVR è già da ora pronto all’uso.

Buon Call Center!!! :-)

  • Share/Bookmark

Pubblicato in Lync Server 2010 | 2 Commenti »

Disponibile la Preview di Windows 8.1

Scritto da Ivan Salvade' il 27 giugno 2013

Anche la Release Preview di Windows 8.1 è disponibile per il download pubblico.

Il link per scaricarla è il seguente :

http://windows.microsoft.com/it-it/windows-8/preview-download

Da quest’altro link, potete scaricare un guida a Windows 8.1 in formato PDF :

http://go.microsoft.com/fwlink/p/?LinkId=302189

Buon testing :-)

  • Share/Bookmark

Pubblicato in Cafè, Windows 8 | Nessun commento »

 
Usiamo i cookie per assicurarti la migliore esperienza di navigazione nel nostro sito web.
Ok