Articolo originale pubblicato martedì 11 settembre 2012
Questo post è a cura di Nick Simons, Senior Program Manager per Office Web Apps.
Nell'estate del 2010 abbiamo presentato le applicazioni di Office Web Apps, ovvero versioni di Word, PowerPoint, Excel e OneNote basate su browser. Abbiamo messo a disposizione questi prodotti come insieme di applicazioni di SharePoint. Per distribuire Office Web Apps nelle proprie reti, i clienti hanno pertanto installato il prodotto nei server SharePoint.
In quel momento, una stretta integrazione con SharePoint rappresentava l'approccio migliore. Chiaramente SharePoint era e continua a essere un pilastro nella storia delle applicazioni di Office Web Apps e include un modello ben definito per l'integrazione di applicazioni come quelle di Office Web Apps. Quando però abbiamo iniziato a pianificare la versione successiva di Office Web Apps, è risultato evidente che sarebbe stato difficile realizzare alcuni dei nostri obiettivi principali con un'architettura così strettamente associata a SharePoint.
Abbiamo voluto semplificare le attività di configurazione e di pianificazione della capacità, abilitando inoltre la federazione su più farm. Abbiamo accolto tra l'altro le richieste di integrazione di nuovi partner, ad esempio Lync. Infine, molti dei nostri clienti, sia di Office 365 che delle versioni in locale, hanno richiesto di usufruire degli stessi miglioramenti offerti agli utenti di SkyDrive con scadenze regolari.
Per raggiungere questi obiettivi, siamo tornati sui nostri passi e abbiamo riconcepito l'integrazione delle applicazioni di Office Web Apps con altri prodotti, non solo per il presente ma anche per il futuro. Abbiamo creato un nuovo modello per separare Office Web Apps da qualsiasi tecnologia partner specifica. Il nostro modello in definitiva impone un carico di attività di codifica relativamente leggero sugli host di file come SharePoint, consentendoci al tempo stesso di eseguire Office Web Apps in server completamente separati.
Questo nuovo prodotto server autonomo è Office Web Apps Server.
Ci rendiamo conto come all'inizio l'idea di un ulteriore tipo di server possa far temere un aumento della complessità e del carico delle attività per gli amministratori. Potrete osservare invece come l'utilizzo di un prodotto autonomo offra i vantaggi seguenti...
1. Configurazione più semplice
2. Attività di aggiornamento e manutenzione completamente separate da SharePoint
3. Integrazione di più farm di SharePoint con una singola farm di Office Web Apps Server
4. Integrazione di altri prodotti, ad esempio Exchange, Lync e prodotti di terze parti con Office Web Apps
5. Distribuzione di nuove funzionalità e di miglioramenti ai clienti basati sul Web e ai clienti che utilizzano installazioni locali praticamente in contemporanea
Dal confronto tra le distribuzioni di Office Web Apps precedenti in SharePoint 2010 e le nuove distribuzioni con Office Web Apps Server, i vantaggi risultano immediatamente evidenti.
Con la versione precedente di Office, una distribuzione di Office Web Apps tipica è simile alla seguente...
Come è possibile osservare, la versione precedente di Office Web Apps deve essere installata in ogni farm e in ogni computer di ogni farm. La scalabilità di Office Web Apps inoltre è strettamente collegata alla scalabilità generale di SharePoint. L'aggiornamento di Office Web Apps richiede infatti l'aggiornamento del codice in ogni computer di ogni farm di SharePoint.
Con Office Web Apps Server, prevediamo invece una distribuzione simile alla seguente...
Come è possibile osservare, una singola farm di Office Web Apps Server è in grado di servire più farm di SharePoint 2013, oltre a Lync 2013 ed Exchange 2013 (Outlook Web Access). È inoltre possibile utilizzare la farm di Office Web Apps per visualizzare qualsiasi file di Word, Excel e PowerPoint accessibile tramite URL o UNC.
Viene descritto di seguito a grandi linee come si integra Office Web Apps con un host di file come SharePoint. Con queste informazioni sarà più semplice capire i requisiti di rete e sicurezza descritti più avanti.
Prima di tutto, qualche definizione:
Un elemento chiave del nuovo modello di integrazione è rappresentato dalla nuova interfaccia API pubblica utilizzata da Office Web Apps per comunicare con gli host. Questa interfaccia API è denominata WOPI (Web application Open Platform Interface). Office Web Apps Server recupera e modifica i file utilizzando l'API WOPI. Ci riferiamo spesso a Office Web Apps Server con il termine di applicazione WOPI. Gli host devono riconoscere le richieste WOPI delle applicazioni WOPI.
WOPI è un'interfaccia API RESTful che utilizza i protocolli HTTP/HTTPS. Questo significa, tra l'altro, che tutto il traffico tra gli host e Office Web Apps Server passa attraverso porte HTTP/HTTPS standard e che Office Web Apps Server è, per quanto possibile, senza stato. In questo modo garantisce una maggiore resilienza per diversi tipi di errori, dalle interruzioni di rete agli errori hardware.
Per capire il funzionamento dell'interfaccia WOPI, analizziamo un semplice scenario dove un utente, che chiameremo Sandra, visualizza un file denominato test.docx ospitato in SharePoint. Ecco come funziona...
1. Sandra passa a una raccolta documenti in cui è archiviato il file test.docx.
2. Sandra fa clic sul nome del file nella raccolta documenti.
3. SharePoint visualizza nel browser una pagina speciale di SharePoint per l'invio delle richieste a Office Web Apps Server (e altre applicazioni WOPI). Indicheremo tale pagina con il nome di SharePoint WOPIFrame.aspx.
4. WOPIFrame.aspx include un iframe (http://dev.w3.org/html5/spec/the-iframe-element.html) che passa a una pagina in Office Web Apps Server che indicheremo con il nome di WordViewer.aspx. La richiesta HTTP a WordViewer.aspx include alcune informazioni importanti:
5. Office Web Apps Server utilizza l'origine WOPI e il token di accesso per ottenere il file test.docx da SharePoint.
6. WordViewer.aspx visualizza il file test.docx nell'iframe nella pagina WOPIFrame.aspx.
Nella figura riportata di seguito viene mostrato il flusso di dati tra il browser, SharePoint e Office Web Apps Server...
Una server farm può essere costituita ad esempio da una macchina virtuale in esecuzione in un server condiviso così come da una farm con decine di server di data center. Le attività di configurazione e manutenzione di base sono comunque le stesse in entrambi i casi. I prerequisiti esatti e i passaggi necessari per la creazione di una farm sono ovviamente inclusi con il prodotto. In questo articolo non verrà riprodotta la documentazione. Ci limiteremo a descrivere gli elementi necessari con un livello di dettaglio accettabile.
È innanzitutto necessario disporre di alcuni computer. Presupponiamo che si stia configurando una farm per gestire le richieste di 80.000 utenti di più farm di SharePoint. Saranno probabilmente necessari quattro server con le caratteristiche seguenti...
È inoltre necessaria una soluzione di bilanciamento del carico. Presso Microsoft disponiamo di una farm di 10 computer che condivide un dispositivo di bilanciamento del carico hardware F5 BIG-IP con molti altri prodotti server. Questa soluzione funziona in modo ottimale, ma è possibile utilizzare qualsiasi altra soluzione accettabile di bilanciamento del carico. L'unico requisito veramente importante è che la soluzione di bilanciamento del carico supporti l'affinità. Per prestazioni ottimali, è estremamente utile che lo stesso server gestisca tutte le richieste per una sessione specifica.
Presupponiamo che un requisito sia che gli utenti abbiano accesso a Office Web Apps sia dalla rete interna che da Internet. In questo caso, sarà necessario configurare il sistema DNS interno ed esterno per la farm. In alternativa, è possibile scegliere di configurare solo il sistema DNS esterno e utilizzare regole DNS interne per mantenere le richieste interne nella rete privata. Questa è la soluzione che abbiamo scelto di implementare.Poiché comunque si tratta della vostra rete, sarà opportuno che la configuriate in base alle vostre esigenze. I requisiti sono i seguenti...
È di fondamentale importanza verificare che queste route di rete siano configurate correttamente. Le applicazioni di Office Web Apps sono relativamente semplici, ma funzionano solo quando i canali di comunicazione sono aperti.
Come specificato nella sezione precedente, la richiesta iniziale per il rendering o la modifica di un file include credenziali utente nel formato di un token di accesso, a sua volta incluso in tutte le richieste inviate da Office Web Apps agli host. Tutto questo traffico deve essere protetto tramite SSL, a meno che non venga utilizzata una rete privata e si consideri attendibile chiunque abbia accesso a tale rete. Anche in questo caso sarebbe necessario utilizzare SSL.Per configurare SSL, è necessario creare certificati e inserirli in ogni computer Office Web Apps Server o nella soluzione di bilanciamento del carico. Se si sceglie di terminare SSL nella soluzione di bilanciamento del carico, è possibile utilizzare impostazioni specifiche in Office Web Apps Server. Tali impostazioni verranno trattate più avanti.
Dopo aver definito i componenti hardware e l'infrastruttura di rete, è il momento di creare effettivamente la farm di Office Web Apps Server. Installate innanzitutto Office Web Apps Server e i relativi Language Pack in tutti i computer. Non tentate di installare altro software nei computer, né SharePoint, né Exchange, né altri prodotti. Se desiderate condividere l'hardware, utilizzate le macchine virtuali.
Al termine, eseguite i comandi di Windows PowerShell seguenti nel primo computer della farm, che denomineremo Server1. Windows PowerShell presuppone che...
Il comando di Windows PowerShell è il seguente:
New-OfficeWebAppsFarm -ExternalURL "https://officewebapps.contoso.com" -EditingEnabled -SSLOffloaded
Disponete ora di una farm di Office Web Apps Server con computer singolo.
Al termine, passate a Server2. In questo server eseguite il comando seguente...
New-OfficeWebAppsMachine -MachineToJoin "Server1"
Disponete ora di una farm con due computer. Ripetete il passaggio precedente per Server3 e Server4.
A questo punto la farm di Office Web Apps è pronta per l'utilizzo, ma non è connessa ancora ad alcun host. Per connettere una farm di SharePoint a questa farm di Office Web Apps Server, aprite una finestra del prompt dei comandi di Windows PowerShell in un server della farm di SharePoint ed eseguite il comando seguente...
New-SPWopiBinding -ServerName "officewebapps.contoso.com"
Sarà necessario inoltre eseguire il comando seguente per indicare alla farm di SharePoint che desiderate utilizzare l'URL esterno della farm di Office Web Apps Server e che viene utilizzato il protocollo HTTPS.
Set-SPWopiZone -Zone "external-https"
Sono state completate così tutte le operazioni. Passate ora a una raccolta documenti nella farm di SharePoint per creare, visualizzare e modificare file di Office in base alle vostre esigenze. Non sono necessarie ulteriori attività di configurazione.
Se infine desiderate disconnettere la farm di Office Web Apps Server da SharePoint, eseguite il comando seguente...
Remove-SPWopiBinding -All
Se aprite ora una raccolta documenti della farm di SharePoint, non vi sarà traccia delle applicazioni di Office Web Apps.
Potete connettere un numero illimitato di farm di SharePoint a una singola farm di Office Web Apps. Lo stesso vale per la connessione di Exchange e Lync a una farm di Office Web Apps. Per ulteriori informazioni, vedete Exchange Server 2013: integrazione con Office Web Apps Server e Distribuzione di Office Web Apps Server e Lync Server 2013.
Sin dall'inizio ci siamo impegnati a garantire aggiornamenti frequenti per le applicazioni di Office Web Apps. Abbiamo fornito però gli aggiornamenti solo ai clienti delle versioni in locale tramite i Service Pack. Dopo il rilascio di Office Web Apps Server 2013, prevediamo di rendere disponibili gli aggiornamenti con una maggiore frequenza. Riteniamo che sarà un'attività facilmente gestibile dagli amministratori, perché l'operazione di aggiornamento di Office Web Apps Server è molto semplice.
Per aggiornare i computer di una farm di Office Web Apps Server, è necessario rimuovere i computer dalla soluzione di bilanciamento del carico e dalla farm. È comunque possibile gestire questo processo praticamente senza alcun disagio per gli utenti.Se ad esempio disponete di una farm con quattro computer, disconnettete due computer e aggiornateli. Create quindi una nuova farm con questi due computer e fate in modo che la soluzione di bilanciamento del carico punti a questi due computer anziché ai due computer della farm originale. Aggiornate ora gli altri due computer e aggiungeteli alla nuova farm, configurando la soluzione di bilanciamento del carico in modo che punti anche a questi due computer.
Quando vengono disconnessi computer dalla farm, è possibile che alcuni utenti riscontrino problemi, ma le applicazioni di Office Web Apps verranno ripristinate. Questo funziona per tutti i casi, ad eccezione dello scenario con un singolo computer (per ovvi motivi).
Ulteriori informazioni su Office Web Apps Server sono disponibili nelle risorse seguenti:• Libreria di Office Web Apps Preview su TechNet• Exchange Server 2013: integrazione con Office Web Apps Server• Distribuzione di Office Web Apps Server e Lync Server 2013• Forum sulla configurazione e la distribuzione di Office Web Apps
Nick SimonsSenior Program Manager - Office Web Apps
Questo è un post di blog localizzato. L'articolo originale è disponibile in Introducing Office Web Apps Server.
Articolo originale pubblicato mercoledì 7 novembre 2012
Questo post è stato scritto da David Matsumoto, Program Manager del team Office Solutions Management.
Nei nostri ultimi post del blog abbiamo parlato delle funzionalità di telemetria di Office, che rappresentano una novità per Office 2013. È possibile che nel frattempo abbiate letto qualche post in cui veniva illustrato più in dettaglio il dashboard di telemetria e che abbiate avuto la possibilità di iniziare a utilizzarlo.
In questo blog parleremo del log di telemetria per Office 2013, che viene installato insieme al dashboard di telemetria. Ne descriveremo la funzione e i modi per utilizzarlo al meglio. Allora cominciamo!
Il log di telemetria consente agli utenti finali di individuare i problemi di compatibilità che si verificano in alcune applicazioni di Office 2013* sul loro computer client locale. Mentre il dashboard di telemetria è destinato ai professionisti IT che operano in ambito aziendale e consente loro di raccogliere informazioni relative all'utilizzo e alla telemetria dell'intera organizzazione e di averle in un'unica visualizzazione, il log di telemetria visualizza lo stesso tipo di informazioni per utente nel computer dell'utente.
Dopo che la registrazione della telemetria viene abilitata, ogni volta che l'utente apre o chiude un file o una soluzione in Office 2013, viene registrato un evento in un archivio dati locale sul computer client. Se si verificano errori, anche quelli che possono non essere ovvi, vengono registrati nell'archivio dati locale con le informazioni relative all'utente e al computer. Quando possibile, gli errori vengono associati a problemi di compatibilità noti che possono essere visualizzati nel log di telemetria.
*Per un elenco dei file e delle soluzioni di Office di cui viene tenuta traccia nel log di telemetria, vedere la Tabella 1 in Funzionamento del log di telemetria.
Se Office 2013 è stato installato in Windows 8, è sufficiente eseguire un gesto di scorrimento rapido verso l'alto per visualizzare la barra delle applicazioni, scegliere Tutte le applicazioni e quindi Log di telemetria per Office 2013. Per le installazioni di Windows 7, scegliere Tutti i programmi, quindi nell'elenco dei programmi espandere Microsoft Office 2013, espandere Strumenti di Office 2013 e quindi scegliere Log di telemetria per Office 2013.
Quando si avvia il log di telemetria (Office Telemetry Log), in Excel 2013 viene aperta una nuova cartella di lavoro con tre fogli di lavoro denominati Eventi (Events), Informazioni di sistema (System info) e Guida (Guide).
Fare clic sul foglio di lavoro Guida (Guide) e quindi sul pulsante verde per abilitare la registrazione:
Non è necessario eseguire altre impostazioni! Ogni volta che si aprirà un documento o una soluzione in Office 2013, l'operazione verrà immediatamente registrata nel log di telemetria. Proseguire e provare ad aprire e chiudere un documento oppure a caricare una soluzione. Tornare quindi al foglio di lavoro Eventi (Events) e fare clic sul pulsante di aggiornamento nella parte in alto a destra del riquadro dell'intestazione. Saranno visibili una o più righe corrispondenti a tutti gli eventi che si sono verificati quando il documento o la soluzione è stata aperta e chiusa. È possibile effettuare una verifica esaminando diverse colonne nel foglio di lavoro Eventi (Events). Vedere di seguito l'esempio della Figura 1.
Ad esempio, nel foglio di lavoro Eventi (Events) è possibile visualizzare le informazioni seguenti:
Figura 1: log di telemetria (Telemetry Log) - visualizzazione Eventi (Events)
È inoltre possibile verificare che la registrazione della telemetria sia abilitata nel computer facendo clic sul foglio di lavoro Informazioni di sistema (System info) e controllando che tale funzione sia attivata.
Nota: se si dispone di un computer client che opera in un ambiente gestito, l'amministratore IT può avere già effettuato il provisioning del computer per abilitare la registrazione della telemetria, in modo che i dati possano essere caricati nel database e visualizzati nel dashboard di telemetria.
Il log di telemetria è particolarmente utile per gli utenti esperti e i tester che desiderano analizzare i problemi relativi a documenti o soluzioni e trovare le operazioni correttive appropriate.
Considerare l'esempio seguente, in cui il log di telemetria viene utilizzato per risolvere i problemi relativi ai documenti (lo stesso vale anche per la risoluzione dei problemi delle soluzioni):
1. Un tester ha caricato due documenti, CalendarControl_report.xls e ConfidentialityAgreement_template.docx, e ha tentato di eseguire i controlli (oppure le macro e simili) che presentano problemi. Notare che i controlli devono essere effettivamente eseguiti per attivare gli eventuali problemi, in modo che questi possano essere registrati nel log di telemetria.
2. Un tester avvia il log di telemetria ed esamina il foglio di lavoro Events (Eventi) per individuare i documenti in uso. Sì accorge così che per tali file sono stati generati un errore e un avviso e che per ognuno è stata visualizzata una spiegazione corrispondente delle possibili cause del problema. Vedere l'esempio evidenziato di seguito nella Figura 2.
Figura 2: log di telemetria (Telemetry Log) - visualizzazione Eventi (Events) di esempio con un errore e un avviso per i documenti con la relativa spiegazione
3. Nella colonna Ulteriori informazioni (More Info) il tester fa clic sul collegamento (link) corrispondente al problema che sta analizzando, in questo caso il documento ConfidentialityAgreement_template.docx. Visualizza informazioni più dettagliate disponibili in MSDN, su cui può eseguire ulteriormente il drill-down e trovare informazioni utili perché lo sviluppatore possa risolvere il problema. Vedere l'esempio evidenziato di seguito nella Figura 3.
Figura 3: drill-down in MSDN per visualizzare ulteriori informazioni
4. Dopo che uno sviluppatore risolve il problema, il tester apre una copia aggiornata del file e vede che nel log di telemetria non sono stati registrati nuovi problemi.
In questo post del blog abbiamo parlato della funzione del log di telemetria e abbiamo spiegato come iniziare a utilizzarlo. Abbiamo inoltre illustrato come gli utenti finali, soprattutto gli sviluppatori e i tester, possono sfruttare a pieno le potenzialità di tale log.
Guida di riferimento per l'utilizzo del log di telemetria
Problemi di compatibilità in Office 2013
Questo è un post di blog localizzato. L'articolo originale è disponibile in Introducing Telemetry Log in Office 2013.
Articolo originale pubblicato mercoledì 19 settembre 2012
Questo post di blog è stato scritto da Nobuko Miwa, Program Manager del team Office Solutions Management.
AVETE MAI DESIDERATO GESTIRE I COMPONENTI AGGIUNTIVI PER OFFICE? Se siete professionisti IT che gestiscono l'utilizzo delle applicazioni, può esservi utile gestire anche i componenti aggiuntivi per Office. Impedendo ad esempio agli utenti finali di eseguire componenti aggiuntivi non approvati che possono causare problemi o incidere negativamente sulle prestazioni, potreste ridurre i costi di assistenza. Con Office 2013 forniamo una nuova funzionalità che consente di gestire l'utilizzo dei componenti aggiuntivi.
Utilizzando il dashboard di telemetria di Office 2013, è possibile monitorare l'utilizzo dei componenti aggiuntivi, nonché le prestazioni e altri problemi. Con i dati raccolti, è possibile decidere quali componenti aggiuntivi gestire. In questo articolo viene illustrato come gestire i componenti aggiuntivi per Office mediante il dashboard di telemetria.
È innanzitutto necessario distribuire il dashboard di telemetria. Per informazioni dettagliate sulla distribuzione del dashboard di telemetria, leggere questo articolo di TechNet.
Dopo aver configurato il dashboard di telemetria, visualizzare il relativo foglio di lavoro Soluzioni (Solutions), nel cui angolo in alto a destra è presente un collegamento Modalità gestione componenti aggiuntivi (Add-in management mode), come illustrato nella schermata seguente. Fare clic sul collegamento per visualizzare il foglio di lavoro Gestione componenti aggiuntivi (Add-in management).
Nel foglio di lavoro Gestione componenti aggiuntivi (Add-in management) è possibile decidere quali componenti aggiuntivi controllare in base all'utilizzo, al tempo di caricamento e ai problemi rilevati. Dopo avere deciso quali componenti aggiuntivi devono essere controllati, seguire le istruzioni visualizzate sul lato destro della schermata per creare uno script di Windows PowerShell per l'applicazione di tali impostazioni. Nella schermata seguente viene illustrato il foglio di lavoro Gestione componenti aggiuntivi (Add-in management) del dashboard di telemetria.
Ecco alcune note da considerare:
Le applicazioni in cui è possibile gestire i componenti aggiuntivi sono Excel, Word, Outlook, PowerPoint, Project, Publisher, Visio, OneNote, Access e InfoPath.
E questi sono i tipi di componenti aggiuntivi supportati:
Componente aggiuntivo COM
.dll
Componente aggiuntivo di automazione di Excel
Componente aggiuntivo XLL di Excel
.xll
Componente aggiuntivo di Excel
.xla, .xlam
Componente aggiuntivo RTD di Excel
Componente aggiuntivo di Word
.dot, .dotm, .dotx, .docm
Componente aggiuntivo di PowerPoint
.ppa, .ppam
Queste sono invece le opzioni che è possibile scegliere per gestire ogni componente aggiuntivo:
Un modo più restrittivo per gestire i componenti aggiuntivi consiste nel bloccare tutti i componenti aggiuntivi non gestiti utilizzando i file dei Modelli amministrativi di Office 2013 (admx)e quindi nell'utilizzare l'impostazione Consenti (Allow) precedentemente descritta per consentire agli utenti di utilizzare solo i componenti aggiuntivi specificati. Per ogni applicazione di Office 2013 supportata sono disponibili specifiche impostazioni di gestione dei componenti aggiuntivi. Tali impostazioni si trovano nei percorsi seguenti:
Dopo avere generato lo script di Windows PowerShell nel foglio di lavoro Gestione componenti aggiuntivi (Add-in management), è possibile eseguire lo script nel Modulo di Active Directory per Windows PowerShell. Nella console specificare il nome dell'oggetto Criteri di gruppo a cui applicare le impostazioni, come illustrato nella schermata seguente:
Si è ora pronti per collegare l'oggetto Criteri di gruppo creato a qualsiasi unità organizzativa.
Verificare ora come si stanno gestendo i componenti aggiuntivi nel client di Office. A tale scopo, aprire la finestra di dialogo Componenti aggiuntivi COM (COM Add-ins) nei computer client di Office eseguendo la procedura seguente:
È possibile vedere che i componenti aggiuntivi sono disabilitati e controllati dall'amministratore e che gli utenti finali non possono riabilitare il componente aggiuntivo nei loro computer, come illustrato nella schermata seguente:
Se i criteri di gruppo non sono stati ancora applicati, al prompt dei comandi è possibile eseguire il comando seguente per attivare il processo di aggiornamento:
gpupdate /force
Nobuko
Questo è un post di blog localizzato. L'articolo originale è disponibile in Let's manage add-ins using Telemetry Dashboard.
Articolo originale pubblicato sabato 27 ottobre 2012
Ormai è probabile che abbiate sentito che in Visio 2013 è stato introdotto un formato di file basato su XML, ovvero VSDX, per offrire nuove funzionalità in Visio, ad esempio la creazione condivisa, e per migliorare l'interoperabilità con le altre applicazioni. Se invece questa è una novità per voi, nel blog di Visio potrete trovare informazioni utili nel post VSDX: il nuovo formato di file di Visio. Se desiderate tutti i dettagli tecnici sul formato VSDX, leggete Introduzione al formato di file di Visio 2013 (con estensione vsdx) e Procedura: gestire il formato di file Visio 2013 a livello di programmazione su MSDN.
I nostri professionisti IT probabilmente ricordano le grandi difficoltà incontrate per il passaggio dal formato di file binario di Office 2003 al formato di file OpenXML utilizzato in Office 2007 e nelle versioni successive. Con Visio 2013, incontrerete le stesse difficoltà, anche se sicuramente riconoscerete anche voi che ne valga la pena. Questo nuovo formato VSDX presenta numerosi vantaggi, tra cui una dimensione più ridotta dei file, un miglior ripristino dei dati e un'interoperabilità più agevole.
Nuovi tipi di file in Visio 2013
In Visio sono previsti tre tipi di file principali, ovvero disegni, modelli e stencil. Questi tipi di file sono ancora disponibili nel nuovo formato, ma con una differenza: come per le altre applicazioni di Office, ora offriamo formati senza macro e con attivazione macro. Le nuove estensioni per ogni tipo di file sono riportate nella tabella seguente.
Senza macro
Con attivazione macro
Disegno
VSDX
VSDM
Modello
VSTX
VSTM
Stencil
VSSX
VSSM
Funzionalità di compatibilità in Visio 2013
In Visio 2013 sono disponibili diverse funzionalità di compatibilità utili per far passare gli utenti dal vecchio al nuovo formato. Tali funzionalità includono quanto segue:
Gli utenti possono trovare ulteriori informazioni sulle nuove funzionalità di compatibilità in questi articoli su Office.com:
Per impostazione predefinita, Visio 2013 salva i file utilizzando il formato VSDX. Questo tipo di salvataggio è appropriato se tutti gli utenti utilizzano Visio 2013. Se invece vi sono utenti che continueranno a utilizzare versioni precedenti di Visio, è possibile utilizzare Criteri di gruppo per impostare su VSD il tipo di file predefinito in Visio 2013. L'impostazione di Criteri di gruppo Salva file di Visio come è disponibile nei file dei Modelli amministrativi (ADMX/ADML) di Office 2013 e Strumento di personalizzazione di Office. Ricercare l'impostazione in Configurazione utente\Modelli amministrativi\Microsoft Visio 2013\Opzioni di Visio\Salvataggio\Salvataggio documenti.
I formati di file che possono essere impostati come tipo di file predefinito per Visio 2013 sono i seguenti:
Come sempre, lasciate un vostro commento se avete suggerimenti sul contenuto per professionisti IT relativo a Visio 2013.
Jill
Questo è un post di blog localizzato. L'articolo originale è disponibile in What IT Pros need to know about the new VSDX file format in Visio 2013.
Articolo originale pubblicato mercoledì 26 settembre 2012
Questo post di blog è stato scritto da Junko Kyomasu, Program Manager del team Office Solutions Management.
Il dashboard di telemetria di Office è un nuovo e potente strumento per la gestione dei documenti e dei componenti aggiuntivi di Office all'interno di un'organizzazione. Garantisce una migliore esperienza di aggiornamento dalla versione di Office esistente a Office 2013. Siamo lieti di sapere che molti di voi abbiano provato le funzionalità di telemetria disponibili in Office 2013, ma alcuni ci hanno detto di voler testare i componenti del dashboard in un gruppo di lavoro, ambiente che finora non era supportato. La configurazione del Registro di sistema per consentire il reporting immediato dei dati può essere un'attività molto ingannevole.
Per agevolarvi e velocizzarvi nella valutazione, abbiamo pubblicato uno script di Windows PowerShell, Deploy-TelemetryDashboard.ps1, che configurerà tutti i componenti di telemetria contemporaneamente! Potete eseguire lo script per installare i componenti in un computer del gruppo di lavoro o in un computer aggiunto al dominio. Lo script consente inoltre all'agente di telemetria incorporato di iniziare immediatamente a eseguire il reporting dei dati di telemetria. L'utilizzo di tale script rappresenta l'unico modo possibile per configurare i componenti del dashboard in un gruppo di lavoro.
Per ambienti di produzione contenenti centinaia o migliaia di computer client, è possibile distribuire i singoli componenti passaggio per passaggio come illustrato in Distribuire il dashboard di telemetria di Office.
Scaricate i file Deploy-TelemetryDashboard.ps1 e TDDB.bak dalla Raccolta TechNet ed eseguite Deploy-TelemetyDashboard.ps1 nel computer in cui è installato Office 2013.
Il gioco è fatto!
Lo script vi consentirà di configurare il dashboard di telemetria nel computer e di visualizzare immediatamente nel dashboard i dati di telemetria raccolti.
Lo script configurerà tutti i componenti necessari per iniziare a utilizzare il dashboard di telemetria. È necessario eseguire lo script in un computer in cui siano installate versioni Office Professional Plus 2013 o Office 365 ProPlus di Office 2013.
Lo script eseguirà le attività seguenti:
1. Creazione di due gruppi locali (solo nel caso di un gruppo di lavoro). Per consentire un accesso sicuro alla cartella condivisa e al database, lo script creerà due gruppi locali in un computer e aggiungerà ai gruppi l'utente attualmente connesso. I gruppi sono i seguenti:
TDAgent - gruppo locale che avrà accesso alla cartella condivisa
TDDatabase - gruppo locale che avrà accesso al database
2. Creazione di una nuova cartella condivisa. Si tratta del percorso in cui i computer client di Office caricheranno i dati di telemetria:
TDShared - cartella locale che verrà creata nell'unità di sistema, ad esempio C:\TDShared
3. Installazione del servizio Processore di telemetria di Office. Il servizio elaborerà i dati caricati dal computer client e li inserirà nel database.
*4. Ripristino del database di telemetria (solo nel caso di un gruppo di lavoro). Lo script ripristinerà un database vuoto.*Nota: nel caso di un computer aggiunto al dominio, lo script avvierà l'Impostazione guidata Processore di telemetria di Office invece di ripristinare un database vuoto. È possibile creare un nuovo database seguendo tale impostazione guidata.
5. Configurazione dell'agente di telemetria. L'agente di telemetria è incorporato nelle versioni Office Professional Plus 2013 e Office 365 ProPlus di Office 2013. Lo script scriverà i valori del Registro di sistema che consentono all'agente di raccogliere e caricare i dati. Per ulteriori informazioni sui singoli valori del Registro di sistema, vedere Agente di telemetria di Office.
6. Esecuzione dell'attività dell'agente. L'agente di telemetria verrà attivato dall'attività pianificata. Lo script eseguirà l'attività dell'agente (Microsoft\Office\OfficeTelemetryAgentLogOn) manualmente, in modo che l'agente raccolga e carichi i dati di telemetria nella cartella condivisa.
7. Avvio del dashboard di telemetria. Dopo che tutte le impostazioni sono state distribuite correttamente e che l'agente ha caricato i dati di telemetria, lo script avvierà il dashboard di telemetria.
8. Esportazione dei valori del Registro di sistema per l'agente. È possibile esportare le impostazioni del Registro di sistema per l'agente, in modo che le stesse impostazioni vengano inviate agli altri computer client di Office che dispongono dell'agente di telemetria.
Speriamo che questo script di Windows PowerShell vi aiuti a configurare senza problemi le funzionalità di telemetria di Office, in modo che possiate iniziare a recuperare i dati di telemetria necessari per eseguire correttamente l'aggiornamento a Office 2013 e a usufruire delle tante e fantastiche funzionalità che offre.
Le vostre domande e i vostri commenti su questo script sono ben accetti. Se avete quesiti o osservazioni, aggiungeteli nel post oppure nella scheda Domande e risposte della Raccolta TechNet.
Questo è un post di blog localizzato. L'articolo originale è disponibile in Quickly set up Office Telemetry Dashboard on a workgroup or domain-joined computer.
Articolo originale pubblicato mercoledì 17 ottobre 2012
Abbiamo pubblicato un nuovo poster di Visio e un nuovo articolo sulla compatibilità e la telemetria in Office 2013. Entrambi rappresentano un buon punto di partenza per i professionisti IT che desiderano informazioni generali senza entrare troppo nel dettaglio.
Nel poster di Visio (disponibile anche nei formati PDF e Zoom-it) viene descritto il funzionamento della telemetria in Office 2013. Vengono fornite inoltre informazioni sui componenti della telemetria, sui tipi di file e le soluzioni monitorati, sul processo di monitoraggio e altro ancora.
Nella nuova guida alla compatibilità di Office 2013 viene descritto il processo "moderno" di compatibilità di Office e viene illustrato il modo in cui questo processo è supportato dalla telemetria di Office. Vengono messi a confronto processi come l'individuazione e l'inventario, viene illustrata l'importanza dell'utilizzo dei gruppi aziendali, viene indicato come eseguire test di accettazione utenti utilizzando A portata di clic e così via.
Come sempre, siamo lieti di ricevere vostri commenti e suggerimenti e vi invitiamo a controllare ogni settimana l'eventuale disponibilità di contenuto nuovo e aggiornato.
Questo è un post di blog localizzato. L'articolo originale è disponibile in New Office 2013 compatibility and telemetry content for IT Pros in the Office Resource Kit.