Se il computer non si avvia presentando un Blue Screen of Death (BSOD) con l’errore 0x0000007B INACCESSABLE_BOOT_DEVICE vi possono essere varie cause, ma il primo controllo da fare è quello di verificare che non siano intercorse modifiche sulla configurazione delle Storage.
Quello che può succedere infatti è che volontariamente o a causa di problemi su batteria tampone o altro siano state apportate modifiche alle configurazioni BIOS relative alla modalità SATA dell’unità di avvio relative all’utilizzo della specifica AHCI (Advanced Host Controller Interface) o alle funzionalità RAID. A riguardo si veda la KB 922976 Error message occurs after you change the SATA mode of the boot drive.
Modificando tali impostazioni infatti il driver dello storage con cui è stato installato il sistema risulta non adatto e di conseguenza l’unità di avvio risulta non accessibile come riportato nella KB 922976:
“During the Windows 7 or Windows Vista installation process, any unused storage drivers are disabled. This behavior speeds up the operating system’s startup process. When you change the boot drive to a driver that is disabled, you must enable the new driver before you change the hardware configuration. For example, assume that you install Windows Vista or Windows 7 on a computer that contains a controller that uses the Pciide.sys driver. Later, you change the SATA mode to AHCI. Therefore, the drive must now load the Msahci.sys driver. However, you must enable the Msahci.sys driver before you make this change. This issue affects only the boot drive. If the drive that you change is not the boot drive, you do not experience this issue.”
Spesso in conseguenza a questo errore il sistema si riavvia senza mostrare informazioni sull’BSOD, per visualizzare le informazioni è possibile premere F8 all’avvio e selezionare l’opzione Disabilita riavvio automatico in caso di errore di sistema.
Se non si è certi di come erano le impostazioni BIOS all’atto dell’istallazione del Sistema Operativo il consiglio è quello di provare a modificare le configurazioni relative a SATA ed AHCI e verificare se il sistema si avvia.
Un’altra causa di questo errore può essere la corruzione della configurazione di boot che può essere ripristinata tramite la console di recovery utilizzando i comandi:
bcdboot C:\windows
bootrec /fixboot
bootrec /fixmbr
bootrec /rebuildbcd
Per ricostruire completamente i boot records è possibile utilizzare i seguenti comandi:
Tramite ad esempio l’url https://servermailname.domain.ext/owa/mailboxname@domain.ext/?cmd=contents&module=tasks è possibile accedere direttamente alle attività di una specifica cassetta postale.
Ovviamente nella cassetta postale su cui si desidera condividere le attività bisognerà impostare le opportune autorizzazioni verso gli utenti che dovranno accedere.
In particolare per poter inserire e modificare attività occorrerà concedere il ruolo Supervisore sulla cartella Attività agli utenti interessati:
Per consentire l’eliminazione delle attività occorrerà concedere il ruolo di creazione elementi nella cartella Posta Eliminata agli utenti interessati:
Per poter per gestire anche le categorie sulle attività condivise agli utenti deve essere concesso l’accesso completo sulla casetta (al contrario di quello accade per i calendari condivisi dove le categorizzazione è gestita tramite una mail nascosta nella cartella del calendario e quindi gestendo la permissions sulla cartella calendario è possibile anche impostare le categorie, a riguardo si veda You cannot change a user’s categories when you work as a delegate in Outlook).
Per pubblicare un server SNMP tramite TMG 2010 occorre prima creare una nuova definizione di protocollo per accettare le chiamate sulla porta 161 in modalità Ricevi e Invia in quanto il Server SNMP deve poter rispondere alle chiamate, non sono invece necessarie connessioni secondarie.
Quindi creare una Regola di pubblicazione non Web utilizzando il protocollo definito precedentemente, per sicurezza esporre il server SNMP solo agli IP esterni necessari se possibile e non a tutti gli indirizzi esterni.
Ieri Martedi 10 Febbraio 2015 sono stai rilasciati una serie di aggiornamenti tra cui la KB 3001652 Update rollup for Visual Studio 2010 Tools for Office Runtime la cui installazione non viene terminata lasciando il computer bloccato nella videata di installazione col messaggio di non arrestare il sistema.
Se si prova poi ad arrestare forzamente il sistema al primo riavvio il problema si ripresenta in quanto l’installazione dell’update non viene completata.
Io ho verificato personalemente l’issue di sistemi con Windows 7, ma pare si verifichi anche su sistemi Windows 8.1 e Surface Pro 3.
“Microsoft has already confirmed for us that it pulled the update because of “some issues reported by users,” so the company needs more time to investigate, while in a post on the official KB3001652 page it notes that “there is a problem in the Microsoft products” that this update is aimed at.
The update rollup for Visual Studio 2010 Tools for Office Runtime is a cumulative pack of previous fixes, so it’s hard to determine what causes the installation problems, since all of the previously released patches actually deployed fine on both Windows 8.1 and Windows 7.”
“Right now, it’s not yet very clear if this is a widespread issue or not, but we’ve reached out to Microsoft for more details and will update the article when we get an answer.
In the meantime, if you do experience the same issues, try hiding the update until a fix or at least a statement is provided by Microsoft on this.”
Al momento quindi per evitare l’issue conviene nascondere l’aggiornamento sui computer e nel caso si utilizzi WSUS non approvare l’aggiornamento o rifiutarlo se precedentemente approvato.
Questa settimana mi è capitato di dover installare il Service Pack 1 di Windows 7 sul portatile della mia compagna. L’installazione veniva tentata tramite Windows Update senza successo ormai da qualche mese rallentando il sistema.
Le seguenti prove per tentare di risolvere il problema non hanno risolto il problema:
Analizzano l’Event Viewer ho notato il seguente evento di errore nel registro di Sistema:
Nome registro: System
Origine: Microsoft-Windows-Service Pack Installer
ID evento: 7
Categoria attività:Nessuna
Livello: Errore
Descrizione:
Modifiche a un aggiornamento (Service Pack per Microsoft Windows (KB976932)) non riuscite durante l’installazione del Service Pack.
Identità: Package_for_KB976932~31bf3856ad364e35~amd64~~6.1.1.17514
Codice errore: 0x800f081f
Stato destinazione: 7
Dal momento che l’evento di errore segnalava un problema con il package di installazione KB976932~31bf3856ad364e35~amd64~~6.1.1.17514, ho provato a rimuoverlo tramite il comando:
Finalmente dopo la rimozione del package il Service Pack 1 di Windows 7 si è installato correttamente. Probabilmente l’issue è stato causato da un’interruzione dell’installazione dell’SP1 prima che questa fosse completata lasciando il sistema in uno stato incoerente.
Per abilitare il servizio KMS (Key Management Service ) in esecuzione su WS2008R2 a gestire le chiavi di licenza KMS per Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1 e Windows Server 2012 R2 installare la KB 2885698 e riavviare il sistema quando richiesto.
Quindi occorre eseguire la seguente procedura eseguendo i comandi in un prompt dei comandi con privilegi amministrativi:
Rimuovere la chiave di licenza esistente tramite il comando: slmgr.vbs /upk
Installare la chiave di licenza per WS2012 R2 tramite il comando: slmgr.vbs /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
Attivare la chiave di licenza tramite il comando: slmgr.vbs /ato
Visualizzare la situazione delle chiavi di licenza tramite il comando:
cscript %windir%\system32\slmgr.vbs /dlv
In caso di problemi è possibile provare a riavviare il servizio Protezione Software che si occupa di erogare le chiavi KMS tramite il comando (a riguardo si veda Deploying KMS Activation): net stop sppsvc && net start sppsvc
Per un report più dettagliato sulle chiavi di licenza è possibile utilizzare il comando: cscript %windir%\system32\slmgr.vbs /dli
Per forzare su un client l’attivazione senza attendere i tempi dettati dalla sua modalità di funzionamento descritto qui Understanding KMS è possibile utilizzare il comando: cscript %windir%\system32\slmgr.vbs /dli
A riguardo si veda il post How To Verify or Check your KMS/MAK Product Key relativo alla versione 2.0, l’ultima versione è la 3.0 che permette la gestione di KMS e Active Directory Based Activation, la gestione tramite PowerShell, la Proxy Authentication e i la generazione dei Licensing Reports.
Scenario: aggiornamento dei driver delle scheda di rete Broadcom su alcune server DELL PowerEdge 1950 con Windows Server 2008 R2. Dopo l’installazione del package driver Broadcom Windows 64bit driver update for NetXtreme I and NetXtreme II Ethernet adapters for the 18.4.2 update contente anche la versione 4 della Broadcom Advanced Control Suite (BACS4) quest’ultima non riusciva più a connettersi all’host. In realtà il problema capita spesso come si più vedere dal seguente thread sui forum di Broadcom BCM5720 Teaming greyed out e può verificarsi anche su WS2012/WS2012 R2.
I vari tentativi di riavviare il server, avviare la BACS4 in modalità esegui come amministratore, disinstallare e reinstallare il package controllando di aver selezionato anche le opzioni CIM Provider e BASP come suggerito nella KB di DELL SLN110336 – Windows Server: Common Issues in Broadcom Advanced Control Suite 4 (BACS4) non hanno risolto l’issue, come neppure l’aggiornamento del firmware.
Rimozione del package d’istallazione dei driver avviando il setup e selezionando l’opzione Remove
Reset del WMI repository avviando da un prompt dei comandi eseguito con credenziali amministrative del seguente comando: winmgmt /resetrepository
Riavvio del sistema
Installazione del package dei driver selezionando le opzioni CIM Provider e BASP
A questo punto la BACS4 ha ripreso a funzionare correttamente connettendosi all’host senza problemi, ovviamente però la rimozione del package causa la disinstallazione del driver della scheda di rete e quindi anche la perdita della configurazione del team che va ricreato (la BACS permette l’esportazione delle configurazioni quindi se si è stati previdenti è possibile ripristinare il team semplicemente reimportando la configurazione)
Si noti che il reset del WMI repository mediante il comando winmgmt potrebbe richiedere la reinstallazione di eventuali altre applicazioni di terze parti presenti sul sistema se queste non utilizzano lo statement #pragma autorecover.
NOTE: The attached file (msicuu2.zip) was removed from Microsoft’s website. It is referenced in the “Very Reliable Method” section and is intended to remove the “Broadcom Advanced Control Suite” listing from Add/Remove Programs and Programs and Features.
The Broadcom network card driver used in the instructions is the “Hard Drive” installation package. Once used, only the full version may be used in future updates and installations of the Broadcom NIC drivers. “Windows Update” Broadcom NIC drivers are available but are only intended Dell-installed (i.e. factory installed) Windows installations. “Windows Update” drivers cannot be used after installing or trying to install the full drivers.
Device Manager cannot be used to install the network drivers. It is not a complete installation of the Broadcom driver. Both the Device manager driver AND the BACS software MUST be installed for the driver to operate correctly.
In caso di problemi a reperire un package d’installazione si ricordi che l’archivio dei package d’installazione per i device di rete su server DELL è disponibile al http://ftp.dell.com/network.
Talvolta può succedere che tramite l’applet Sistema non si riesca ad eliminare un profilo non più utilizzato in quanto il bottone di eliminazione risulta disabilitato.
Per verificare se tali file sono in uso è possibile utilizzare il tool Process Explorer che permette la ricerca dei handle aperti.
I file di registry possono rimanere aperti anche dopo il riavvio e l’apertura di una sessione con credenziali diverse da quelle relative al profilo incriminato se vi sono processi elaborati nella fare di avvio del computer correlati all’account utente di cui si sta tentando di eliminare il profilo.
In particolare quello che spesso succede è che vi siano operazioni pianificate eseguite nel contesto dell’account utente di cui si sta tentando di eliminare il profilo. Un modo per eseguire tale verifica è utilizzare il tool Autoruns for Windows.
In un caso che mi è capitato di gestire vi erano delle operazioni pianificate relative a Google Updater, Facebook Updater e altri software scedulati per essere eseguiti nel contesto dell’account utente di cui si desiderava eliminare il profilo. Eliminati tali operazioni pianificate è stato possibile eliminare il profilo tramite l’applet Sistema senza problemi.
Scenario: Hyper-V Windows Server 2012 R2 (ma si verifica anche in Windows Server 2012) durante l’installazione di Windows Server 2012 R2 su una VM compare l’errore:
0xE0000100: “Errore imprevisto dell’installazione di Windows. Verificare che le origini di installazione siano accessibili, quindi riavviare l’installazione.”
o se l’OS dell’host Hyper-V è in inglese:
0xE0000100: “Windows installation encountered an unexpected error. Verify that the installation sources are accessible, and restart the installation.”
Anche se sembrerebbe un errore legato alla non corretta lettura dell’immagine iso utilizzata per installare il sistema operativo nella VM, la causa dell’issue è legato all’impostazione di memoria della VM.
Nel mio caso la VM aveva le seguenti impostazioni si memoria:
Durante la fase d’installazione la funzionalità di memoria dinamica non è utilizzabile e quindi alla VM vengono di fatto assegnato un valore di RAM coincidente alla RAM di avvio che però probabilmente non sono sufficienti a gestire il caricamento dell’iso.
Per risolvere il problema è bastato aumentare la RAM di avvio a 1024 MB.
Se aprendo tramite Acrobat Reader un ODF vi viene segnalato un errore relativo alla mancanza del font ArrowNarrow non riuscendo quindi a visualizzare le parti del documento scritte con tale font, le cause possono essere diverse. Inoltre l’issue è legato ad un OS o ad una versione particolare di Acrobat Reader.
Reason
In revising Arial Narrow, Microsoft added new name fields for the “preferred” family and style, andintroduced the behavior wherein all four Arial Narrow fonts are labeled as having the same style (e.g. “Narrow” instead of “Narrow Bold Italic”).
Solution 1 : Install an updated version from Microsoft.
Search your system for adobefnt*.lst and delete any of these files; example, adobefnt02.lst.
Restart the application.
Solution 2: ReplaceArial Narrow version 2.35 with previous version font files (version 2.30 or earlier).
Quitall Adobe applications.
Locate the Arial Narrow font files in the C:\windows\fonts folder and confirm the version of the font files:
– ARIALN.TTF- ARIALNB.TTF
– ARIALNBI.TTF
– ARIALNI.TTF
Double-click the font file to open the font preview and display the version number.
Nel caso che ho analizzato io ho risolto il problema in modo differente dal momento che non volevo eseguire un downgrade del font per non causare eventuali problemi ad altre applicazioni. La procedura che ho utilizzato è stata semplicemente quella di copiare con privilegi amministrativi i file del font ArialNarrow(ARIALN.TTF, ARIALNB.TTF, ARIALNBI.TTF e ARIALNI.TTF) da %WinDir%\Fonts in %ProgramFiles(x86)%\Adobe\Reader 11.0\Resource\Font.
Come si può leggere nel documento Accessing and embedding fonts using Distiller dell’help online di Adobe tale cartella viene utilizzata come primo punto da cui avviare la ricerca dei font:
When converting a PostScript file to PDF, Distiller needs access to the file’s fonts to insert the appropriate information in the PDF. Distiller first searches the PostScript file for Type 1, TrueType, and OpenType fonts. If the font isn’t embedded in the PostScript file, Distiller searches additional font folders. Distiller searches the following font folders in Windows:
/Resource/Font in the Acrobat folder
/Windows/Fonts
Distiller searches the following font folders in Mac OS:
/Resource/Font in the Acrobat folder
/Users/[user name]/Library/Fonts
/Library/Fonts
/System/Library/Fonts
The Acrobat installation includes width-only versions of many common Chinese, Japanese, and Korean fonts, therefore Distiller can then access these fonts in Acrobat. Make sure that the fonts are available on your computer. (In Windows, choose Complete when you install Acrobat, or choose Custom and select the Asian Language Support option under the View Adobe PDF category. In Mac OS, these fonts are installed automatically.)
For information on including fonts in a PostScript file, see the documentation that came with the application and printer driver you use to create PostScript files.
Note: Distiller does not support Type 32 fonts.
To specify other font folders for Distiller to search, in Acrobat Distiller, choose Settings > Font Locations. Then in the dialog box, click Add to add a font folder. Select Ignore TrueType Versions Of Standard PostScript Fonts to exclude TrueType fonts that have the same name as a font in the PostScript 3 font collection.
Note: To provide Distiller with access to a font folder that has been moved, use this dialog box to remove the folder listed in its old location and add it in its new location.
Una terza soluzione che non ho provato potrebbe essere quella di eliminare o rinominare i file che contengono l’enumerazione dei font: %appdata%\local\Adobe\Acrobat\11.0\Cache\AcroFnt*.lst a riguardo si veda il post LiveCycle ES: what is the AdobeFnt11.lst file? sul blog di David McMahon (Sr.Technical Account Manager at Adobe Systems – Germany).
Le versioni di Office 2007 / 2003 / XP non prevedevano il supporto ai file in OpenDocument format ovvero gli ODF files (.odt, .ods and .odp).
A partire da Office 2007 SP2 è stato fornito il supporto ai file ODT in modo nativo, mentre nelle versioni precedenti il supporto viene fornito tramite add-in di terze parti (a riguardo si veda OpenDocument software).
Il Service Pack 2 di Microsoft Office Compatibility Pack non aggiunge il supporto per i seguenti tipi di file in formato OpenDocument:
odt (testo)
ods (foglio di calcolo)
odp (presentazione)
Questi tipi di file sono stati aggiunti al Service Pack 2 per la famiglia di prodotti Microsoft Office 2007. Per aprire o modificare i tipi di file in formato OpenDocument nelle versioni di Word, Excel o PowerPoint precedenti a Office 2007, utilizzare il componente aggiuntivo ODF (OpenDocument Format) per Microsoft Office. Per scaricare questo componente aggiuntivo, visitare il seguente sito Web SourceForge.net (informazioni in lingua inglese): http://odf-converter.sourceforge.net/download.html#hDownloadOffice
The goal for this project is to provide translators to allow for interoperability between applications based on ODF (OpenDocument) standards (currently ODF 1.1) and Microsoft OpenXML based Office applications. As a part of this interoperability initiative, add-ins are being developed that can be installed on top of Microsoft Office Word (document processing), Excel (spreadsheet) and PowerPoint (presentation) applications (Office 2007 / 2003 / XP version) to allow for opening and saving OpenDocument format / ODF files (.odt, .ods and .odp) that adheres to ODF specifications. We also provide command line translator utilities that allow doing batch conversions.
The converter is based on XSL transformations between two XML formats, along with some pre- and post-processing to manage the packaging (zip / unzip), schema incompatibilities and the integration into Microsoft Office applications like Word, Excel and PowerPoint. We chose to use an Open Source development model that allows developers from all around the world to participate and contribute to the project.
Along with the add-ins for Microsoft Word, Excel and PowerPoint, we also provide a command line translator that allows doing batch conversions. These translators can also be run on the server side for certain scenarios.
La particolarità di questo progetto è che coinvolge un nutrito gruppo di partner e questo dovrebbe garantire al progetto una sicurezza di continuità nello sviluppo:
DIaLOGIKa (Development & European Institutions scenarios testing – Germany)
Sonata-Software (Development and End to End functionality testing – Bangalore, India)
Microsoft (Funding, Architectural & Technical Guidance and Project co-coordination)
Per riportare uno switch HP V1910 (JE007A) alle impostazioni predefinite di fabbrica è possibile utilizzare la seguente procedura:
Connettersi allo switch tramite cavo console (seriale DB-9 femmina – RJ45) con le seguenti impostazioni (per la connessione è possibile utilizzare HyperTerminal o Putty):
Bits per second=38400
Data bits=8
Parity=None
Stop bits=1
Flow control=None
Emulation=VT100
Autenticarsi allo switch (per default la credenziale amministrative è User: admin senza password)
Abilitare la command line tramite il comando _cmdline-mode on e premere Invio
Confermare l’abilitazione della commad line digitando y quindi premere Invio
Digitare la password (la password di default è 512900)
Per visualizzare i comandi disponibili digitare ?
Per ripristinare le impostazioni di fabbrica digitare initialize quindi premere Invio
Nel baso invece sia stata persa la password di admin è possibile ripristinare l’accesso allo switch mediante la seguente procedura HP 1910 Switch Series – Password Loss.
Se Java non viene aggiornato sui computer si può incorrere nel blocco delle versioni obsolete da parte di Internet Explorer per evitare varchi di sicurezza.
Il componente che si occupa di questa gestione è l’Out-of-date ActiveX control blocking che blocca le versioni di componenti ritenute obsolete contenute nella seguente lista.
L’Out-of-date ActiveX control blocking è attivo su tutte le Security Zones di Internet Explorer eccetto la Local Intranet Zone e la Trusted Sites Zone e funziona con le seguenti combinazioni di Sistema Operativo e versione di Internet Explorer:
Sistema operativo
Versione Internet Explorer
Windows 8.1 e Windows 8.1 Update
Da Internet Explorer 8 a 11
Windows 7 SP1
Da Internet Explorer 8 a 11
Windows Server 2012
Da Internet Explorer 8 a 11
Windows Server 2008 R2 SP1
Da Internet Explorer 8 a 11
Windows Server 2008 SP2
Internet Explorer 9
Windows Vista SP2
Internet Explorer 9
Scendendo nel dettaglio del funzionamento l’Out-of-date ActiveX control blocking scarica in locale una copia del file versionlist.xml e lo memorizza in %LOCALAPPDATA%\Microsoft\Internet Explorer\VersionManager\versionlist.xml tale file è utilizzato per verificare versioni dei controlli da bloccare e viene controllato dall’ Out-of-date ActiveX control blocking aggiornato automaticamente da Internet Explorer se necessario.
Anche se ovviamente è sconsigliato è possibile bloccare l’update del file versionlist.xml impostando a 0 la chiave di registro HKCU\Software\Microsoft\Internet Explorer\VersionManager\DownloadVersionList ad esempio tramite il comando:
Per gestire in modo centralizzato il comportamento del’Out-of-date ActiveX control blocking è possibile utilizzare le seguenti 4 Group Policy settings per computer o per utente disponibili per Internet Explorer dalla versione 8 alla 11:
Turn on ActiveX control logging in Internet Explorer
Remove the Run this time button for outdated ActiveX controls in Internet Explorer
Turn off blocking of outdated ActiveX controls for Internet Explorer on specific domains
Turn off blocking of outdated ActiveX controls for Internet Explorer
Remove the Update button in the out-of-date ActiveX control blocking notification for Internet Explorer
Grazie alla GPO Turn on ActiveX control logging in Internet Explorer è possibile eseguire l’inventory degli ActiveX controls utilizzati nell’infrastruttura aziendale. Infatti l’abilitazione di tale GPO implica la memorizzazione degli Internet Explorer logs relativi alle informazioni sugli the ActiveX control sul file locale %LOCALAPPDATA%\Microsoft\Internet Explorer\AuditMode\VersionAuditLog.csv (per i dettagli sul formato del file VersionAuditLog.csv si veda la documentazione dell’Out-of-date ActiveX control blocking). Una volta abilitato il logging è possibile, ad esempio tramite PowerShell, estrarre le informazioni e riversarle poi su file unico. Per un esempio di estrazioni dati dal file VersionAuditLog.csv si veda ad esempio lo script PowerShell Get-ActiveXControlLog (Retrives content from the IE ActiveX blocking log).
Tornado al problema iniziale ovvero il blocco di versioni Java obsolete ad esempio su pagine “fidate” in scenari in cui putroppo non sia possibile aggionare la versione di Java perché determinati applicativi non funzionerebbero più correttamente (situazioni aimè purtroppo tutt’altro che rare o improbabili) sono possibili varie soluzioni in base agli approfondimenti sul funzionamento dell’Out-of-date ActiveX control blocking.
Soluzione 1: Disabilitazione del blocco dei controlli obsoleti in Internet Explorer
E’ possibile disabilitare il blocco dei controlli obsoleti tramite la GPO per computer o per utente Administrative Templates\Windows Components\Internet Explorer\Security Features\Add-on Management\Turn off blocking of outdated ActiveX controls for Internet Explorer
In alternativa è possibile eseguire la disabilitazione impostando a 0 la chiave di registro HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Ext ad esempio tramite il comando:
Ovviamente questa è la soluzione più drastica e non consigliata in quanto espone la macchina a malware veicolizzati tramite siti attaccati o attaccanti che sfruttano le vunerabilità delle versioni obsolete di Java.
Soluzione 2: Inserimento degli url fidati nella Local Intranet Zone o nella Trusted Sites Zone di Internet Explorer
Questo approccio può essere applicabile ad url relativi alla Intranet aziendale che espone applicazioni line-of-business, ma non è un approccio consigliato per url pubblici che grazie al fatto di essere inseriti nella Local Intranet Zone o nella Trusted Sites Zone potrebbero avere privilegi troppo elevati.
By default, the Local Intranet zone contains all network connections that were established by using a Universal Naming Convention (UNC) path, and Web sites that bypass the proxy server or have names that do not include periods (for example, http://local), as long as they are not assigned to either the Restricted Sites or Trusted Sites zone.
The default security level for the Local Intranet zone is set to Medium (Internet Explorer 4) or Medium-low (Internet Explorer 5 and 6).
Be aware that when you access a local area network (LAN) or an intranet share, or an intranet Web site by using an Internet Protocol (IP) address or by using a fully qualified domain name (FQDN), the share or Web site is identified as being in the Internet zone instead of in the Local intranet zone.
This zone contains Web sites that you trust as safe (such as Web sites that are on your organization’s intranet or that come from established companies in whom you have confidence).
When you add a Web site to the Trusted Sites zone, you believe that files you download or that you run from the Web site will not damage your computer or data.
By default, there are no Web sites that are assigned to the Trusted Sites zone, and the security level is set to Low.
Per ulteriori informazioni si vedano anche i seguenti:
Soluzione 3: Disabilitazione del blocco dei controlli obsoleti in Internet Explorer per specifici domini o Url locali e remoti
E’ possibile disabilitare il blocco dei controlli obsoleti tramite la GPO per computer o per utente Administrative Templates\Windows Components\Internet Explorer\Security Features\Add-on Management\Turn off blocking of outdated ActiveX controls for Internet Explorer on specific domains
In alternativa è possibile eseguire la disabilitazione impostando la chiave di registro HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Ext\Domain ad esempio tramite il comando:
Questa a mio avviso è la soluzione più consigliabile in quanto permette di gestire esclusivamente l’esclusione del controllo del blocco delle versioni Java obsolete (o altri controlli obsoleti) su domini/url “fidati” consentendo la funzionalità che sia aveva precedente.
Conclusioni
In base al proprio scenario occorre valutare attentamente la soluzione che permette la funzionalità dell’applicativo che utilizza versioni Java o controlli obsoleti mantenendo però la superficie di attacco minore.
In ogni caso si tenga presente che non appena possibile è altamente consigliabile aggiornare la versione Java o dei controlli obsoleti utilizzati.
Molto spesso il ruolo DHCP viene installato su un host che assolve anche al ruolo di Domain Controller occorre però precisare che questa scelta presenta delle implicazioni di sicurezza evidenziate dal tool Best Practices Analyzer presente in Windows Server a partire dalla versione 2008 R2.
Come riportato nel post DHCP Server in DCs and DNS Registrations se non si esegue tale configurazione si va incontro a rischi per la sicurezza del Domain Controller e ad un funzionamento ridotto:
What happens when the DHCP Server service is installed in a DC and no alternate credentials are configured? A common error is to think that the DHCP Server service running in a DC will use its service account security context to register records in DNS if no alternate credentials are configured, and then there is security risk. In fact, this is not the behavior of the DHCP Server in a DC. If the DHCP Server service detects that it is running in a domain controller, and no alternate credentials for DNS registrations have been configured, then it decides to not do any registrations for DHCP clients and logs event DHCP/1056.
NOTE: this does not affect other registrations being done by the computer where the DHCP Server service is running, it only affects the registration of DNS records by the DHCP Server on behalf of the DHCP clients.
What is the side-effect of this?
When the DHCP Server decides that it is not going to do registrations for DHCP clients, it stops setting option 81 in the responses to clients (option 81 is used to negotiate who registers what between the DHCP Server and the DHCP Client). If the client does not get this option in the response from the server then it goes and does its own registrations.
Recommendations
If the DHCP Server is configured to run in a DC, make sure that the alternate credentials for DNS registrations are correctly configured.
Use a “normal” user account, not an administrative or privileged account, for the alternate credentials. Just make sure to use the Password Never Expires option. There is not need to add this account to any special group. The steps to configure these credentials are documented in http://support.microsoft.com/kb/282001. If there are more than one DHCP Server in the environment, try to use the same account for the alternate credentials in all of them.
“On a server that is dedicated to the domain controller role, you can reduce the number of members in the Backup Operators group. If possible, domain controllers should be dedicated, but in smaller organizations a domain controller might be used to run other applications. In this case, users who are responsible for backing up applications on the domain controller must also be trusted as service administrators because they have the privileges that enable them to restore files, including the system files, on domain controllers.”
In ogni caso vi sono ruoli e funzionalità che non dovrebbero o non possono essere installati su un Domain Controller come ad esempio la feature IPAM (IP Address Management) come indicato al seguente IPAM Deployment Planning:
“IPAM must be installed on a domain member computer. You cannot install IPAM on a domain controller. If IPAM is installed on the same server with DHCP, then DHCP server discovery will be disabled.”
Conclusioni
Sebbene il DHCP previa la configurazione di sicurezza descritta possa essere installato su un Domain Controller è preferibile per motivi di sicurezza e di semplificazione della gestione dell’infrastruttura dedicare un host fisico o virtuale al DHCP. Il server DHCP in effetti essendo essenziale ai fini delle funzionalità di rete soprattutto in infrastrutture con un elevato numero di client dovrebbe essere istallato su un server con questo unico ruolo i modalità core in modo da ridurre il numero di riavvi a causa dell’installazione degli aggiornamenti del sistema operativo. In Windows Server 2012 per garantire il servizio DHCP in alta affidabilità è possibile implementare il DHCP Failover, a riguardo si vedano i seguenti link:
Active Directory è un repository di oggetti e come tale può essere oggetto nella sua vita anche operazioni errati di cancellazione e/o modifica. Le cause di questi danni accidentali possono essere varie come ad esempio l’errore umano oppure l’esecuzione di un tool/script che segue operazioni massive . Diventa quindi importante mettere in campo una serie di best practices atte a prevenire e quando non possibile recuperare i dati persi. Di seguito elencherò una serie di accorgimenti e procedure derivate dalla mia personale esperienza.
1. Prevenzione mediante delega amministrativa
Molto spesso all’interno di infrastrutture informatiche vi sono soggetti che eseguono alcune operazioni amministrative su determinate Organizational Unit come la creazione e la manutenzione di utenti. Di conseguenza è consigliabile concedere solo le autorizzazioni necessarie a tali soggetti . L’operazione può essere semplicemente eseguita tramite la GUI di Active Directory Users and Computers a riguardo si vedano:
Va precisato che perché questo metodo di protezione abbia effetto occorre sviluppare in modo iterativo un modello di delega seguendo ad esempio questa procedura come descritto nell’articolo Delega dell’autorità in Active Directory di Joel Yoker (Senior Consultant Microsoft Consulting Services) e Rob Campbell (Senior Technical Microsoft Consulting Services):
Definire i ruoli amministrativi IT all’interno dell’organizzazione
Sviluppare un modello per unità amministrative e gruppi di protezione
Definire gli account secondari per gli amministratori IT
Delegare i diritti
Ovviamente un prerequisito essenziale per l’adozione delle delega amministrativa è l’utilizzo di account dedicati da parte dei soggetti che a vario titolo e autorizzazione intervengono su Active Directory. La Bad Practice di utilizzare l’account Administrator deve essere relegata solo per operazioni eccezionali di istallazione o configurazioni particolari come ad esempi una migrazione di AD. A riguardo il mio consiglio è quello di configurare, ad esempio, tramite script l’invio di mail di allarme quando si rileva sui domain controller un login tramite l’account Administrator in modo da scoraggiarne l’utilizzo perché in conseguenza all’uso occorre motivarlo per evitare allarmi.
2. Prevenzione tramite la protezione da cancellazione accidentale di oggetti AD
La protezione dalla cancellazione accidentale èpossibile fin da Windows 2003 in quanto in realtà si basa sull’impostazione di permissions sugli oggetti AD in modo che non sia possibile l’eliminazione. Scendendo nel dettaglio questo significa impostare un Deny per le Delete and Delete Subtree advanced permissions sul gruppo Everyone.
In Windows Server 2008 tale impostazione è stata semplificata introducendo l’opzione “Protect object from accidental deletion” nello snap-in Active Directory Users and Computers che se selezionato imposta appunto la Deny delete subtree permission. Per poter utilizzare questa funzionalità occorre abilitare le visualizzazione delle Advanced Features nel menu View menu che rende disponibile l’opzione Protect object from accidental deletion nel tab Object. Inoltre è necessario avere nell’infrastruttura almeno un DC con Windows Server 2008 o successivo.
In Windows Server 2008 R2 sono stati resi disponibili gli Active Directory Cmdlets in Windows PowerShell tramite cui è possibile impostare in modo massivo la protezione da cancellazione accidentale sugli oggetti in AD.
Di seguito, ad esempio, i cmdlets per impostare la protezione da cancellazione accidentale sulla OU Ufficio001 nel dominio WindowsServer.it per oggetti di tipo Utente, Computer, Gruppo e Organizational Unit:
3. Recupero mediante abilitazione del cestino di Active Directory
Per velocizzare il recupero di oggetti cancellati è possibile abilitare il Cestino di Active Directory disponibile a partire da Windows Server 2008 R2 grazie al quale viene migliorato e semplificato il ripristino a seguito di eliminazioni che in Windows Server 2003 e Windows Server 2008 erano più difficoltosi e parziali. A riguardo si veda Windows Server 2008 R2: Active Directory Recycle Bin.
4. Recupero mediante restore autoritativo di Active Directory
Se il danno accidentale su AD non si sviluppa tramite eliminazione di oggetti, ma tramite una modifica o se non si ha a disposizione il Cestino di AD è possibile tentare il recupero tramite il restore di AD autoritativo totale o parziale.
Inoltre si vedano anche le Active Directory Backup and Disaster Recovery Procedures pubblicate da EDE Consulting nella sezione Active Publications, al momento sono disponibili le seguenti versioni dei documenti:
Nel caso estremo in cui i precedenti metodi di recupero non siano applicabili, ad esempi nei casi in cui gli oggetti AD da recuperare siano sparsi su varie OU o siano già intervenuti una serie di modifiche successive da preservare è possibile approcciare il recovery ripristinando un DC in una ambiente di test separato dalla produzione in un periodo temporale antecedente al disastro e utilizzare un tool di reportistica di AD per generare una fotografia dello stato da utilizzare poi per confronto e ripristino manuale.
Vi sono sono vari tool disponibili uno che ho avuto modo di testare è ADManager Plus disponibile in versione Trial per 30 giorni in grado di generare report Html, PDF e Csv.
Conclusioni
Se possibile è ovviamente meglio prevenire le situazioni disastrose generate per cause accidentali, ma non si può ovviamente pensare di riuscire ad evitare in modo completo eventuali danni accidentali. Quindi è necessario avere sempre a disposizione backup dei System State aggiornati dei Domain Controller.
Inoltre può essere utile abilitare il l’Auditing delle operazioni di modifica su Active Directory per capire come il danno accidentale si è sviluppato ed evitare che si ripresenti in futuro ed adottare la più corretta procedura di ripristino. Per informazioni su come abilitare l’Auditing in AD si vedano:
Esistono anche una serie di tool di terze parti in grado di eseguire l’auditing di Active Directory fornendo feature ulteriori rispetto a quelle offerte nativamente dal sistema operativo. Di seguito alcuni esempi:
Per far sì che se un utente che ha privilegi di eliminazione elementi su cartelle di una mailbox condivisa (calendari, posta etc..) inserisca gli elementi eliminati nella cartella Posta Eliminata della mailbox condivisa anziché nella cartella dell’utente occorre eseguire una configurazione.
When you use Microsoft Outlook to delete items from a mailbox folder of another user for whom you have deletion privileges, the deleted items go to your Deleted Items folder rather than to the Deleted Items folder of the mailbox owner.
Per risolvere l’issue è sufficiente impostare la chiave:
HKCU\Software\Microsoft\Office\xx.0\Outlook\Options\General\DelegateWastebasketStyle al valore DWORD 4 dove:
xx=15 per Outlook 2013
xx=14 per Outlook 2010
xx=12 per Outlook 2007
xx=11 per Outlook 2003
xx=10 per Outlook 2002
xx=9 per Outlook 2000
Dopo aver eseguito l’impostazione è necessario riavviare Outlook.
Per gestire centralmente le impostazioni della suite office è possibile utilizzare Active Directory ed eseguire le configurazioni tramite Group Policy. Prima però occorre importare in AD gli Administrative Template di Office.
Di seguito uno step by step per l’importazione degli Administrative Template di Office 2013 in abiante Windows Serveer 2008 R2 e successivi:
Eseguire il setup dell’Office 2013 Administrative Template files (ADMX/ADML) and Office Customization Tool, ovvero admintemplates_64bit.exe, nel caso di OS a 64 bit, per estrarre il file admx e adml in una cartella, ad esempio C:\Office2013-ADMX.
Copiare in %systemroot%\sysvol\domain\policies\PolicyDefinitions i file necessari. Per esempio per poter gestire le impostazioni di Outlook2013 nelle localizzazioni Inglese e Italiano copiare i seguenti file:
C:\Office2013-ADMX\admx\outlk15.admx in %systemroot%\sysvol\domain\policies\PolicyDefinitions
C:\Office2013-ADMX\admx\en-us\outlk15.adml in %systemroot%\sysvol\domain\policies\PolicyDefinitions\en-us
C:\Office2013-ADMX\admx\it-it\outlk15.adml in %systemroot%\sysvol\domain\policies\PolicyDefinitions\it-it
Nel caso in cui un utente possa inviare mail per conto di una mailbox condivisa vi sono alcune considerazioni da fare per quanto riguarda i send items e la posizione in cui questi verranno memorizzati considerando che probabilmente può essere più utile che i send items vengano salvati nella posta inviata della mailbox condivisa.
Il salvataggio dei Send Items nella posta inviata della mailbox condivisa è disponibile in Outlook a partire dalla versione 2003, ma per ogni versione occorre fare delle considerazioni separate.
In Outlook 2003, Outlook 2007 e Outlook 2010 è necessario installare una hotfix, mentre Outlook 2013 ha il supporto nativo per tale funzionalità:
When you send an email message from a shared mailbox, the sent email message remains in your Outbox until you manually perform a Send/Receive operation)
This problem occurs when all the following conditions are true:
Your Outlook profile is configured in online mode (not cached Exchange mode).
You have the DelegateSentItemsStyle registry value set to 1.
Update Rollup 4 for Exchange Server 2010 Service Pack 2 introduced a new Exchange PowerShell cmdlet to configure the Sent Items folder to which a message is copied. Because this new feature is handled by the Exchange server, Outlook can be configured for online or cached Exchange mode. However, the Exchange server feature works only if the Outlook DelegateSentItemsStyle registry value is disabled.
For more information about the Set-MailboxSentItemsConfiguration cmdlet, click the following article number to view the article in the Microsoft Knowledge Base: 2632409 Messages sent by using the “Send As” and “Send on behalf” permissions are only copied to the Sent Items folder of the sender in an Exchange Server 2010 environment
La configurazione descritta non è necessaria in Outlook 2010 e Outlook 2013 se vengono utilizzati gli account multipli che però richiedono l’accesso completo alla mailbox condivisa e non solo l’autorizzazione Invia Come. A riguardo si vedano:
Quando si costruisce una form ereditata da un’altra che conteneva dei controlli con l’impostazione Anchor non mantengono la posizione corretta se si modifica la dimensione della form ereditata in particolare se i controlli hanno l’Anchor impostato su Bottom.
“After you run or recompile a project, anchored controls may be restored to their original position on the base form. When you create a new Windows Form by inheriting from a base form that has private anchored controls, you may encounter unexpected run-time and design-time behavior. When you first resize the inherited form in the designer, the controls move correctly with the form; however, at run time or when you recompile, the controls are restored to their original position on the base form.”
Sempre nella KB 316560 vengono dati due suggerimenti su come risolvere il problema:
You can work around this problem by using one of the following methods:
Wait until after you run InitializeComponent to resize the form. Do not resize the form in the designer.
In the base form, change the access modifier of anchored controls (for example, button1) to be Protected in the base class, as follows: – In Microsoft Visual C#, change Private to Protected:
Protected System.Windows.Forms.Button button1; – In Microsoft Visual Basic .NET, change Friend to Protected: Protected WithEvents Button1 As System.Windows.Forms.Button
Sebbene la KB 316560 riporti che il problema è stato corretto nel Microsoft .NET Framework SDK 1.1 io l’ho rilevato su un progetto VB.NET in Visual Studio 2013 impostato per utilizzare .NET 4.5.
Per risolverlo ho modificato l’access modifier dei controlli da Friend a Protected, va precisato che se nelle form ereditate è stata modificata la dimensione prima di intervenire sull’access modifier dei controlli occorre eliminare manualmente dal file designer.vb della form ererditata le righe di codice relative al size della form:
Me.AutoScaleDimensions = New System.Drawing.SizeF(…, …)
Me.ClientSize = New System.Drawing.Size(…, …)
Quindi reimpostare la dimensione desiderata dal designer.
L’Autologon può essere utile in scenario in cui un computer viene utilizzato come chiosco, per attivarlo è necessario operare in due modi diversi a seconda che il computer sia a dominio o meno come indicato al seguente Attivare l’accesso automatico.
Per i computer in Workgroup è sufficiente utilizzare il comando control userpasswords2, mentre per i computer membri di dominio è necessario intervenire sulla chiave di registro HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon descritta al seguente Configuring Accounts to Autologon.
In the Open box, type Regedt32.exe, and then press Enter.
Locate the following subkey in the registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Double-click the DefaultUserName entry, type your user name, and then click OK.
Double-click the DefaultPassword entry, type your password, and then click OK. Note If the DefaultPassword value does not exist, it must be added. To add the value, follow these steps:
On the Edit menu, click New, and then point to String Value.
Type DefaultPassword, and then press Enter.
Double-click DefaultPassword.
In the Edit String dialog, type your password and then click OK. Note If no DefaultPassword string is specified, Windows automatically changes the value of the AutoAdminLogon key from 1 (true) to 0 (false), disabling the AutoAdminLogon feature.
On the Edit menu, click New, and then point to String Value.
Type AutoAdminLogon, and then press Enter.
Double-click AutoAdminLogon.
In the Edit String dialog box, type 1 and then click OK.
Exit Registry Editor.
Click Start, click Shutdown, and then type a reason in the Comment text box.
Click OK to turn off your computer.
Restart your computer. You can now log on automatically.
Si tenga conto che vi sono alcune limitazioni e alcune particolarità sempre descritte nella KB, in particolare si vedano le restrizioni legate a Windows 8/8.1:
To bypass the AutoAdminLogon process and to log on as a different user, press and hold the Shift key after you log off or after Windows restarts.
This registry change does not work if the Logon Banner value is defined on the server either by a Group Policy object (GPO) or by a local policy. When the policy is changed so that it does not affect the server, the autologon feature works as expected.
When Exchange Active Sync (EAS) password restrictions are active, the autologon feature does not work. This behavior is by design. This behavior is caused by a change in Windows 8.1 and does not affect Windows 8 or earlier versions. To work around this behavior in Windows 8.1 and later versions, remove the EAS policies in Control Panel.
An interactive console logon that has a different user on the server changes the DefaultUserName registry entry as the last logged-on user indicator. AutoAdminLogon relies on the DefaultUserName entry to match the user and password. Therefore, AutoAdminLogon may fail. You can configure a shutdown script to set the correct DefaultUserName entry for AutoAdminLogonAs. For more information, click the following article number to view the article in the Microsoft Knowledge Base: 19364 AutoAdminLogon loses DefaultUserName.
Generalmente quando si configura l’Autologon spesso risulta necessario anche configurare un’applicazione per l’avvio automatico, si ricordi che in Windows Vista e successivi la cartella esecuzione automatica si trova in %AppData%\Microsoft\Windows\Start Menu\Programs\Startup. Va però precisato che se il computer è in dominio potrebbe essere più semplice gestire l’avvio di applicazioni tramite Group Policy.
