Talvolta può accadere di dover compattare dei dischi virtuali vhd/vhdx di VM perché a seguito del normale funzionamento questi hanno assunto dimensioni elevati che però sono di fatto molto superiori al reale spazio occupato.

Di seguito la procedura che è necessario eseguire per ridurre al massimo il file vhd/vhdx:

Passo 1: Deframmentare il disco avviando la procedura di deframmentazione all’interno dell’OS della VM

Passo 2: Arrestare la macchina virtuale

Passo 3: Montare il vhd/vhdx in read only tramite interfaccia grafica dell’applet Disk Management o tramite il cmdlet PowerShell Mount-VHD:

Mount-Vhd –path <Path del file vhd/vhdx> -readonly

Passo 4: Eseguire una compattazione  tramite l’interfaccia grafica dell’applet Hyper-V manager o tramite il cmdlet PowerShell Optimize-VHD:

Optimize-Vhd -path <Path del file vhd/vhdx> -Mode Full

Passo 5: Disconnettere il vhd/vhdx in read only tramite interfaccia grafica dell’applet Disk Management o tramite il cmdlet PowerShell Dismount-VHD:

Dismount-vhd -path <Path del file vhd/vhdx>

Come riportato nella sezione TechNet del cmdlet Optimize-VHD il file vhd/vhdx non deve essere montato o montato in readonly:

“This operation reclaims unused blocks as well as rearranges the blocks to be more efficiently packed, which reduces the size of a virtual hard disk file.

To use Optimize-VHD, the virtual hard disk must not be attached or must be attached in read-only mode.

The compact operation can succeed without reducing the file size, if no optimization is possible.”

Per utilizzare l’opzione Full di compattazione è però necessario che il  file vhd/vhdx sia montato in modalità readonly:

“Full scans for zero blocks and reclaims unused blocks. (Allowable only if the virtual hard disk is mounted read-only.)”

Concludendo per compattare un file vhd/vhdx è necessario che questo sia montato in modalità read only.

Per ulteriori informazioni si veda anche il post Compacting a Dynamically Expanding virtual hard disk in Windows Server 2012 e in particolare la nota relativa a dischi virtuali non formattati in NTFS:

“It is still recommended that you defrag the drive in advance. Also be aware, if the virtual hard disk is not NTFS formatted, you must prepare the virtual hard disk for compacting by using a non-Microsoft disk utility program to replace the blank space with zeroes. Lastly, the vhd cannot be in use.”

Per preparare immagini per computer con Windows 10 tramite sysprep occorre tenere presente di alcune accortezze per non avere problemi durante il restore dell’immagine.

Il comando per creare l’immagine di un computer è il seguente 8per informazioni sulle opzioni a riga di comando siveda Sysprep Command-Line Options):

%WINDIR%\system32\sysprep\sysprep.exe /oobe /generalize /shutdown

In questi giorni ho avuto modo di preparare alcune immagini per computer con Windows 10 e di seguito l’elenco dei passaggi da seguire per non avere problemi durante il restore dell’immagine.

Passo 1: Installare il sistema operativo senza connettere a Internet il computer per evitare aggiornamenti delle app

Passo 2: Quando richiesto impostare una password di amministratore con l’adeguata complessità, ad esempio almeno 8 caratteri con lettere minuscole e maiuscole, numeri e caratteri non alfabetici (a riguardo si vedano Passwords must meet complexity requirements e Password Policy) come indicato in Sysprep (System Preparation) Overview:

“If you do not assign a strong password to a user account before you run Sysprep or OOBE, you may not be able to log on to the PC. We recommend that you always use strong passwords for your user accounts.”

Passo 3: Mantenere il computer disconnesso dalla rete durante tutta la preparazione del sistema per evitare aggiornamenti delle app.

A riguardo si veda il post Windows 10 Sysprep fails after removing or updating Windows built-in Windows Store apps dove si consiglia di non avere accesso ad internet durante la preparazione del computer, se questo non è possibile a livello infrastrutturale in quanto il sistema deve essere connesso alla rete per la preparazione e questo comporta anche l’accesso ad Internet viene suggerito di implementare un blocco a livello di Windows Firewall tramite il comando:

cmd.exe /c netsh advfirewall firewall add rule name=”Block Internet” proto=TCP dir=out localport=any action=block en=yes profile=any remoteport=80,443

Come riportato in Windows 10 Sysprep fails after removing or updating Windows built-in Windows Store apps la problematica era già presente anche in Windows 8 come indicato nella KB 2769827 Sysprep fails after you remove or update Windows Store apps that include built-in Windows images:

“The issue at hand is actually an issue from Windows 8 https://support.microsoft.com/en-us/kb/2769827 where if you remove the built-in apps during a build and capture sysprep will fail. I had imagined this was resolved by now but the fix is still in the works.  The workaround is pretty simple we just need to kill access to the internet while we are building our image.  There are many ways to achieve this depending on what you have at your disposal but below is a quick and easy netsh command to block internet access which will resolve our problems and allow sysprep to complete successfully.  In the meantime ensure to keep your reference image patched with the latest CU’s for Windows 10 and this issue will hopefully be resolved and we can safely remove this step in the future.”

Nel caso si intenda creare immagini per la versione Enterprise di Windows 10 e non si sia interessati alle app è possibile utilizzare la versione LTSB a riguardo si veda il mio precedente post Windows 10 Enterprise LTSB.

Passo 4: Se possibile evitare di eseguire il join a dominio del sistema (in ogni caso Sysprep rimuoverebbe il computer dal dominio come indicato in What is Sysprep?:

“The Sysprep tool runs only if the PC is a member of a workgroup, not a domain. If the PC is joined to a domain, Sysprep removes the PC from the domain.”

E in Sysprep (System Preparation) Overview:

“If a PC is joined to a domain, and the Group Policy of that domain assigns a strong account password policy to the PC, all user accounts will require strong passwords. Running Sysprep or OOBE does not remove the strong password policy.”

Nel caso sia stato necessario eseguire il join a dominio per preparare il sistema prima di eseguire il sysprep eseguire le seguenti operazioni:

1. Rimovere il computer dal dominio
2. Rimovere l’applicazione dei criteri di gruppo di dominio tramite il comando:
   gpupdate /force /boot
3. Riavviare il sistema
4. Eseguire il sysprep

Conclusioni

Sysprep è sicuramente uno strumento utile per automatizzare il deploy, ma occorre gestirlo correttamnete analizzando gli scenari supportati, a riguardo si veda anche la sezione Limitations e Unsupported Scenarios in Sysprep (System Preparation) Overview e in particolare si tenga presente delle seguenti:

– In some cases, customized applications that you install before you recapture the Windows image may require a consistent drive letter. Some applications store paths that include the system’s drive letter. Uninstallation, servicing, and repair scenarios may not function correctly if the system’s drive letter does not match the drive letter that the application specifies.

– The Plug and Play devices on the reference and destination PCs do not have to be from the same manufacturer. These devices include modems, sound cards, network adapters, and video cards. However, the installation must include the drivers for these devices.

– Moving or copying a Windows image to a different PC without generalizing the PC is not supported.

– Using the Sysprep tool on upgrade installation types, or to reconfigure an existing installation of Windows that has already been deployed is not supported. Sysprep must be used only to configure new installations of Windows. You can run Sysprep an unlimited number of times to build and configure your installation of Windows.

Per ulteriori informazioni si veda anche la KB828287 Unsupported Sysprep scenarios.

Per una guida step by step per creazione di un’immagine di Windows 10 tramite Sysprep e Deployment Toolkit (MDT) 2013 Update 1 si veda Create a Windows 10 reference image.

Talvolta può capitare che risulti impossibile eliminare una cartella per vari motivi come ad esempio nomi di directory o file troppo lunghi o problematiche legati a permessi su file o cartelle.

Per risolvere è possibile ridurre i nomi di file o cartelle o controllare di avere i permessi necessari per l’eliminazione eventualmente attribuendosi l’ownership della cartella e di tutte le sottocartelle o file (a riguardo si veda Take ownership of files or other objects).

Può capitare però che il problema dell’impossibilità di eliminare un file sia dovuto all’impossibilità di leggere le informazioni di sicurezza di un file o di una cartella, in questo caso accedendo al tab Security delle proprietà del file o della cartella compare l’errore “The requested security information is either unavailable or cannot be displayed”.

In questo caso è possibile procedere con l’eliminazione utilizzando i comandi DOS eliminando la cartella in errore o la cartella che contiene in file in errore tramite il comando Rmdir specificando l’opzione /S

Di seguito il procedimento che è possibile seguire:

1. Aprire un prompt dei comandi con privilegi amministrativi
2. Spostarsi nella directory padre del file o della sottodirectory impossibile da eliminare
3. Eliminare la directory tramite il comando rmdir DirectoryName /s
4. In caso di problemi specificare il nome della directory specificando lo shortname 8.3 ricavabile tramite il comando dir /x

Come nota aggiuntiva si tenga presente che la generazione dei nomi di file 8.3 o shortname dovrebbe essere disabilitata per evitare decadimenti di performance su file server  tranne nel caso si utilizzino applicazioni che non sono in grado di gestire file e cartelle con nomi lunghi, a riguardo si veda la KB121007 How to disable 8.3 file name creation on NTFS partitions:

“The use of 8.3 file names and directories for all long file names and directories on NTFS partitions may decrease directory enumeration performance. An 8.3-compliant file name refers to MS-DOS file-naming conventions. These conventions restrict file names to eight characters and optional extensions to three characters.

Note: Although disabling 8.3 file name creation increases file performance under Windows, some applications (16-bit, 32-bit, or 64-bit) may not be able to find files and directories that have long file names.”

Talvolta può essere necessario spostare i file di configurazione delle VM su di un path diverso da quello scelto durante la creazione.

Per eseguire tale operazioni è possibile ad esempio eseguire l’esportazione e l’importazione della VM, ma in questo caso occorre prevedere spazio per i VHD ovviamente tempo per esportare e importare.

Un’altra alternativa è quella descritta in questo post Solved: How to move a Hyper-V virtual machine without Exporting it first che prevede però l’arresto del servizio Hyper-V management e l’intervento manuale sulle impostazioni di sicurezza dei file di conficurazione.

Una terza opzione è quella di sfruttare la procedura di importazione procedendo come segue, ipotizzando di volere spostare i file di configurazione da V:\Hyper-V\Virtual Machines a S:\Hyper-V\Virtual Machines mentre i file dei dischi virtuali sono :

Passo 1: Arrestare la VM

Passo 2: Copiare il file di configurazione della VM in una cartella di appoggio, il file di configurazione della VM ha nome nome pari all’ID della VM con estensione xml

Per ottenere la corrispondenza Nome – ID delle VM è possibile usare il seguente comando PowerShell:

Get-VM | Select Name, ID

Quindi nel nostro esempio si copierà il file 0E3BB6ED-01D8-46CF-9E9A-1D02AE759124.xml da V:\Hyper-V\Virtual Machines a S:\Export\VMTest.

Passo 3: Eliminare  la VM, questo comporterà l’eliminazione del file di configurazione, ma non dei file  VHD/VHDX.

Passo 4: Avviare la procedura di importazione della VM puntando alla cartella in cui è stato copiato il file di configurazione che nel nostro esempio è S:\Export\VMTest.

Passo 5: Selezionare la VM da importare che nel nostro esempio è VMTest

Passo 6: Selezionare Restore come tipologia di importazione per conservare l’ID univoco della VM.

Passo 7: Scegliere il path per il file di configurazione il Checkpoint e Smart Paging ovvero il path della cartella in cui desideriamo spostare il file di configurazione, nostro esempio il path sarà S:\Export\VMTest.

Passo 8: Selezionare il path dove sono memorizzati i VHD/VHDX della VM, nel nostro esempio S:\Hyper-V\Virtual Hard Disks.

Passo 9: Selezionare il path dove saranno memorizzati i VHD/VHDX della VM, nel nostro esempio sempre S:\Hyper-V\Virtual Hard Disks in quanto i file dei virtual disk sono già in posizione corretta, ma se si desidera è possibile eseguire durante l’import anche il move dei VHD/VDHX se necessario .

Passo 10: Verificare la correttezza delle impostazioni inserite e avviare l’importazione

Il KMS (Key Management Service) consente di gestire l’attivazione di prodotti e sistemi operativi Microsoft acquistati con dei contratti multi licenza. Il servizio può risiedere su un computer con OS client o Server quindi per la naturale evoluzione del sistema può rendersi necessario dover spostare il servizio KMS su sistemi con OS più aggiornati e rimuovere quindi il servizio su sistemi con OS in dismissione.

Di seguito la procedura per la rimozione del KMS da un sistema con Windows Server 2008 R2 (o Windows 7).

Passo 1: Rimuovere la KMS product key tramite il comando:

• slmgr.vbs /upk

Passo 2: Installare la default KMS client key per la versione del sistema operativo sul sistema tramite il comando:

• slmgr.vbs /IPK ProductKey

L’elenco delle default KMS client key è disponibile al seguente Appendix A: KMS Client Setup Keys.

Passo 3:  Eliminare il record DNS _VLMCS di tipo SRV per KMS service in dominio.ext._tcp relativo al server KM da rimuovere

Passo 4: Se si è già installato un server KMS sostitutivo controllare che il server DNS lo pubblichi correttamente tramite una query per il il record _VLMCS  dopo aver cancellato la cache del DNS tramite i comandi:

• ipconfig /flushdns
• nslookup -type=srv _vlmcs._tcp.dominio.ext

Passo 5: Disabilitare la registrazione DNS tramite il comando:

• slmgr.vbs /cdns

Passo 6: Riavvio del servizio Software Protection tramite il comando:

• net stop sppsvc && net start sppsvc

Passo 7: Testare la funzionalità del KMS sostitutivo provando ad attivare il sistema tramite il comando:

• slmgr.vbs /ato

Il KMS (Key Management Service) è uno dei tre metodi tramite cui è possibile gestire l’attivazione di prodotti e sistemi operativi Microsoft acquistati con dei contratti multi licenza, gli altri due metodi sono la gestione manuale tramite MAK (Codice ad attivazione multipla) e l’attivazione basata su Active Directory (introdotta con WS2012/W8 e che richiede l’aggiornamento dello schema della foresta Active Directory a Windows Server 2012 o successivi).

Di seguito alcune indicazioni tratte dalla mia esperienza e da indicazioni su documenti Microsoft .

Architettura per server KMS

Come indicato nel seguente Pianificare l’attivazione dei contratti multilicenza nella rete aziendale principale è in genere consigliata una soluzione centralizzata basata sul Servizio di gestione delle chiavi (KMS) in quanto rispetto all’attivazione basata su Active Directory consente di attivare i vecchi computer client e i computer non appartenenti al dominio, l’attivazione basata su Active Directory è praticabile se tutti i client dell’organizzazione eseguono Windows 10, Windows 8.1 o Windows 8

Nella rete principale è in genere consigliata una soluzione centralizzata basata sul Servizio di gestione delle chiavi (KMS). Puoi anche usare l’attivazione basata su Active Directory, ma in molte organizzazioni, il Servizio di gestione delle chiavi è comunque necessario per attivare i vecchi computer client e i computer non appartenenti al dominio. Alcuni amministratori preferiscono eseguire entrambe le soluzioni per ottenere la massima flessibilità, mentre altri preferiscono scegliere solo una soluzione basata sul Servizio di gestione delle chiavi per semplicità. L’attivazione basata su Active Directory come soluzione unica è praticabile se è necessario attivare solo computer a dominio con sistemi operativi Windows 8 / Windows server 2012 e successi e/o Office 2013 e successivi.

Di seguito uno schema tipico dell’architettura KMS, come indicato il servizio KMS può ad esempio essere installato su un Domain Controller.

Se possibile potrebbe essere conveniente dedicare una macchina Virtuale al servizio col minimo di requisiti hardware in modo da non aver problemi con eventuali aggiornamenti del KMS la cui installazione implica il riavvio del sistema. In questo modo sarà possibile anche installare il tool VAMT (Volume Activation Management Tool) per una gestione più semplice basata su interfaccia grafica dei prodotti Microsoft con attivazione a volume che ha come requisito SQL Server 2012 anche in versione Express (a riguardo si veda Install VAMT).

Impostazioni del servizio KMS

Per quanto riguarda le caratteristiche di KMS si ricordi che per default utilizza le seguenti impostazioni:

• Gestisce le richieste di attivazioni rimando in ascolto sulla porta TCP 1688
• Per default i client tentano di attivarsi ogni 120 secondi
• Per default i client rinnovano l’attivazione ogni 10080 minuti (7 giorni)

Prima che il servizio KMS a rilasciare le attivazione è necessario che venga superata una soglia di richieste che varia in base al prodotto da attivare.

Per quanto riguarda Windows 10 si veda Activate clients running Windows 10:

“You can activate physical computers and virtual machines by contacting a KMS host. To qualify for KMS activation, there must be a minimum number of qualifying computers (called the activation threshold). KMS clients will be activated only after this threshold has been met. Each KMS host counts the number of computers that have requested activation until the threshold is met.”

“A KMS host responds to each valid activation request from a KMS client with the count of how many computers have already contacted the KMS host for activation. Client computers that receive a count below the activation threshold are not activated. For example, if the first two computers that contact the KMS host are running Windows 10, the first receives an activation count of 1, and the second receives an activation count of 2. If the next computer is a virtual machine on a computer running Windows 10, it receives an activation count of 3, and so on. None of these computers will be activated, because computers running Windows 10, like other client operating system versions, must receive an activation count of 25 or more.”

Per Windows 8/8.1 e Windows Server 2012/R2 si veda Volume Activation Overview:

“KMS maintains an activation threshold, which requires that the organization activate at least five computers (physical or virtual machines) running a server operating system with Windows Server 2012 or later and at least 25 client computers running Windows 8 or later. The computers running Windows Server 2012 must connect within a 30-day period to active KMS client computers.”

Per le soglie di sistemi operativi precedenti si veda Understanding KMS:

“KMS can activate both physical computers and virtual machines. To qualify for KMS activation, a network must meet the activation threshold: KMS hosts activate client computers only after meeting this threshold. To ensure that the activation threshold is met, a KMS host counts the number of computers that are requesting activation on the network. For computers running Windows Server 2008 or Windows Server 2008 R2, the activation threshold is five. For computers running Windows Vista or Windows 7, the activation threshold is 25. The thresholds include client computers and servers that are running on physical computers or virtual machines.”

Per quanto riguarda Office 2010/2013 la soglia di attivazione è di 5 computer come riportato nei seguenti:

• Volume activation quick start guide for Office 2010
• Plan volume activation of Office 2013

A riguardo si veda Configuring KMS Hosts

Come indicato al seguente Step 1: Review and Select Activation Methods le chiavi di attivazione a volume per i sistemi operativi consentono di attivare non solo la versione a cui si riferiscono ma  anche le precedenti. Quindi ad esempio la Volume license per “Windows Server 2012 R2 for Windows 10” consentirà l’attivazione di:

• Windows 10 Professional
• Windows 10 Enterprise
• Windows Server 2012 R2 (all editions)
• Windows 8.1 Professional
• Windows 8.1 Enterprise
• Windows Server 2012 (all editions)
• Windows 8 Professional
• Windows 8 Enterprise
• Windows 2008 R2 (all editions)
• Windows 7 Professional
• Windows 7 Enterprise
• Windows 2008 (all editions)
• Windows Vista Business
• Windows Vista Enterprise

Per quanto riguarda l’attivazione dei prodotti Office è invece necessario attivare sul server KMS le chiavi di attivazione a volume per ciascuna versione utilizzata (a riguardo si veda la KB2852521 How to setup and install an Office 2010 and 2013 KMS Host).

Configurazione del servizio KMS in Windows Server 2012 R2

Per l’installazione del KMS in Windows Server 2012 R2 si veda Activate using Key Management Service, per quanto riguarda la configurazione in base alla ma esperienza personale è necessario:

• Specificare la porta di ascolto TCP anche se si intende utilizzare quella di default (16880) per evitare l’errore “STATUS_SUCCESS” al Commit.
• Per coprire tutti gli scenari di attivazione da parte di computer a dominio o in workgroup abilitare le eccezioni del firewall per Privato, Domino e Pubblico.
• Aggiungere il dominio DNS del dominio Active Directory alle zone DNS personalizzate in caso contrario altrimenti il record DNS SRV del server KMS non  viene aggiunto.

Gestione del servizio KMS

Di seguito alcuni comando utili per verificare il corretto funzionamento del servizio KMS

Verifica esistenza record DNS per server KMS:

nslookup -type=srv _vlmcs._tcp.domain.ext

Informazioni sul servizio KMS e dei prodotti registrati su file di testo:

cscript %windir%\System32\slmgr.vbs /dli all > KMS-Info.txt

Elenco client attivati tramite PowerShell:

$(foreach ($entry in (Get-EventLog -Logname “Key Management Service”)) {$entry.ReplacementStrings[3]}) | sort-object –Unique

Per monitorare l’attività del KMS è possibile utilizzare il visualizzatore eventi:

https://technet.microsoft.com/it-it/library/mt297923(v=vs.85).aspx

https://technet.microsoft.com/en-us/library/ff793434.aspx

Vi sono molti tool per eseguire misure di performance della velocità dei dischi uno dei quali è IOmeter un tool Open Source che è anche utilizzato dal team del supporto tecnico DELL quando deve eseguire questo tipo di misure.

IOMeter è composto da due programmi Iometer che è l’interfaccia grafica e Dynamo che è il workload generator a riga di comando. Il tool non necessita di installazione  e una volta scaricato dalla pagina http://www.iometer.org/doc/downloads.html per l’architettura e il sistema operativo del computer da analizzare (al momento è disponile la versione 1.1.0).

DELL mette a disposizione un file di test per eseguire misure sui server PowerEdge disponibile al seguente How to test performance on PowerEdge servers with Iometer dove è anche possibile trovare indicazioni su come utilizzare IOmeter.

Di seguito gli step da seguire per utilizzare IOmeter tramite il template messo a dispozione da DELL che permette di simulare i seguenti workload:

• Email Server – R60 W40- RND- 4K
• Database Server – R70 W30- RND- 8K
• Web Server – R95 W5- RND- Var
• Online Transaction Processing (OLTP) Server – R80 W20- RND- Var
• Archical File Server – R90 W10- SEQ- Var
• User Store File Server – R80 W20- SEQ- Var
• Streaming Media Server – R98 W2- SEQ- Var
• Std Read- 2M
• Burst Read- 2M
• Std Write- 2M
• Burst Write- 2M

Passo 1: avviare IOmeter.exe

 Passo 2: Caricare il file di configurazione di IOmeter SIM-Real-World-Workload-2.1.0.icf (nel caso si voglia utilizzare la versione precedente di IOmeter 2006.07.27 utilizzare il file di configurazione Sim-Real-World-Workload-1.2.0.icf)

Passo 3: Selezionare il volume su cui eseguire il test

Passo 4: Se necessario è possibile rimuovere i test che sono d’interesse, ad esempio nel caso si sia interessati solo a rilevare solo le massime performance in lettura e scrittura e quindi occorra solo eseguire i test:

• Std Read- 2M
• Burst Read- 2M
• Std Write- 2M
• Burst Write- 2M

Passo 5: Volendo è possibile impostare la modalità di visualizzazione dei risultati mentre i test vengono eseguiti

Passo 6: Avviare IOmeter e selezionare la directory in cui creare il file di output in formato csv

Per analizzare il file csv generato da IOmeter è possibile utilizzare il seguente tool online http://vmktree.org/iometer/ che permette di ottenere i dati in forma tabellare (in alternativa è possibile utilizzare Excel importando i dati del csv).

Per eseguire misure scongiurando eventuali problematiche a carico di applicazioni e/o servizi in esecuzione sul sistema è anche possibile creare tramite AOMEI PE Builder eseguito in una VM dedicata con la versione di OS con cui si intende generare l’immagine aggiungendo il driver del controller dischi del computer da analizzare e una cartella con i file di IOmeter.

Per ulteriori informazioni su IOmeter si veda documentazione disponibile al seguente link http://www.iometer.org/doc/documents.html.

Una delle novità di Hyper-V in W10 e WS2016 è che gli Hyper-V integration components sono disponibili tramite Windows Update come riportato in What’s New for Hyper-V on Windows 10 e nel post Hyper-V integration components are available through Windows Update e saranno disponibili per i seguenti sistemi operativi:

• Windows Server 2012
• Windows Server 2008 R2
• Windows 8
• Windows 7

A quanto pare sebbene Windows Vista SP2 sia tra gli OS Supportati al momento è escluso dalla disponibilità degli Hyper-V integration components (a riguardo si veda Supported Windows guest operating systems for Windows Server Technical Preview e Supported Guest Operating Systems for Client Hyper-V in Windows 10).

La prima release degli Integration Components tramite Windows Update è stata la KB3004908 Hyper-V integration components for Windows virtual machines that are running on Windows Technical Preview hosts, per maggiori dettagli si vedano anche i post:

• Updating Integration Components over Windows Update
• Integration components: How we determine Windows Update applicability

Volendo è anche possibile eseguire il download degli Hyper-V integration components tramite la KB3071740 Hyper-V integration components update for Windows virtual machines that are running on a Windows 10-based host, a riguardo si vedano anche i seguenti:

• Managing Hyper-V Integration Services
• Update integration components inside the virtual machine without using Windows Update

Se fosse necessario testare in Hyper-V su Windows 10/Windows Server 2012 sistemi operativi come Windows XP o Windows Server 2003 (ad esempio per lab di migrazione) e non si intende rinunciare alle funzionalità offerte dagli Hyper-V integration components (come ad esempio la dynamic memory) è possibile utilizzare ad esempio la vmguest.iso in %windir%\System32 copiandola da un Windows Server 2012 R2 o da un Windows 8.1. Ovviamente questo è un workaround e non è supportato per VM destinate ad ambienti di produzione.

Con l’introduzione di Windows Server 2008 R2 è stato introdotto il Active Directory Module for Windows PowerShell che è poi stato arricchito di nuovi cmdlets per gestire un numero sempre maggiore di funzionalità di Active Directory e servizi ad essa correlati, a riguardo si vedano i cmdlets e i moduli Powershell aggiunti nelle varie versioni del sistema operativo:

• Windows PowerShell modules introdotti in Windows Server 2012 and Windows 8
• Windows PowerShell modules introdotti in Windows Server 2012 R2 and Windows 8.1
• Windows PowerShell modules introdotti in Windows Server 2016 Technical Preview and Windows 10

La gestione del Global Catalog, ad esempio, è una delle funzionalità che è ormai matura per essere gestita completamente in Powershell in modo anche più produttivo.

Di seguito i comandi che è possibile utilizzare per la gestione e l’analisi della configurazione del ruolo Global Catalog.

Ricerca Global Catalog della foresta

Per eseguire tale query è possibile utilizzare il seguente comando disponibile a partire da Windows Server 2008 R2 come indicato in Finding the Global Catalog Servers in a Forest:

Get-ADForest rootdomain.ext | FL GlobalCatalogs

Volendo è anche possibile specificare un dominio figlio o non specificare alcun dominio nel caso si intenda eseguire la ricerca nel dominio corrente, per maggiori informazioni si veda il cmdlet Get-ADForest. 

In alternativa è possibile anche utilizzare il seguente comando che estrai gli oggetti Domain Controller mostrando per ciascuno le proprietà Name e IsGlobalCatalog:

Get-ADDomainController -Filter * | Select Name, IsGlobalCatalog

Ricerca Global Catalog in un Site

Per eseguire tale query è possibile utilizzare il seguente comando disponibile a partire da Windows Server 2008 R2 come indicato in Finding the Domain Controllers or Global Catalog Servers in a Site:

Get-ADDomainController -Filter {Site -eq ‘SiteName’} | FT Name,IsGlobalCatalog

Verifica record DNS relative al Global Catalog

I Global Catalog sono identificati oltre che in AD anche nel DNS tramite record SRV _gc che possono essere interrogati tramite Powershell mediante il seguente comando:

Get-DnsServerResourceRecord -ZoneName domain.ext -RRType “SRV” -Name “_gc._tcp”

Aggiunta e rimozione del ruolo Global Catalog su un Domain Controller

Tramite Powershell è anche possibile aggiungere o rimuovere il ruolo di Global Catalog modificando le opzioni dell’oggetto NTDSSettings del domain controller.

Di seguito il comando per abilitare il ruolo di Global Catalog:

Set-ADObject -Identity (Get-ADDomainController -Identity “DCName”).NTDSSettingsObjectDN -Replace @{options=’1′}

Mentre di seguito il comando per rimuovere il ruolo di Global Catalog:

Set-ADObject -Identity (Get-ADDomainController -Identity “DCName”).NTDSSettingsObjectDN -Replace @{options=’0′}

Per maggiori informazioni si veda Enabling and Disabling the Global Catalog.

Verifica se la promozione a Global Catalog è completa

Dopo aver avviato la promozione di un domain cotroller al ruolo di Global Catalog è anche possibile verificare se tale operazione si è conclusa tramite il comando:

Get-ADRootDSE -Server DCName | FT GlobalCatalogReady

Per maggiori informazioni si veda Determining Whether Global Catalog Promotion Is Complete.

In Windows10 per impostazione predefinita Windows Photo Viewer viene utilizzato solo per aprire file grafici .tif e .tiff, mentre per i file negli altri formati grafici (jpg, png, bmp, gif, ico, etc.) viene utilizzata l’app Photos.

E’ possibile cambiare questo comportamento sono tramite impostazioni di registro e non  tramite la funzionalità “Default Programs” del Pannello di Controllo come descritto in Using Windows Photo Viewer as default image viewer on Windows 10.

Nel caso in cui si sia implemento nell’infrastruttura Windows 10 LTSB  l’app Photos non è presente e i file con formati grafici diversi da TIFF vengono aperti da Paint.

Un modo semplice per gestire l’apertura dei file di determinati formati grafici in modo centralizzato tramite Windows Photo Viewer è quello di utilizzare le Group Policy preferences per creare un registry item che imposti il sistema per gestire un file in un formato grafico diverso da TIFF in modo analogo ad un file TIFF. Ad esempio per aprire un file .jpg tramite Windows Photo Viewer in modo analogo a quello che succederebbe aprendo un file .tif o .tiff è possibile aggiungere nella chiave di registro HKLM\SOFTWARE\Microsoft\Windows Photo Viewer\Capabilities\FileAssociations il valore .jpg di tipo REG_SZ impostato a PhotoViewer.FileAssoc.Tiff.

Quindi è possibile creare una GPO Preferences per creare le necessarie chiavi di registro al fine di gestire tramite Windows Photo Viewer i file dei formati grafici necessari:

In questo modo quando si tenta di aprire i file nei formati grafici gestiti si avrà la possibilità di utilizzare Windows Photo Viewer e se lo si desidera di impostarlo come predefinito.

Volendo è ovviamente possibile intervenire sul registro in maniera più pensante per configurare più minuziosamente l’utilizzo di Windows Photo Viewer per file in formati grafico diverso da TIFF, a riguardo si veda ad esempio il seguente thread [Windows 10] Scomparsa Visualizzatore immagini integrato.

Un altro approccio possibile può essere quello di impostare l’utilizzo Windows Photo Viewer quando si visualizzano immagini contenuti in  specifiche cartelle tramite il comando:

rundll32 “%ProgramFiles%\Windows Photo Viewer\PhotoViewer.dll”, ImageView_Fullscreen C:\MyPhoto

Ultimamente mi è successo su una serie di computer (Lenovo M83 Desktop ThinkCentre) con Windows 10 che si verificassero dei blocchi di sistema per alcuni secondi con warning sull’accesso in lettura e scrittura di file con ritardi di vari secondi e i seguenti warning di sistema numerose volte:

Nome registro: System
Origine:       disk
ID evento:     153
Categoria attività:Nessuna
Livello:       Avviso
Parole chiave: Classico
Descrizione:
Nuovo tentativo per l’operazione di I/O all’indirizzo di blocco logico 0x6d4430 per il disco (nome PDO: \Device\0000002a) 0.

Per ulteriori informazioni sul warning si veda il post Interpreting Event 153 Errors.

Nome registro: System
Origine:       storahci
ID evento:     129
Categoria attività:Nessuna
Livello:       Avviso
Parole chiave: Classico
Descrizione:
Emessa reimpostazione a dispositivo \Device\RaidPort0.

Understanding Storage Timeouts and Event 129 Errors.

Premesso che questo tipo di problematica accade anche su sistemi operativi precedenti a Windows 10 e su vari modelli di computer di vendor diversi, il problema pare legato ad una non corretta gestione delle impostazioni di risparmio energetico come riportato su questo post Event ID 129 – storachi – Reset to device, DeviceRaidPort0, was issued.

Nel mio caso l’indicazione  proposta nel post di disabilitare l’impostazione di risparmio energetico relativa al PCI Express – Link State Power Management non ha avuto alcun effetto migliorativo.

Impostando però le opzioni di risparmio energetico su “Prestazioni Elevate” i warning scomparivano e anche i blocchi di sistema saltuari.

Di conseguenza sicuramente il problema è correlato ad una gestione non corretta delle opzioni di risparmio energetico ed infatti una soluzione alternativa per risolvere il problema è quella di installare il driver Intel Rapid Storage per Windows 10 più recente (al momento l’ultima versione è la 14.8.0.1042) disponibile al seguente  Download per Tecnologia Intel® Rapid Storage.

Questa seconda soluzione però non ha funzionato su computer Dell OptiPlex 3020 su cui ho risolto impostando le opzioni di risparmio energetico su “Prestazioni Elevate”

Un’altra possibilità suggerita nell’articolo Disable Intel Rapid Start Technology del supporto Acer (che però non ho testato) potrebbe essere quella di disabilitare se possibile l’Intel Rapid Start Technology (iRST) energy-saving sleep mode nel BIOS in caso di incompatibilità.

Su di un Domain Controller WS2008R2 mi è successo di non riuscire ad eseguire il comando GPRESULT in quanto restituiva sempre l’errore “ERROR: Not found.”. Anche provando ad eseguire rsop.msc veniva restituito un errore analogo e andando a vedere gli evento di sistema veniva registrato il seguente:

Nome registro: System
Origine:       Microsoft-Windows-GroupPolicy
ID evento:     1089
Categoria attività:Nessuna
Livello:       Avviso
Parole chiave:
Utente:        SYSTEM
Descrizione:
Impossibile registrare le informazioni di Gruppo di criteri risultante, che descrivono l’ambito degli oggetti Criteri di gruppo applicati al computer o all’utente. È possibile che Gruppo di criteri risultante sia stato disattivato, che il servizio Strumentazione gestione Windows (WMI) sia stato disattivato o arrestato oppure che si siano verificati altri errori di WMI. Le impostazioni dei Criteri di gruppo sono state correttamente applicate al computer o all’utente, ma i rapporti generati dagli strumenti di gestione potrebbero non essere accurati.

Come riportato dall’evento 1089 l’errore è correlato ad un problema relativo a WMI e per risolverlo si può eseguire una rebuild del WMI tramite i seguenti comandi:

sc config winmgmt start= disabled
net stop winmgmt /y
Winmgmt /salvagerepository %windir%\System32\wbem
Winmgmt /resetrepository %windir%\System32\wbem
sc config winmgmt start= auto

Terminate la rebuild ho avviare il servizio winmgmt ed eseguire un aggiornamento delle Group Policy tramite i seguenti comandi:

net start winmgmt
gpupdate /force

Verificare poi che i comandi gpresult e rsop.msc funzionino correttamente e che sia stato registrato il seguente evento dopo l’esecuzione del comando gpresult:

Nome registro: System
Origine:       Microsoft-Windows-GroupPolicy
ID evento:     1502
Categoria attività:Nessuna
Livello:       Informazioni
Parole chiave:
Utente:        SYSTEM
Descrizione:
Elaborazione delle impostazioni dei criteri di gruppo completata. Sono state rilevate e applicate nuove impostazioni per … oggetti Criteri di gruppo.

Al termine della procedura, dal momento che il servizio WMI è utilizzato da altre funzionalità, riavviare il sistema.

Come descritto nel post Fix: Loading DNS zones takes a long time on a Windows Server 2008 R2-based DNS server a marzo 2016 è stata rilasciata la fix KB3145126 Loading DNS zones takes a long time on a Windows Server 2008 R2-based DNS server per risolvere i problemi di lentezza di caricamento delle zone DNS su server DNS e Domain Controller Windows Server 2008 R2 causati dopo l’installazione della security update MS15-127: Security update for Microsoft Windows DNS to address remote code execution: December 8, 2015 e dell’hotfix KB3022780 DNS server does not respond with IP address to a CNAME query for a delegated zone in Windows Server 2008 R2.

Prima d’installare la KB3145126 occorre però eseguire una verifica sulle zone DNS per essere sicuri che siano compliance con l’RFC 2181 in caso contrario dopo l’installazione della KB3145126 il servizio DNS non si avvierà registrando il seguente evento di errore:

Nome registro: Application
Origine:       Application Error
ID evento:     1000
Categoria attività:(100)
Livello:       Errore
Parole chiave: Classico
Utente:        N/D

Descrizione:
Nome dell’applicazione che ha generato l’errore: dns.exe, versione: 6.1.7601.23375, timestamp: 0x56e06454
Nome del modulo che ha generato l’errore: dns.exe, versione: 6.1.7601.23375, timestamp: 0x56e06454
Codice eccezione: 0xc0000005
Offset errore 0x000000000006138f
ID processo che ha generato l’errore: 0xcdc
Ora di avvio dell’applicazione che ha generato l’errore: 0x01d1cbadfcd1c43e
Percorso dell’applicazione che ha generato l’errore: C:\Windows\system32\dns.exe
Percorso del modulo che ha generato l’errore: C:\Windows\system32\dns.exe
ID segnalazione: 3b548b39-37a1-11e6-abb5-001d096aa2f2

Per consentire l’avvio del servizio DNS più e occorrerà disinstallare la KB3145126 ed apportare le modifiche necessarie nelle zone DNS come descritto nella KB3145126:

This DNS service crash may occur if DNS is configured to have a CNAME and an SOA record that both exist for the “@” record. The “@” record identifies the root of a DNS zone. This can frequently be identified in the DNS Manager as a record with the <same as parent folder> name. The SOA and NS records are allowed in this folder. RFC 2181 describes name uniqueness checks for CNAME records. According to RFC 2181, the CNAME may not exist in the <same as parent name> folder (“@”) of a zone.

You may have to uninstall the KB3145126 update first to make the DNS service stable.

In estrema sintesi occorre verificare che nelle zone DNS non vi siano record DNS CNAME che puntino al zona stessa identificabili col nome “(come per la cartella padre)” o “(same as parent name)”.

Una volta identificati tali record è possibile rimuoverli manualmente oppure, come indicato nella KB3145126, tramite il comando DNSCMD:

To delete the CNAME records that do not comply with RFC 2181 based on the output that’s returned from the PowerShell script, type the following command at command prompt, and then press Enter:

DNSCMD /recorddelete DNS zone name @ cname

Per aiutare gli amministratori nel deploy la KB3145126 rende disponibile anche uno script PowerShell per l’identificazione delle zone DNS con record CNAME in conflitto con record SOA, per problemi d’impaginazione dello script la prima riga va però suddivisa in due come segue:

In ogni caso il consiglio è quello di procedere all’aggiornamento prima su di un domain controller Windows Server 2008 R2 verificare che non vi siano problemi di avvio del servizio DNS e quindi procedere con l’aggiornamento con gli altri domain controller.

Dopo l’installazione della KB3159706 Update enables ESD decryption provision in WSUS in Windows Server 2012 and Windows Server 2012 R2 la console di WSUS in Windows 2012 R2 non si avvia più registrando il seguente evento diinformazioni nel registro Applicazioni relativo ad un errore nell’accesso al database SUSDB.

Nome registro: Application
Origine:       MSSQL$MICROSOFT##WID
ID evento:     18456
Categoria attività:Accesso
Livello:       Informazioni
Parole chiave: Classico,Controllo non riuscito
Utente:        SERVIZIO DI RETE
Descrizione:
Accesso non riuscito per l’utente ‘NT AUTHORITY\SERVIZIO DI RETE’. Motivo: impossibile aprire il database specificato ‘SUSDB’ in modo esplicito. [CLIENT: <named pipe>]

Come dibattuto in questo post WSUS console & service can’t start. “Reason: Failed to open the explicitly specified database ‘SUSDB'” il motivo è legato al fatto che l’installazione della KB3159706 è da fare con una certa accortezza in quanto oltre a verificare di avere i prerequisiti indicati sul server WS2012R2 che eroga il servizio di WSUS e sui client W8/W8.1:

“To apply this update in Windows Server 2012 R2, you must have April 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 (2919355) installed.”

Dopo l’installazione occorre però eseguire le seguenti configurazioni come descritto nella KB3159706 in caso contrario la console di WSUS non si avvierà:

1. Open an elevated Command Prompt window, and then run the following command (case sensitive, assume “C” as the system volume):

“C:\Program Files\Update Services\Tools\wsusutil.exe” postinstall /servicing

2. Select HTTP Activation under .NET Framework 4.5 Features in the Server Manager Add Roles and Features wizard.

3. Restart the WSUS service.

Nel caso sul server WSUS sia stato implementato SSL occorre eseguire altre configurazioni descritte nella KB3159706 Update enables ESD decryption provision in WSUS in Windows Server 2012 and Windows Server 2012 R2.

Come descritto nel post The long-term fix for KB3148812 issues la KB3159706 permette la corretta gestione dei client Windows 10 da parte di WSUS e in particolare consente la distribuzione dei Windows 10 feature updates come ad esempio il Windows 10 Anniversary Update:

“Windows 10 feature updates (denoted by the “Upgrades” classification in WSUS) are staged in encrypted packages to Windows Update several days prior to the actual go-live date.  This is to ensure that we can release to all regions simultaneously.  The Windows 10 client has been able to decrypt these packages since RTM; however, WSUS was not able to do this.  Until now, we have been manually decrypting these packages prior to releasing to the WSUS channel, the process of which is both time consuming and error prone.  KB3159706 introduces this functionality to WSUS for Windows Server 2012/R2, such that it can now natively decrypt this content.  Skipping this KB means not being able to distribute the Windows 10 Anniversary Update, or any subsequent feature update, via these platforms.  Note that Windows Server 2016 will have this functionality at RTM.”

Come indicato nel post nel caso fosse stato installata la KB3148812 è consigliabile disinstallarlo prima di procedere all’installazione:

Both these updates modify the same files as KB3159706; since the latter is newer, it will simply replace the binaries. You can remove KB3148812 (if you don’t recognize this KB, then no action is needed), but it is not necessary. In any case, your “For testing purposes only” watermark will disappear after you’ve removed the test package.  Our recommended order for this deployment is:

  1. Uninstall test package

  2. [Optional] uninstall KB3148812

  3. Install KB3159706

  4. Reboot your WSUS server

I computer Windows 10 joinati a dominio possono causare blocchi regolari degli account utente nel caso in cui Windows 10 non sia aggiornato con il Cumulative Update del 13 ottobre 2015 (KB3097617) o successivi.

Ho verificato questo comportamento in una Active Directory basata su Domain Controller WS2008 R2 con livello funzionale di Dominio Windows Server 2008 R2 con client Windows 10 Enterprise a 64 Bit, ma leggendo vari interventi su post e forum relativi a questo issue non pare correlato alla versione del sistema operativo dei Domain Controller o alla versione del livello funzionale di Dominio (per esempio accade anche con Domain Controller WS2012R2 e livello funzionale di Dominio Windows Server 2012).

L’issue si manifesta in due modi:

1. Quando i computer si blocca dopo in periodo di inattività se l’utente lo sblocca compare una richiesta di immissione delle credenziali che se ignorato comporta spesso il blocco dell’account.
2. Occasionalmente la richiesta di immissione delle credenziali non viene visualizzata e l’account viene bloccato e sul Domain Controller che ha eseguito il blocco viene registrata come motivazione il fallimento della Kerberos Pre-Authentication.

Il problema è correlato alla pre-autenticazione Kerberos infatti disabilitando sull’utente tale impostazione il problema non si verifica.

Va però precisato che la disabilitazione della pre-autenticazione Kerberos sull’utente può essere solo un workaround temporaneo per identificare la causa del problema perché espone rischi di sicurezza come descritto nel post How to find user accounts with Kerberos preauthentication disabled:

“During Kerberos authentication the Authentication Service (AS) request identifies the client to the KDC in plain text. If preauthentication is enabled, a time stamp will be encrypted using the user’s password hash as an encryption key. If the KDC reads a valid time when using the user’s password hash (stored in the Active Directory) to decrypt the time stamp, the KDC knows that request isn’t a replay of a previous request.”

“The preauthentication feature may be disabled for specific users in order to support some applications that don’t support the security feature. Access the user account from the Active Directory users and the computers will snap-in and select the account tab.”

E nel seguente Kerberos Components in Windows 2000 – Preauthentication:

“By default the KDC requires all accounts to use preauthentication. This makes offline password-guessing attacks very difficult. However, preauthentication can be disabled for individual accounts when this is necessary for compatibility with other implementations of the protocol.”

La soluzione corretta è invece assicurarsi, come ho detto all’inizio del post, di avere il sistema Windows 10 aggiornato almeno alla Cumulative Update del 13 ottobre 2015 (KB3097617) in cui come si può verificare dal file information for update 3097617 uno dei file aggiornati è appunto C:\Windows\System32\kerberos.dll.

Per maggiori informazioni si veda 4771(F): Kerberos pre-authentication failed.

Talvolta può essere necessario rilevare la lingua con cui è stato installato un sistema dal punto di vista sistemistico o sviluppativo. Di seguito alcuni metodi con cui è possibile ricavare tale informazione tramite WMI.

Metodo 1: Query WMI da console

E’ possibile utilizzare la seguente query a riga di comando:

wmic os get locale, oslanguage, codeset

Dove oslanguage identifica la lingua del sistema operativo, mentre locale è l’identificativo della lingua utilizzato dal sistema (ovvero lo standard international numeric abbreviation per una country/region) e il codeset rappresenta la tabella dei caratteri usata dal sistema operativo per tradurre le stringhe nelle diverse lingue.

Di seguito il risultato per un sistema Windows Server 2012 R2 installato in Italiano:

Mentre di seguito il risultato per un sistema Windows Server 2012 R2 installato in Inglese con formato ora e valuta in italiano e layout di tastiera in italiano:

Per l’interpretazione dei codici numeri restituiti è possibile fare riferimento ai seguenti:

•  Code Page Identifiers
• Locale IDs Assigned by Microsoft

Di seguito ad esempio i valori per un sistema installato in Italiano:

• CodeSet = 1252 – ANSI Latin 1; Western European (Windows)
• Locale = 0410 – Italian – Italy
• OSLanguage = 1040 – Italian – Italy

Di seguito ad esempio i valori per un sistema installato in Inglese con formato ora e valuta in italiano e layout di tastiera in italiano:

• CodeSet = 1252 – ANSI Latin 1; Western European (Windows)
• Locale = 0410 – Italian – Italy
• OSLanguage = 1033 – English – United States

Metodo 2: Query WMI in un’applicazione

E’ possibile ricavare le informazioni relative a CodeSet, Locale e OSLanguage tramite la classe WMI Win32_OperatingSystem eseguendo una query WMI nel codice come illustrato in WMI Queries.

Di seguito un esempio di codice WMI in VB.NET:

Dim query As New System.Management.WqlObjectQuery(“SELECT CodeSet, Locale, OSLanguage FROM Win32_OperatingSystem”)

Using searcher As New System.Management.ManagementObjectSearcher(query)
     Dim item = searcher.Get()(0)
     MsgBox(String.Format(“CodeSet={0} Locale={1} OSLanguage={2}”, item(“CodeSet”), item(“Locale”), item(“OSLanguage”)))
End Using

Metodo 3: Query WMI in PowerShell

E’ possibile sfruttare WMI anche in ProwerShell sempre ricorrendo alla classe WMI Win32_OperatingSystem tramite il seguente codice:

$os = Get-WmiObject Win32_OperatingSystem
$os | Select-Object –Property Locale, OSLanguage, CodeSet

A partire da PowerShell 3.0 sono stati introdotti anche il cmdlet Get-Culture che permette di ricavare informazioni sulla culture del sistema e Get-UICulture che permette di ricavare informazioni sulla culture dell’interfaccia grafica sistema.

Dopo una migrazione da Outlook 2013 ad Outlook 2016 potrebbe accadere che Outlook non riesca più ad accedere al profilo di posta creato per un account Exchange o a creare un nuovo profilo di posta per un account Exchange.

Il motivo può essere legato al fatto che il computer non riesce a trovare ad utilizzare la funzionalità di AutoDiscover per rilevare il server Exchange o che la versione di Exchange non sia supportata.

In Outlook 2016, come indicato in What’s new for administrators in Outlook 2016 for Windows, richiede l’utilizzo dell’AutoDiscover per connettersi al server Exchange e non può connettersi ad Exchange 2007:

“Outlook 2016 does not support connecting to Exchange Server 2007.”

“Outlook 2016 now requires AutoDiscover to be configured, or it will be unable to connect to Exchange Server. Outlook 2016 retrieves Exchange connectivity settings directly from AutoDiscover instead of the registry, making profiles more reliable, but that also makes AutoDiscover a required feature.”

“As a result, Outlook 2016 administrators must configure AutoDiscover.”

La rilevazione basata su AutoDiscover si basa su Active Directory per computer a dominio e su DNS per computer esterni come illustrato in Account Auto Configuration process (Autodiscover):

“When you install a Client Access server in Exchange 2013, a default virtual directory named Autodiscover is created under the default website in Internet Information Services (IIS). This virtual directory handles Autodiscover service requests from Outlook 2007, Outlook 2010, and Outlook 2013 clients and supported mobile phones under the following circumstances:

• When a user account is configured or updated
• When an Outlook client periodically checks for changes to the Exchange Web Services URLs
• When underlying network connection changes occur in your Exchange messaging environment

Additionally, a new Active Directory object named the service connection point (SCP) is created on the server where you install the Client Access server.

The SCP object contains the authoritative list of Autodiscover service URLs for the forest. You can use the Set-ClientAccessServer cmdlet to update the SCP object.”

“For more information about SCP objects, see Publishing with Service Connection Points.”

“For external access, or using DNS, the client locates the Autodiscover service on the Internet by using the primary SMTP domain address from the user’s email address.”

Per eseguite il test della funzionalità di AutoDiscover è possibile utilizzare il link https://testconnectivity.microsoft.com/ oppure tramite il menu esteso dell’icona di Oulook visualizzabile premendo il tasto CTRL e cliccando sull’icona.

Quindi nel caso in cui computer non a dominio debbano connettersi ad account Exchange occorrerà creare un record DNS SRV _autodiscover per il protocollo _tcp e porta 443 nella zona DNS relativa al loro dominio di posta elettronica che punti al server Exchange.

Per maggiori dettagli si veda Configure DNS for Remote Access:

“In your external DNS zone, remove any host (A) or canonical name (CNAME) records for the Autodiscover service.

Add a service (SRV) resource record for the Autodiscover service, using the following parameters:

• Service: _autodiscover
• Protocol: _tcp
• Port: 443
• Host: RemoteName (for example, remote.adventure-works.com)”

Per il test della corretta rilevazione del record SRV è possibile utilizzare il comando nslookup come descritto nel post How To Check Exchange Autodiscover SRV Record Using Nslookup:

nslookup -q=srv _autodiscover._tcp.domain.ext

Per ulteriori informazioni si veda anche l’articolo Exchange Account Set-up Missing in Outlook 2016 di Diane Poremsky – Microsoft Outlook Most Valuable Professional (MVP).

Scenario: Lumia 650 Dual SIM con una SIM Vodafone o Tim e una SIM 3 Italia.

Issue: In questo caso molto probabilmente si noterà che la SIM Tre funzionerà sempre in modalità roaming evidenziato dall’icona a forma di triangolo (a riguardo si veda Icons on your phone) se la connessione dati è impostata per essere servita dalla SIM Vodafone o Tim.

Il motivo è spiegato nella Guida di Lumia 650 nella sezione Il mio Lumia Dual SIM supporta LTE/4G/3G su entrambe le SIM? dove viene riportato quanto segue:

“Esistono diversi telefoni Lumia con doppia SIM che supportano LTE, 4G e 3G. È tuttavia possibile impostare solo una delle schede SIM alla volta per l’uso della connessione LTE, 4G o 3G. L’altra SIM è limitata a una connessione 2G/GSM. Se il tuo operatore di telefonia mobile non ha una rete 2G/GSM, la registrazione della scheda SIM non riuscirà e non potrai effettuare o ricevere chiamate, inviare o ricevere SMS oppure usare la rete dati con questa scheda SIM.

Per informazioni sulla compatibilità della scheda SIM con le reti 2G/GSM, contatta il tuo operatore di telefonia mobile.”

Quindi dal momento che 3 Itala non ha una rete 2G, ma si appoggia alla rete 2G di Tim se la connessione LTE, 4G o 3G è impostata per essere gestita dalla SIM Vodafone o Tim, la SIM 3 Italia dovrà necessariamente connettersi in roaming a Tim per funzionare in 2G.

Se invece si imposta la connessione LTE, 4G o 3G per essere gestita dalla SIM 3 Italia questa funzionerà senza attivare il roaming (può essere però necessario eseguire manualmente la ricerca delle reti selezionando la rete 3 Italia).

Le Group Policy Preference consentono di creare operazioni pianificate computer e utente. Per quanto riguarda la creazione di attività pianificate è possibile crearle mediante la procedura illustrata al seguente Configure a Scheduled Task Item in cui per quanto riguarda le Group Policy Preference Computer in contesto di sicurezza predefinito è SYSTEM:

“If the preference item is part of Computer Configuration , by default the task is run in the security context of the SYSTEM account.”

Mi è successo, però, un volta creata una Group Policy Preference Computer per la creazione di un’attività pianificata questa poi non venisse creata a causa nell’impostazione dell’account con cui eseguire l’attività che nel caso di Group Policy Preference Computer viene impostato a %LogonDomain\%LogonUser%.

Neppure provando a impostare manualmente l’account SYSTEM tramite la dialog di selezione Utente o Gruppo, che equivale a impostare l’account a BUILTIN\SYSTEM, l’attività pianificata venisse creata ed eseguita.

Per riuscire creare e a far funzionare correttamente un’attività pianificata tramite una  Group Policy Preference Computer ho dovuto impostare l’account a NT AUTHORITY\SYSTEM.

Per maggiori informazoni sulla creazioni di attività pianificate tramite Group Policy Preferences si veda Scheduled Tasks Extension.

Per impostazione predefinita il percorso download di Internet Explorer è impostato sul path %USERPROFILE%\Downloads.

Vi sono però casi in cui si desidera modificare questa impostazione per un determinato numero di utenti di dominio in questo caso mancando una specifica group policy è possibile ricorrere alle Group Policy Preferences impostando una apposita chiave di registro.

Il path predefinito download per Internet Explorer può essere modificato impostando il valore Default Download Directory di tipo REG_SZ nella chiave HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main.

Nel caso il valore Default Download Directory non esista verrà utilizzato il percorso predefinito di download di Internet Explorer è impostato sul path %USERPROFILE%\Downloads.