IoT Day con Hackster Live e Intel Innovator Tour al PoliBa

ICTPower e DotNetSide organizzano, in collaborazione con Hackster Live ItaliaIntel Innovator Tour e Microsoft, una giornata completamente gratuita dedicata al mondo IoT, dalla realtà dei microcontrollori e dei maker, fino alla sensoristica e all’automazione industriale, con interventi da parte di Microsoft MVP, Intel Innovators ed esperti riconosciuti a livello internazionale.

Durante questa giornata potrete scoprire tutte le soluzioni proposte da Microsoft che permettono di sfruttare le potenzialità dell’IoT in modo semplice, disponendo di una piattaforma completa e, nel laboratorio del pomeriggio, avrete la possibilità di provare i tool in prima persona. Tutti gli speaker saranno a disposizione per rispondere alle vostre domande e curiosità.

Vi aspettiamo il 10 marzo 2017 presso il Politecnico di Bari c/o Campus Universitario, Sala Videoconferenza presso l’Amministrazione Centrale del Politecnico di Bari in Via Amendola, 126/B (piano -1). L’evento è, come di consueto, gratuito, ma con posti limitati.

Dove: Amministrazione Centrale del Politecnico di Bari in Via Amendola 126/B,  Sala Videoconferenza (piano -1).
Quando: venerdì 10 marzo 2017 ore 09:00

Non perdere l’occasione di partecipare a questo evento, i posti sono limitati!

REGISTRATEVI QUI

DevOps, Agile e Lean: non è più concesso ignorarli

DevOps è diventato ormai il killer-approach per la delivery di soluzioni che siano in grado di avere un basso time-to-market e ottimizzare l’intero value stream aziendale annesso.

Devo ammettere che da sempre considero DevOps la naturale estensione dell’Agile, con una positiva contaminazione dei principi Lean (che ricordo sono derivati dal mondo manifatturiero), cosa che mi porta ad amare poco il termine “DevOps” in sé perché, almeno lessicalmente, sembra limitare il tutto ai Developer ed agli Operation oltre che all’ambito IT.

solution s curve

Detto questo, è importante evidenziare che DevOps non “appartiene” solo al mondo dell’IT, bensì è un approccio che spinge a far propri i 3 principi portanti: Flow, Feedback e Learning (così come sono oggi riformulati rispetto alla prima enunciazione), per un’azione efficace nella creazione di Servizi e Prodotti negli ambiti più diversi. A tal proposito segnalo l’interessante approfondimento degli amici di AgileReloaded: L’orizzonte allargato di Agile.

Resta comunque indubbio che l’IT è la culla di DevOps, trasformando gradualmente le azioni annesse allo sviluppo di soluzioni complesse da attività “artigianali” ad attività più “ingegneristiche”, con precisi elementi di riferimento. Ciò fa si che le aziende percepiscano sempre più il proprio IT per quello che deve essere: un Asset strategico al servizio del Business e non un Centro di Costo.

E le parole sono estremamente importanti: parlare di “divisione IT” porta ad immaginare un Silos a sé stante con regole proprie e ben identificabili. Ciò è quanto di più semplicistico si possa immaginare perché l’IT è estremamente pervasivo e condiziona, restandone a sua volta condizionato, tutte le aree aziendali.

La centralità di DevOps, anche se non del tutto maturata nel nostro contesto nazionale, è confermata da un’indagine di IDC che oggi ne vede l’adozione in oltre il 70% delle principali aziende mondiali (con livelli diversi e penetrazione diversa) e stima il superamento della soglia dell’80% entro il 2019.

Ma questa penetrazione così profonda, quali sfide comporta?

Anche qui dobbiamo avere una visione olistica del contesto poiché molte aziende che provano a sperimentare DevOps su un progetto pilota o un’area di riferimento, si accorgono rapidamente che è necessario coinvolgere tutte le diverse funzioni aziendali, per cui lo Scaling diventa inevitabile e anche estremamente veloce.

Ma torniamo alla nostra precedente domanda, andando ad evidenziare le sfide primarie che ogni azienda incontra nell’adozione concreta di DevOps e, quindi, nel profondo percorso di trasformazione e cambiamento Culturale:

  • Sponsorship aziendale: adottare DevOps significa investire e avere pazienza nell’ottenere risultati tangibili localizzati a breve termine, ma complessivamente visibili nel medio termine. L’investimento è sia in termini finanziari che in termini di impegno delle Persone (vi prego… non usate il termine “risorse” per indicarle!), per cui solo se è uno dei massimi dirigenti aziendali (CxO) a supportarla, l’adozione potrà avere il sostegno necessario e raggiungere risultati lusinghieri;
  • Abbandonare le rigide strutture di controllo del passato: una Cultura volta al continuo miglioramento, basata su applicazioni empiriche, mal si lega con una organizzazione aziendale basata sul pattern command-and-control, in cui è difficile cambiare. I manager devono imparare a delegare, mentre le linee più operative ad avere coraggio, cercando di rendere la struttura più flessibile ma soprattutto focalizzata sul value stream;
  • Il Core know-how deve essere in azienda: considerare l’IT un “centro di costo” ha portato negli anni ad abusare dell’outsourcing, perdendo conoscenza, controllo e capacità di gestire le nuove sfide di mercato. Questa tendenza deve trasformarsi in un’outsourcing bilanciato in cui gli elementi chiave, per rispondere efficacemente e prontamente al Business, sono all’interno e ci si appoggia ad un’outsourcing controllato per gli elementi corollari (abbiamo parlato abbondantemente di questo aspetto nella serie DevOps and Outsourcing: OutOps);
  • Ridurre la resistenza al cambiamento: DevOps è Cultura, e una trasformazione aziendale nella sua direzione comporta nuovi modelli organizzativi, nuovi ruoli e un diverso approccio alle prospettive di carriera. Questi aspetti spingono ad aumentare la resistenza al cambiamento per restare nella propria “confort zone” e ridurre al minimo la necessità di rimettersi in discussione. È compito dell’organizzazione fare chiarezza su questi aspetti e creare le opportunità a sostegno dei desideri intersechi (leggasi Management 3.0) ed estrinsechi di ogni singolo collaboratore;
  • Fail Fast o meglio… Learn Fast: il fallimento è una componente poco desiderata ma fortemente presente, e a volte indispensabile, nel mondo dei sistemi complessi. Il mantra non deve essere: “non fallire mai…” ma “fallire il meno possibile e quando accade far tesoro del fallimento stesso”. In pratica ogni fallimento diventa un tassello nel cambiamento e nell’ottimizzazione complessiva… chiaramente questo non vuol dire fallire sempre!
  • Mai applicare qualcosa “out-of-the-book”: DevOps è un cambiamento culturale da ricamare nel proprio contesto e come tale necessita di essere capito profondamente nelle sue varie sfaccettature. Non basta comprare un libro e leggere qualche blog per iniziare la propria trasformazione: il rischio di fallimento è estremamente elevato! Meglio affidarsi al supporto di professionisti che accompagnano l’organizzazione a muovere i primi passi e ad individuare gli elementi focali che consentono affacciarsi al mondo DevOps con maggiore fiducia e minori incertezze.

Se tutto questo vi spaventa o vi fa tornare nel “vostro mondo” fatevi una domanda: possiamo permetterci di non cambiare quando tutto sta evolvendo ad un ritmo frenetico ed inarrestabile?

In fondo bisogna lasciare andare il passato per essere padroni del futuro.

Stay tuned J

Veeam Backup for Office 365: Estendere la protezione con Veeam Agent

Come abbiamo già avuto occasione di vedere nell’articolo introduttivo dedicato a Veeam Backup for Office 365, non è ancora possibile salvare il contenuto dei database all’interno di un repository di Backup & Replication, ma solo in volumi locali o share SMB.

Per risolvere il problema, fino a quando la funzionalità non sarà implementata nativamente, possiamo sfruttare Veeam Agent for Windows ed estendere le capacità di protezione in un repository centralizzato. Per chi non conoscesse ancora Veeam Agent, è l’evoluzione del famoso Veeam Endpoint, la soluzione di backup dedicata alle macchine fisiche, sia server che client.

La logica da applicare è molto semplice e consiste del proteggere la cartella dove salviamo i database Office 365, all’interno del repository centralizzato di Backup & Replication.

Configurazione Backup

Come prima cosa va creato un nuovo Backup Job, puntando alla cartella dove si trovano i file Office 365, come mostrato nella figura 1.

Figura 1 – Selezione Cartella

Il secondo passo è quello di scegliere il repository di Backup & Replication, che dovrà essere la versione 9.5 con l’Update 1 installato – figura 2.

Figura 2 – Veeam Repository

Se avete abilitato correttamente un repository per poter essere utilizzato dagli Agent, figura 3, potrete procedere con il wizard. Un aspetto su cui fare molta attenzione è relativo alla retention; avete a disposizione due differenti valori: il primo dato da Backup for Office 365 ed il secondo dato da Veeam Agent, questo significa che bisogna evitare di avere valori troppo elevati da entrambe le parti.

Ad esempio si può avere una retention, all’interno di Backup for Office 365, di 3 anni e di solo 4 giorni dentro Veeam Agent. Questo ci permette di non raddoppiare lo spazio necessario e di snellire la procedura di salvataggio dentro il repository di Backup & Replication.

Figura 3 – Selezione Repository e Retention

Completato il wizard sarà possibile eseguire il job di salvataggio all’interno dell’infrastruttura Veeam Backup & Replication. Il tempo di esecuzione varierà a seconda della grandezza del database source e della performance della vostra infrastruttura.

Figura 4 – Backup in Veeam Agent

Figura 5 – Backup in Veeam Backup & Replication

Conclusioni

Ecco un veloce esempio di integrazione tra due prodotti teoricamente slegati ma che praticamente si possono integrare ed offrire un risultato molto interessante per tutte le aziende che intendono proteggere al meglio la propria infrastruttura….anche se i dati si trovano sul cloud.

Nakivo Backup & Replication: configurare la Replica VMware

Nakivo Backup & Replication: configurare la Replica VMware

nakivoreplication01

La funzione di replica per VMware permette di creare una copia identica della VM sorgente nell’host ESXi di destinazione in stato di power off pronta per essere attivata in caso di necessità.

Dovuto al suo stato di power off, la copia della VM (replica) non consuma nessuna risorsa ed è disponibile in VMware vSphere. Per una replica possono essere creati fino a 30 punti di recupero  e sono disponibili come una regolare snapshot della VM permettendo agli amministratori di ritornare allo stato funzionale richiesto anche senza utilizzare Nakivo Backup & Replication.

nakivoreplication02

Con la replica è possibile proteggere i sistemi più critici salvando le copie localmente o fuori sede. Se la VM sorgente presenta dei problemi, è possibile effettuare immediatamente il failover dalla VM sorgente alla VM replicata riducendo drasticamente il tempo richiesto per il ripristino.

Rispetto al classico restore dai backup, la replica permette di minimizzare la lunghezza del fuori servizio causando solo una minima interruzione dei servizi di rete.

Basata sulla tecnologia delle VM snapshot, la prima replica è una copia identica della VM sorgente e supporta le tipologie di dischi VM sparse, thin, thick e flat. Utilizzando la tecnologia VMware CBT, il processo di replica successivo è di tipo forever incremental in quanto combina solamente i blocchi di dati variati della VM sorgente dall’ultimo punto di verifica creando un nuovo punto di ripristino. Questo processo permette di incrementare drasticamente la velocità di replica.

 

Configurare un Replication job

Dalla Dashboard Nakivo, cliccare sul menu Create e selezionare la voce VMware vSphere replication job.

nakivoreplication03

Selezionare la VM da replicare e cliccare su Next.

nakivoreplication04

Specificare il Container, Datastore e Network per la replica. Cliccare Next per continuare.

nakivoreplication05

Impostare la pianificazione per eseguire la replica e cliccare su Next.

nakivoreplication06

La replica può essere impostata per essere effettuata ogni minuto in modo da ottenere quasi una replica in tempo reale.

nakivoreplication07

Specificare il Job name, la retention ed i parametri richiesti. Cliccare su Finish per salvare la configurazione del job. Impostando l’opzione App-aware mode come Enabled, il prodotto garantisce che i dati nelle applicazioni e nei database siano sempre consistenti.

nakivoreplication08

Un’opzione utile è la Replica disks che permette di creare thin disks nella VM di destinazione per risparmiare spazio.

nakivoreplication09

La voce Screenshot verification permette la verifica della replica per garantire un corretto ripristino della VM.

nakivoreplication10

Dalla Dashboard, effettuare un click con il tasto destro del mouse sul job di Replica appena configurato e selezionare la voce Run Job per eseguire il job immediatamente.

nakivoreplication11

Cliccare su Run per procedere.

nakivoreplication12

La replica viene eseguita.

nakivoreplication13

Quando il job viene completato correttamente, nella parte destra della schermata vengono visualizzate tutte le info relative al job eseguito.

nakivoreplication14

 

Effettuare il Failover

Quando la VM nel sito primario presenta un problema, è possibile spostare il carico (failover) dal sito di produzione al sito DR per ripristinare velocemente i servizi di rete. La VM ripristinata dalla replica contiene tutte le variazioni rispetto all’ultima replica effettuata.

Dalla Dashboard, cliccare sul menu Recover e selezionare l’opzione VMs from replica.

nakivoreplication15

Selezionare la replica da ripristinare e il recovery point desiderato. Cliccare su Next.

nakivoreplication16

Specificare la Network da utilizzare e cliccare su Next.

nakivoreplication17

Inserire il Job name e cliccare su Finish per salvare la configurazione.

nakivoreplication18

Effettuare un click con il tasto destro del mouse sul job appena creato e selezionare Run Job.

nakivoreplication19

Cliccare su Run Recovery per effettuare il power on della replica.

nakivoreplication20

Il job di Recovery viene mandato in esecuzione.

nakivoreplication21

Quando il job viene completato, nella parte destra dello schermo sono visualizzate tutte le Job Info.

nakivoreplication22

Dal vSphere Web Client è possibile verificare la replica in esecuzione.

nakivoreplication23

 

Effettuare il Failback

Quando la VM problematica nel sito primario viene ripristinata, viene effettuato il processo di failback per ritrasferire il carico al sito primario.

Quando viene effettuato il failback verso la produzione, devono essere considerati due scenari:

  • Scartare le modifiche – le variazioni nella VM ripristinata possono essere scaricate
  • Mantenere le modifiche – le variazioni nella VM ripristinata dalla replica devono essere mantenute e messe in produzione

 

Scartare le modifiche

Per scaricare i dati variati, dal vSphere Web Client effettuare un click con il tasto destro del mouse sulla VM ripristinata e selezionare l’opzione Power > Shut Down Guest OS.

nakivoreplication24

Dalla Dashboard Nakivo, effettuare un click con il tasto destro del mouse sul Recovery job precedentemente creato e selezionare Delete.

nakivoreplication25

Selezionare l’opzione Delete job and recovered VMs e cliccare su Delete per confermare l’operazione. Tutte le modifiche verificatesi nella VM vengono scaricate e quindi perse.

nakivoreplication26

Effettuare il power on della VM sorgente nel sito primario per ripristinare il servizio.

 

Mantenere le modifiche

Se le modifiche devono essere mantenute e spostate nella VM di produzione, è sufficiente replicare la VM ripristinata in produzione. Dalla Dashboard Nakivo, effettuare un click con il tasto destro del mouse sul Recovery job precedentemente creato e selezionare Delete.

nakivoreplication27

Selezionare l’opzione Delete job and keep recovered VMs e cliccare su Delete per confermare.

nakivoreplication28

Creare un nuovo job di replica per la VM che si intende recuperare in maniera permanente ed utilizzare l’opzione Use existing VM as a target nello STEP 2. Questo effettua il trasferimento di tutte le modifiche nella VM in produzione.

nakivoreplication29

Per garantire una perdita nulla di dati, spegnere la VM recuperata dal VMware vSphere client ed effettuare la replica della VM nuovamente.

nakivoreplication30

Effettuare il Power on della VM creata dal job di replica.

nakivoreplication31

La VM nel sito primario è ora pienamente funzionale mantenenedo tutte le modifche verificatesi durante la fase di failover.

signature

Copyright Nolabnoparty. All Rights Reserved.

Lentezza durante l’apertura di Dispositivi e stampanti

In Windows 10, 8.1, 8, 7 può capitare che l’applet Dispositivi e stampanti venga aperto con un ritardo di diversi secondi.

Il motivo di questo tempo di ritardo può dipendere da varie cause in quanto l’applet Dispositivi e stampanti si occupa di visualizzare e gestire di fatto tutti i dispositivi del computer e quindi le cause del tempo di attesa possono essere:

  • Driver non aggiornati
  • Problemi di rete, infatti all’apertura dell’applet vengono scaricati da Internet i metadati dei dispostivi e, se abilitato, viene eseguito il Network Discovery
  • Problemi con eventuali dispositivi come ad esempio l’audio o Bluetooth

Per maggiori informazioni su come disabilitare il Network Discovery (tale funzionalità è disabilitata per default nel profilo di rete di Dominio) e se abbia senso farlo si veda il post Disabling Network Discovery/Network Resources:

The official guidance for disabling Network Discovery is to disable it in the Network and Sharing Center GUI or in the Windows Firewall interface itself, but people are often confused because they continue to see machines in the Network Resources list even after selecting this option. The thing to remember is that not all the providers are Network Protocols. There is the registry and Windows Connect Now for example. Disabling the Network Discovery via the Firewall will stop the incoming network traffic but it won’t stop other non-network sources. It also doesn’t block outgoing traffic so the machine will still broadcast via NetBIOS for example.

Another reason people want to disable Network Discovery is that they have a performance issue and the knee-jerk reaction is to disable the feature instead of resolving the performance issue.

So what to do if you disabled Network Discovery in the Firewall and still see machines in the Network Resources list? Or still see a performance issue? Network Discovery is made of multiple protocols. You need to identify which service/port is being used to gather the data or having the performance issue and troubleshoot that.

La configurazione della funzionalità Network Discovery può essere gestita tramite le Group Policy contenute nel gruppo Computer Policy\Policies\Administrative Templates\Network\Link-Layer Topology Discovery:

Il download dei metadati dei dispositivi può essere gestito tramite la Group Policy Prevent device metadata retrieval from the internet in Computer Policy/System/Device Installation (a riguardo si veda Manage connections from Windows operating system components to Microsoft services)

Per una discussione sul problema si veda il thread Windows 10: How Long Does It Take to Open Devices & Printers?.

Si tenga presente che corrispondente app in Impostazioni \ Dispositivi non presenta ritardi all’apertura.

Nel caso sia necessario gestire le stampanti, ma  non si riesca ad indentificare la causa del problema o se la causa non è immediatamente risolubile come  ad esempio nel caso di driver aggiornati non disponibili o problematiche di rete causate da infrastrutture fisiche obsolete con cavi rovinati o in categoria 5 è possibile aprire un’altra applet per gestire le stampati.

Le stampanti possono infatti anche essere gestite tramite l’applet avviabile tramite il comando:

shell:PrintersFolder

Per i comandi utilizzabili per visualizzare le cartelle si sistema e utente si veda Shell: folder shortcuts, a riguardo si veda anche Shell Commands to Access the Special Folders in Windows 10/8/7/Vista/XP.

Licenze di Veeam Backup for Microsoft Office 365 per vExpert e MVP

Veeam ha annunciato la disponibilità di licenze NFR (Not for Resale) gratuite (per 1 anno e fino ad un massimo di 10 utenti) del nuovo prodotto Veeam Backup for Microsoft Office 365. Le licenze sono disponibile per tutti i VMware vExpert, Microsoft MVP, VTEC member, Certified Engineer e Trainer e sono destinati ad ambienti non‑production ma senza limiti di funzionalità (utiler per lab, ma anche per gli MVP per proteggere i propri dati sull’account Office 365). Per richiedere la licenza, basta registrarsi a questo link. Utilizzando Veeam Backup for Microsoft Office 365 è possibile: Avere il controllo […]

The post Licenze di Veeam Backup for Microsoft Office 365 per vExpert e MVP appeared first on vInfrastructure Blog.

Installazione centralizzata dei driver

La distribuzione dei driver da una posizione centralizzata può essere utile in vari scenari, come ad esempio nel caso si desiderino gestire stampanti di rete mediante driver V4.

Nel caso dei driver di stampante V4 infatti il server di stampa non distribuisce più i driver ai clinet, ma quest’ultimi devono reperirlo autonomamente in modo da reperire quello più appropriato in base all’architettura e alla versione del sistema operativo. A riguardo si veda il seguente Printer Sharing Technical Details:

Typically, v4 print drivers are published to Windows Update and will be installed automatically when a connection is made if the client has Windows Update access, and if a matching driver is available. In an enterprise, there are other mechanisms that can be used; Windows Server Update Services (WSUS), DevicePath, and standard deployment tools.

Oltre alla possibilità di gestire l’installazione di driver tramite Windows Update è possibile, come indicato utilizzare altri meccanismi per l’installazione centralizzata dei driver.

Deploy di driver tramite DevicePath

Questo approccio si basa sul fatto che durante un’installazione PnP di un dispositivo dopo la ricerca del driver eseguita nello store locale e prima che venga avviata la ricerca in  Windows Update è possibile eseguire la ricerca del driver anche in una share o in un altro percorso locale.

E’ possibile gestire la ricerca tramite DevicePath modificando il valore DevicePath nella chiave di registro HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion che per default è impostata a %systemroot%\inf aggiungendo eventuali altri path di ricerca separati da punto e virgola, ad esempio (a riguardo si veda Modify the DevicePath Registry Key):

%systemroot%\inf;c:\drivers;\\share\drivers

Deploy di driver tramite WSUS

WSUS per default permette di gestire gli aggiornamenti per sistemi operativi, software Microsoft e driver, ma in molti casi l’installazione dei driver non può avvenire senza input dell’utente o i driver presenti sul Microsoft Catalog potrebbero non essere ancora presenti o aggiornati.

image

Volendo è però possibile utilizzare la funzionalità di Local Publishing di WSUS che permette di eseguire il deploy centralizzato di pacchetti di setup firmati digitalmente per applicazioni di terze parti o driver come indicato in Printer Sharing Technical Details anche se questo approccio richiede una maggior conoscenza tecnica.

“WSUS allows administrators to easily search and import driver packages from the Microsoft Update Catalog. If the v4 driver that needs to be deployed is not available in the Microsoft Update Catalog, it can still be distributed through WSUS using Local Publishing. Using Local Publishing in WSUS requires a high level of technical understanding and the ability to author update packages. This option is not recommended if a suitable driver is available on the Microsoft Update Catalog or in situations where Basic v4 Sharing with Customized user interface would be sufficient.”

Per maggiori informazioni circa l’utilizzo e la configurazione del Local Publishing in WSUS si veda anche il link Local Publishing su MSDN dove viene ribadito che questo approccio comporta l’esigenza di maggiori skill per la sua implementazione e possibili issues nella visualizzazione della WSUS administration console:

“The WSUS API allows you to create and publish custom updates, applications, and device drivers for your organization. The process of authoring and distributing this kind of update is called local publishing. Local publishing is best performed by organizations that have dedicated development and testing resources, since the planning, implementation, testing, and deployment of custom updates is a complex and time-consuming process.”

The WSUS user interface will not display locally-published updates, and will distribute only the updates that are available on Microsoft Update and Windows Update. If a WSUS server has locally-published updates, in some cases updates may not display correctly in the WSUS administration console.”

Esiste però il progetto Open Source Wsus Package Publisher che può semplificare l’implementazione del Local Publishing in WSUS in grado di supportare Wsus 6.2, 6.3 e 10 (Windows Server 2012, 2012R2, and 2016). Nella sezione Documentation del sito Codeplex dedicato al progetto Wsus Package Publisher sono già disponibili varie guide tra cui quelle per l’installazione e l’implementazione:

Wsus Package Publisher non è altro che un’applicazione .NET 4.0 che si avvale di altre applicazioni e che non necessita di un’installazione nel sistema. Dai test che ho effettuato nel caso si rimuovano pacchetti aggiunti tramite Wsus Package Publisher conviene eseguire poi dalla console di WSUS la Pulizia guidata server. Si tenga conto che Wsus Package Publisher pubblica comunque i pacchetti di setup in WSUS quindi potrebbero verificarsi gli issues sulla visualizzazione della WSUS administration console come indicato precedentemente.

Se necessario è possibile utilizzare ad esempio Advanced Installer per creare un setup msi per i driver, come ad esempio nel caso del TOSHIBA e-STUDIO V4 Printer Driver, per eseguire il deploy tramite Wsus Package Publisher.

Deploy di driver tramite System Center Configuration

La soluzione Microsoft per una gestione strutturata dei driver è System Center Configuration Manager tramite cui è possibile eseguire il deploy di driver e creare driver package, per maggiori informazioni si veda Manage drivers in System Center Configuration Manager.

Programma Windows Insider per professionisti IT

Durante una sessione dell’evento Microsoft Ignite Australia 2017 in programma dal 14 al 17 febbraio 2017 a Broadbeach – Microsoft ha dato seguito ad una raccomandazione, fatta recentemente da Dona Sarkar alla conferenza Microsoft NexTech Africa, rivolta a piccole, medie e grandi aziende. Esse, secondo il team di Windows, dovrebbero avere almeno l’1% di macchine con su le build Insider di Windows 10.

Fino ad oggi non esisteva un programma specifico per questo tipo di utenza ed ecco l’annuncio, da parte di Bill Karagounis, del programma Windows Insider dedicato ai professionisti IT (WIP4Biz).

L’obiettivo di WIP4Biz è quello di supportare maggiormente le aziende che hanno al proprio interno un reparto IT. Questo permetterà di preparare meglio la migrazione del parco macchine a Windows 10, testare in anticipo nuove funzionalità del sistema operativo, distribuire nuovi servizi e strumenti in maniera più rapida, rendere più sicure le applicazioni aziendali e migliorare la produttività all’interno dell’ambiente di lavoro.

Chiaramente questo miglioramento del programma Insider porterà a Microsoft maggiori feedback su Windows 10, in particolare dagli utenti del mondo business. Non mancheranno forum, blog, notizie ed eventi locali.

Al momento non ci sono informazioni precise sul nuovo programma, ma sappiamo che nei prossimi mesi saranno aggiunte nuove funzionalità per professionisti IT al programma Windows Insider esistente.

Intanto potete compilare il form presente a questa pagina per ricevere i dettagli sul come accedere, in futuro, a queste nuove funzioni riservate agli Insider.

Fonte | Neowin

Runecast Analyzer aggiornamento offline

Runecast Analyzer aggiornamento offline

runecastofflineupdate01

L’appliance Runecast Analyzer può essere configurata per installare i KB aggiornati utilizzando l’aggiornamento offline nel caso di mancanza di connettività Internet.

Poichè Runecast Analyzer utilizza le informazioni dagli articoli del VMware Knowledge Base per effettuare lo scan proattivo dell’infrastruttura vSphere e rilevare potenziali problematiche, mantenere il sistema aggiornato è fondamentale per avere il più alto livello di efficienza.

Effettuare il login al sito web Runecast e scaricare l’aggiornamento offline cliccando sul bottone Download offline update.

runecastofflineupdate02

 

Configurare l’appliance

Da vSphere Web Client, effettuare l’upload del file ISO relativo all’offline update nello storage utilizzato dall’appliance Runecast.

runecastofflineupdate03

Effettuare un click con il tasto destro sull’appliance e selezionare Edit Settings.

runecastofflineupdate04

Espandere il gruppo CD/DVD drive 1 e cliccare sul bottone Browse.

runecastofflineupdate05

Individuare nello storage e selezionare il file ISO caricato e cliccare su OK.

runecastofflineupdate06

Quando il campo CD/DVD Media punta all’offline update corretto, cliccare su OK per salvare la configurazione.

runecastofflineupdate07

 

Aggiornare Runecast Analyzer

Utilizzando il browser preferito, digitare l’indirizzo https://IPaddress_appliance:5480 ed inserire le credenziali amministrative. Cliccare su Login per accedere alla dashboard di amministrazione.

runecastofflineupdate08

Accedere alla sezione Update > Settings ed impostare il campo Update Repository come Use CDROM Updates. Cliccare Save Settings per salvare la configurazione.

runecastofflineupdate09

Nella sezione Status cliccare la voce Check Updates. Da notare l’attuale Appliance Version 1.0.0.31.

runecastofflineupdate10

Il sistema verifica gli aggiornamenti disponibili direttamente dal file ISO.

runecastofflineupdate11

Quando il nuovo aggiornamento viene rilevato, cliccare su Install Updates per aggiornare l’appliance.

runecastofflineupdate12

Cliccare OK per confermare.

runecastofflineupdate13

Il sistema installa l’aggiornamento disponibile.

runecastofflineupdate14

Quando il processo viene correttamente completato, il campo Appliance Version indica la versione aggiornata 1.0.0.34.

runecastofflineupdate15 Accedere alla dashboard Runecast Analyzer per utilizzare le nuove funzioni.

runecastofflineupdate16

Il processo di aggiornamento è ora completo. Consultare questo articolo per la procedura completa di installazione e configurazione di Runecast Analyzer.

signature

Copyright Nolabnoparty. All Rights Reserved.

RDS2012R2/2016: Connettersi attraverso l’RD-Gateway se il dominio pubblico è diverso dal local domain in active directory

Quando ci si collega ad un’infrastruttura RDS passando attraverso il Remote Desktop Gateway il compito del certificato pubblico e del nome del dominio interno ed esterno sono molto importanti.

Il compito del certificato SSL pubblico installato sul/sui server di un’infrastruttura RDS è quello di autenticarci e di farci passare tramite SSO, prima sull’RD-Gateway, e poi sull’RD-Connection Broker. Ma per far si che tutto questo giro funzioni il nome del server scritto nel certificato SSL deve essere perfettamente uguale al nome dell’RD-Gateway, inoltre il nome del dominio pubblico deve coincidere con quello in Active directory.

Infatti se analizziamo il file RDP che si esegue quando mi collego tremite l’RD-WebAccess (es. app WordPad) noteremo che tutti i campi evidenziati hanno lo stesso nome di dominio e nel campo gatewayhostname:s:: è indicato il nome esatto del nome del certificato SSL.

  • remoteapplicationprogram:s:||WordPad
  • gatewayhostname:s:gateway.dominio.eu  —————> nome del certificato SSL
  • remoteapplicationname:s:WordPad
  • workspace id:s:srv-rds01.dominio.eu
  • loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.QuickSessionCollection
  • alternate full address:srv-rds01.dominio.eu
  • full address:s:srv-rds01.dominio.eu

Se il nome del certificato pubblico corrisponde al nome del dominio interno tutto funzionerà perfettamente.

In questo scenario infatti il nome del certificato SSL coincide col nome del dominio interno e verrà anche risolto dal DNS server del dominio interno, vedi Figura 1

image

Figura 1

Quando invece il nome del server indicato sul certificato SSL è diverso dal nome di dominio interno (esempio .local, .private, .demo, .lab etc) , non avverrà il “match” tra il nome del dominio interno e il nome scritto nel certificato SSL.

Nell’esempio, indicato in Figura 2, il nome scritto nel certificato SSL è dominio.eu mentre il nome del dominio Active Directory è dominio.local

image

Figura 2

Per risolvere il problema si deve cambiare il “Client Access Name” il nome del CB-Connection Broker che viene specificato nel file .rdp in modo che corrisponda al nome del certificato SSL e che venga mantenuto e risolto anche nel dns interno.

Un forte ringraziamento ad un mio collega MVP Toby Phipps che ha creato uno script che esegue il cambio del nome del CB-Connection Broker e prelevabile a questo link

Come accennato, anche il DNS interno dovrà riconoscere e risolvere il nome del server, si dovrà quindi aggiungere una zona con il nome del dominio pubblico e gli host con il nomi dei server con i rispettivi indirizzi interni. In realtà si potrebbero anche aggiungere i record nel file hosts locale del client che si deve collegare ma, ovviamente, è molto meno gestibile e facilmente dimenticabile.

Il risultato sarà come raffigurato nella Figura 3

 

image

Figura 3

Blog italiani (e in italiano) nel mondo IT/ICT