Archives de catégorie : Windows 8

Multisite DirectAccess scenario in Powershell

Multisite is a very interesting scenario that was complicated to deploy with Windows 7 and Forefront UAG. If this challenging scenario does not scared you, have a look at this Edge Man post. Technically speaking, it was also possible to achieve a “similar” configuration with a Global Server Load Balancing configuration using F5 Big-IP for example. With Forefront UAG 2010, we had load-balancing capabilities with Network Load Balancing and Hardware Load Balancing but it was long to setup. Have a look at my high-availability blog post series if you want to compare to this blog post!

In Windows server 2012, multisite will become (this post is written with the Consumer Preview released in February 2012!) a much more easier deployment. What an interesting challenge to deploy it with PowerShell only. First, let’s see my configuration  :

MULTISITEVISIO

We have two sites having their own Windows 2012 server. The challenge is to setup the DA1 server as a DirectAccess server, convert it to multisite and and add DA2 as a new Entry Point for my Multisite configuration. Now let’s switch to PowerShell!

Initial DirectAccess configuration

Let’s start with my first DirectAccess server setup. It’s name is DA1.DirectAccessLab.Lan we start with the role installation :

Add-WindowsFeature –Name DirectAccess-VPN –IncludeManagementTools

ADDFEATURE0

In order to be sure that everything is operational, let’s check it with a single PowerShell command : Install-RemoteAccess –Prerequisite

ADDFEATURE1

I will need an IPHTTPS certificate on DA1.DirectAccessLab.Lan. Public name record in my certificate will be DA1.DirectAccessLab.Lan. Let’s check that my certificate is present in the computer store with the following command :

$IPHTTPS = (Get-ChildItem Cert:\\LocalMachine\My | Where {$_.Subject -like « CN=DA1.DirectAccessLab.Fr* »})

Write-Host $IPHTTPS

IPHTTPS1

Now, it’s time to configure our first DirectAccess server with a single PowerShell command :

Install-RemoteAccess -DAInstallType FullInstall -ConnectToAddress DA1.DIRECTACCESSLAB.FR -ClientGPOName « DirectAccesslab.Lan\DirectAccess Clients GPO » -ServerGPOName « DirectAccesslab.Lan\DirectAccess Servers GPO »-InternalInterface LAN-InternetInterface INTERNET -NLSURL https://nls.directaccesslab.lan –Force –PassThru

INSTALLREMOTEACCESS0

Server-side configuration is almost terminated. We need to configure Certification Authority to be used for IPSEC tunnels authentication. It is mandatory for multisite deployments, just like having a real IPHTTPS certificate for each entry point. The following PowerShell command will configure this :

$CA = (Get-ChildItem Cert:\\LocalMachine\Root | Where {$_.Subject -like « CN=INET* »})

Write-Host $CA

Set-Daserver -IPSecRootCertificate $CA -PassThru

FINALIZESERVER1

Now let’s switch to the client-side configuration with the Following PowerShell commands :

Add-DAClient –SecurityGroupNameList “DirectAccesslab.Lan\DA Clients”

Remove-DAClient –SecurityGroupNameList “DirectAccesslab.Lan\Domain Computers”

Set-DAClient –OnlyRemoteComputers Disabled

Get-DAClient

CLIENTSIDE

 

Client-side configuration is almost complete, we just need to configure some settings for end-user experience for the Network Connectivity Assistant. PowerShell commands bellow will configure it with an HTTP type probe located on a domain controller :

Set-DAClientExperienceConfiguration -PolicyStore « DIRECTACCESSLAB.LAN\DirectAccess Clients GPO » -UserInterface $True -SupportEmail HelpDesk@DirectAccesslab.fr -CorporateResources {HTTP:http:dc.directaccesslab.lan} -PreferLocalNamesAllowed $True -FriendlyName « DirectAccess Connection » -PassThru

SETDACLIENTEXPERIENCE

Our first DirectAccess server is now operational. Let’s check that with a Get-RemoteAccessHealth command :

GETREMOTEACCESSHEALTH0

If you need more explanations on this part, have a look at my DirectAccess in Powershell blog post.  Now we are ready for Multisite!

Enabling Multisite

We have a standalone server that must be converted as the first entry point of a Multi-site DirectAccess configuration. Each DirectAccess Server (or High-available group of DirectAccess servers) is considered as a DirectAccess Entry point. Let’s convert to Multi-Site :

Enable-DAMultiSite -EntryPointName « EMEA Headquarter » -ComputerName DA1.DirectAccesslab.Lan -ManualEntryPointSelectionAllowed Enabled -Name « DirectAccesslab Multi-Site Infrastructure » -PassThru – Force

ENABLEMULTISITE

 

Multi-site configuration is enabled with a single entry point named “EMEA Headquarter”. The  Get-DAEntryPoint command will provide some details on this entry point  :

GETDAENTRYPOINT1

 

Not many information. This entry point is not GSLB enabled and include a single server. Let’s have a look at this entry point with the Get-DAServer PowerShell command :

Get-DAServer -EntryPoint « EMEA Headquarter »

GETDAENTRYPOINT2

 

We have the same information as in standalone configuration. From a server point of view, there is not much more difference. At this point our only requirements are :

  • Do not use self-signed certificate for IPHTTPS
  • Enable computer certificates

 

By now we have operational Multisite DirectAccess infrastructure And that’s all for Multisite activation!

 

Adding a new entry point

Now come the most interesting part of this blog post : How to add a second entry point remotely. At the beginning of this step, my DA2.DirectAccessLab.Lan server is :

  • Joined to the DirectAccessLab.Lan Domain with a LAN named interface
  • Configured with a public interface named INTERNET with a public IP address
  • Having a public IPHTTPS certificate with DA2.DirectAccessLab.fr as subject name

 

Here are the only prerequisites that wont be performed remotely! Just like our first DirectAccess server, we need to install roles. Let’s use PowerShell remoting capabilities : Add-WindowsFeature –Name DirectAccess-VPN –IncludeManagementTools -ComputerName DA2.DirectAccesslab.Lan

ADDFEATURE2

 

And check it remotely : Install-RemoteAccess –Prerequisite –ComputerName DA2.DirectAccesslab.Lan

ADDFEATURE3

 

Before performing the magic trick, we must be sure that’s my IPHTTPS certificate for DA2.DirectAccessLab.Fr is present on my remote server :

$IPHTTPS = Invoke-Command –ComputerName DA2.DirectAccessLab.Lan –ScriptBlock {(Get-ChildItem Cert:\LocalMachine\My | Where {$_.Subject –Like “CN=DA2.DirectAccessLab.Fr*”})}

Write-Host $IPHTTPS

IPHTTPS2

 

And now, the magic trick. How to add a new DirectAccess Entry Point in an exiting Multi-site configuration remotely. As long as all prerequisites are already present, it’s a simple PowerShell Command :

Add-DAEntryPoint -Name « Backup Site » -ConnectToAddress DA2.DIRECTACCESSLAB.FR -InternalInterface LAN -InternetInterface INTERNET -ServerGPOName « DirectAccessLab.Lan\DirectAccess Backup Servers GPO » -RemoteAccessServer DA2.DirectAccessLab.Lan –PassThru -Force

ADDDAENTRYPOINT2

 

One thing we can notice is that we need an additional GPO to configure our new server. Each Entry point must have it’s own dedicated GPO. By now, our DirectAccess multi-site infrastructure have two entry point. The Get-DAMultiSite also report that users will be able to select the entry point they want to use. Windows 8 is able to connect to the first available entry point, but it’s not capable to really detect witch one is the closest from the client. Global Server Load Balancing feature was designed for that!

GETDAMULTISITE

 

If we take a look at our new entry point configuration with a Get-DAServer –EntryPoint “Backup Site” PowerShell command we can notice that there a much less information than for the first entry point. Information such as Internal Interface, InternetInterface or SSLCertificate are not provided. That’s must be a bug in the Consumer Preview version because these information are available if you run the same command on the remote server! That’s not a bug, it’s by design. Theses information will be available if you use the same Powershell CommandLet querying the server name and not the entry point.

GETDASERVERBACKUP

 

Let check everything

Everything seems to be operational on my first entry point. Some services are disabled but it’s normal (no 6to4 or Teredo support, no management server declared, no more OTP, …).

Get-RemoteAccessHealth –EntryPoint “EMEA Headquarter”

REMOTEACCESSHEALTH1

 

But on my second entry point we can notice one minor difference with ISATAP. My DA2.DirectAccessLab.Lan is not considered as an ISATAP router. It’s only an ISATAP client from my DA1.DirectAccessLab.Lan server.

Get-RemoteAccessHealth –EntryPoint “Backup Site”

REMOTEACCESSHEALTH2

 

In my opinion, it’s a bug on my lab. During DA2.DirectAccessLab.Lan configuration, my server already had an ISATAP interface properly configured. That’s must be why there is no ISATAP router on my server. This should not append in production environment (My lab need to be fixed on this point!)

 

And now from the client-side perspective

From a Windows 8 point of view, a DirectAccess Multi-site infrastructure is just two URL, one for each Entry point. So Multi-site only rely on IPHTTPS transition protocol. That’s why Teredo support is not active on my infrastructure (and because each entry point have only one IPv4 public address!). Windows 7 only support one URL for IPHTTPS interface, that’s why legacy operating systems cant use Multi-site.

Get-NetIPHTTPSConfiguration

GETNETIPHTTPSCONFIGURATION

 

It’s cool to have two entry point, but witch one is currently used? Simple : Get-NetIPHTTPSState

GETNETIPHTTPSSTATE

 

Back to server-side

Multi-site infrastructure is now operational. We need more than an active IPHTTPS interface to validate that point. We need to be able to track IPSEC sessions :

Get-RemoteAccessStatistics | Format-List

Get-RemoteAccessStatisticsSummary | Format-List

FINALSTATS

 

At last, the console view

Now we have an operational DirectAccess infrastructure with Multi-site capabilities. From the console point of view, here what’s it look like :

CONSOLEVIEW

 

Conclusion

I’m sure this deployment process can be fully automated (With PowerShell jobs). If you compare with my high-availability blog post series on Forefront UAG 2012, it will be now more easier to deploy DirectAccess in a high availability scenario and avoiding complex networking issues with Windows Server 2012. Infrastructure described in this post is not compatible with legacy clients (yes Windows 7 is a legacy client!) but there only few changes to allow these clients to connect to an entry point.

BenoîtS – Simple and Secure by Design but Windows 8 compliant!

Disconnect DirectAccess in Windows 8.x while on LAN

A small blog post to relay an interesing post from Richard Hicks. Microsoft just published an update applicable to Windows 8.x DirectAccess clients to solve an interesting problem When the DirectAccess clients are not able to reach the Network Location server While on LAN. As they are not able to reach NLS, they try to enable DirectAccess while on LAN. Users can wait for a while.

before

After you apply the update, your users will be able to disconnect from DirectAccess in such situation.

After

 

Thank you Richard for pointing that out.

 

BenoîtS – Simple and Secure by design but business compliant.

Windows to go, pas que pour les Geek

Etre Geek, c’est aussi identifier des solutions innovantes qui peuvent apporter un véritable plus dans les projets. Dans le cas présent, les projets de migration de poste de travail. Sur ce point, grand merci à Stanislas Quastana pour la solution SPYRUS WorkSafe Pro :

clip_image001

Cette solution ne doit pas être considérée comme un produit pout "Geek" mais comme un véritable Solution Accelerator pour les projets de migration vers Windows 8. Tout projet de migration vers Windows 8 va impérativement devoir adresser des sujets autour :

  • De la compatibilité applicative
  • Du packaging des applications
  • L’introduction de la virtualisation applicative
  • Introduire de nouvelles fonctionnalités sécurité (Bitlocker, DirectAccess, Smartcard, …)

Par expérience, quel que soit la qualité des intervenants impliqués dans un projet de migration de poste de travail, on tombe invariablement sur la capacité à mettre à disposition les packages applicatifs validés pour pouvoir délivrer le nouveau poste de travail vers Windows 8.1. C’est le principal frein aux projets de migration. Au final, le projet prend du retard, avec risque de ne pas être en capacité de répondre aux exigences business à la source du projet (on ne fait pas de projet pour le plaisir de faire un projet). Un business case a été monté, il est censé avoir mis en évidence des quickwins et donc des réductions de couts.

La solution de SPYRUS (lien) intègre à la fois :

  • Une clé USB prévue pour l’usage Windows To go
  • Assez de capacité pour héberger applications et données utilisateur si nécessaire
  • Une carte à puce intégrée (plus besoin de lecteur)

De mon point de vue, inscrire cette solution dans le cadre d’un projet de migration vers Windows 8.1 doit être pris au sérieux. Le plus grand frein à l’adoption d’un nouveau système d’exploitation dans l’entreprise c’est la disponibilité des applications sur la nouvelle plateforme. Migrer un utilisateur sans ses applications n’a pas de sens. Tout projet de migration de poste de travail doit être en mesure de réduire la phase de coexistence au plus court pour éviter :

  • La double gestion (et donc les double couts)
  • Un allongement de la durée du projet (et donc de son cout)
  • Proposer un retour arrière pour les erreurs de migration (mais pas trop sinon on prend du retard et ça coute cher)
  • La solution du double poste physique qui est un gouffre économique

C’est là que Windows to Go prend tout son intérêt. L’utilisateur en demandant toujours plus, il est prêt à adopter un nouveau système d’exploitation (en changent de PC, cela va de soi) si toutes ses applications sont disponibles.

Dans le cadre d’un projet de migration de postes, la solution de SPYRUS une solution intéressante pour assurer la coexistence entre le legacy et le futur poste de travail. Si toutes les applications ne sont pas encore packagées sous Windows 8, on peut au moins proposer deux postes de travail à l’utilisateur grâce à Windows To go. Certes cela a un cout mais on est capable de rapidement embarquer des utilisateurs et donc accélérer la migration. En plus, cela permet de dissocier les problématiques :

  • On est capable de déployer le nouveau poste de travail rapidement
  • On est capable de maintenir l’accès au poste "legacy" pour certaines applications (un reboot et on retrouve l’ancien poste)
  • C’est l’utilisateur qui peut décider de sa date de migration
  • On peut proposer de l’authentification forte en avance de phase sur les postes "legacy"
  • La migration des données locales est facilité (plus de transfert réseau, c’est que du local)

Lorsqu’on inscrit cette solution dans un projet poste de travail, on peut proposer quelques scénarios intéressants dont l’onboarding rapide :

  1. La mise à disposition de la clé Windows To Go par courrier, y compris à domicile
  2. L’utilisateur connecte la clé Windows To Go à son poste de travail Legacy et démarre Windows 8
  3. L’utilisateur contacte le support pour réaliser l’Offline domain Join en DirectAccess (ben quoi, il fallait bien le caser celui-là)
  4. L’utilisateur réaliser l’enrôlement de sa carte à puce
  5. Installation des applications MSI/APP-V via SCCM même à domicile (Viva DirectAccess)

De là, l’utilisateur a un poste de travail opérationnel sous Windows 8.1 tout en ayant la possibilité de revenir sur son poste "Legacy" en un simple reboot. La majorité des postes de travail étant aujourd’hui des portables, on facilite grandement la migration de ces populations qui ne sont pas souvent dans les locaux de l’entreprise.

Dès lors que toutes les applications ont été validées, l’utilisateur peut passer au bureau pour prendre livraison de son nouveau poste de travail. Si on a bien pensé la gestion de la localisation des données utilisateurs, la migration de celles-ci consistera à réaliser un simple USMT de Windows 8.1 vers Windows 8.1. A la première ouverture de session l’utilisateur récupère donc toutes ses données ainsi que ses applications (SCCM 2012 est user-centric), il n’a plus besoin de la clé SPYRUS, il est possible de recycler celle-ci pour l’onboarding d’autres utilisateurs.

Au final, Windows To Go simplifie grandement la migration vers Windows 8.1, tout en proposant à l’utilisateur d’être early-adopter en toute sécurité. Il existe bien d’autres scénarios d’usages :

  • La mise à disposition d’un poste de travail temporaire en utilisant le portable/tablette personnelle de l’utilisateur
  • Du BYOD maîtrisé (matériel de l’utilisateur mais OS/Applications de l’entreprise)
  • Les partenaires intervenant au sein d’une entreprise pour lesquels on devait fournir un PC
  • Les partenaires intervenant en "remote" pour lesquels on devait fournir PC,accès VPN et token pour authentification forte

Windows to go doit dont être vu comme un véritable accélérateur des projets de déploiement de Windows 8.1, en particulier lorsque la migration doit être réalisé.

Quelques articles/bases à relire sur le sujet :

Quelques sessions Techdays pour réfléchir sur le sujet :

  • Windows 8 et Windows Server 2012: à deux c’est mieux! (SER210)
  • BYOD et Télétravail : Comment autoriser ces nouveaux scénarios avec Windows To Go, Hyper-V client et DirectAccess (CLI314)
  • Nouveautés de App-V 5.0 et intégration avec System Center 2012 (CLI309)

Histoire de montrer que c’est si simple, voilà la commande qui a été utilisée pour provisionner ma clé USB

clip_image002

Et l’utilisation du fichier généré sur mon futur poste de travail.

clip_image003

Et au premier logon sur le domaine, j’étais déjà en DirectAccess. La classe non? Geek oui mais Business focus cette fois.

 

Au passage, grand merci à Stanislas QUASTANA pour m’avoir fait découvrir la solution et la photo.

 

BenoîtS – Simple and Secure by Design but Business compliant

A KB list to keep in mind for your DirectAccess projects

Even if DirectAccess is now much more easier to deploy with Windows Server 2012, there still have some “cases” where Microsoft help is required. Jason Jones (Former Forefront MVP) updated his “Hot list” recently. Keep a bookmark on this list. This can save a lot of time during your next DirectAccess deployment.

 

BenoîtS – Simple and Secure by Design but Business compliant

Windows 2012 DirectAccess legacy client considerations

Let’s start this new year with a resolution : Correct previously published blog post including not accurate information (Thank you Alex ).

It might appear strange but with Unified Remote Access included with Windows Server 2012, Windows 7 DirectAccess Clients are considered as legacy clients. Legacy clients can connect to a Windows Server 2012 based DirectAccess infrastructure if we enable some compatibility features that I will describe in this blog post.

By default, A Windows Server 2012 based infrastructure is configured to operate in Kerberos proxy mode. In this default configuration, only Windows 8 clients can connect. In Kerberos Proxy mode, there is a single IPSEC Tunnel and certificates are not required. That’s a new DirectAccess deployment option available with Windows Server 2012. If you want to support Windows 7 clients, don’t forget to enable this checkbox :

ENABLEW7

When you activate the “Enable Windows 7 Clients computers to connect Via DirectAccess” checkbox, computer certificates become mandatory. That’s the minimum requirement to support Windows 7 Clients in a Windows Server 2012 based DirectAccess infrastructure.

Single-Site/Multiple site impact

Multi-site feature is introduced with Windows Server 2012. From user point of view a DirectAccess clients can have multiple entry point for a DirectAccess infrastructure. User can even select witch entry point to use. Unfortunately, this feature is only compatible with Windows 8. For this reasons, Windows 7 clients connecting to a multi-site DirectAccess infrastructure need a dedicated group policy that provide a single entry point for the DirectAccess infrastructure. As a conclusion, we cannot have Windows 7 and Windows 8 clients members of the same group in Multisite deployment (This possibe when Multi-site option is not enabled).

Windows 7 clients are considered as legacy clients. This means that :

  • They still rely on Teredo for DirectAccess
  • They need an IPSEC certificate to establish IPSEC tunnels
  • They will have their own dedicated DirectAccess configuration
  • They need a dedicated security group

From a DirectAccess point of view, there are two kind of clients,so there are two client-side GPO. This also means that there are two security group. You can find it with the Add-DAclient PowerShell command illustrated bellow :

ADDDACLIENTHELP

Great, but if we try to configure the “DownlevelSecurityGroupNameList” parameter with a single-site DirectAccess deployment, you will have the following error message :

ADDCLIENTERROR

In multisite deployments scenarios, we need separate security groups, one for Windows 8 clients and another one for legacy clients. Your Multi-site deployment can be composed of at least a single site. Legacy clients will only be able to connect to one entry point. Let’s switch our DirectAccess infrastructure to Multi-site :

ENABLE-DAMULTISITE

One important thing to notice with multi-site mode : you must separate Windows 7 and Windows 8 clients computers into different security groups because each operating system will have it’s own dedicated client-side GPO. Once we have at least one DirectAccess entry point we can configure it to support legacy clients with the Add-DAClient as illustrated bellow :

ADDCLIENTOK

By now, we have a Windows Server 2012 DirectAccess infrastructure witch is almost ready to accept legacy DirectAccess clients. Let’s have a look at the result of a Get-DAServer command :

GETDASERVER0

Server configuration seems to be fine. I have a certificate for IPHTTPS and an root certificate authority selected. With Windows 7, you still need certificates for DirectAccess. I would say that you always need certificates for DirectAccess because you always deploy it with Network Access Protection. But there is something bad with my configuration : The Teredo state parameter witch is disabled. When disabled (because no consecutive IPv4 public addresses or parameter disabled), client-side and Server-side GPO does not include Teredo configuration. With Windows Server 2012, this is no longer a problem.

If you configure your Internet-facing with a single IPv4 address, Teredo cannot be used (from the server point of view). Two public IPv4 addresses are always required on server side. Because Windows Server 2012 now allow to deploy DirectAccess behind a NAT device, Teredo is no longer a requirement.

Technically speaking you can enable it with the following PowerShell command, but its not mandatory :

ENABLETEREDO

And now, you remember why you need to create inbound rule for ICMP traffic . Now my configuration is fully operational from a technical point of view. But from user perspective there is something missing : The DirectAccess Connectivity Assistant 2.0. It’s included with Windows 8 and configured by the Client-side GPO but not for Windows 7, and more important, version 2.0 is required. This version is only supported when DirectAccess client is connected to a Windows Server 2012 based DirectAccess infrastructure. So don’t forget to create an additional client-Side GPO to configure the DirectAccess Connectivity Assistant for Legacy clients.

Edit : After some research and advices from Jason Jones, Teredo is a mandatory requirement for the Windows Server 2008 R2/UAG DirectAccess generation, not for Windows Server 2012. If Teredo is not operational for the DirectAccess client, IPHTTPS will be fine and even better with Windows Server 2012 based DirectAccess infrastructure. For many clients, having Microsoft box connected on LAN and Internet was not acceptable from a Security point of view. With Windows Server 2012, this is no longer a problem.

Thank you Jason.

BenoîtS – Simple and Secure by Design but Business compliant

UAG 2010 SP3 for 2013, what to expect for DirectAccess?

According to Forefront UAG team blog, UAG 2010 Service Pack 3 is in progress and should be available in the first quarter of 2013. Additional information are provided by a recent Ben Ari blog post.

image

 

According to ben Ari, support for Windows 8 clients connecting to a UAG 2010 SP3 in DirectAccess will be for SP3. This means that it’s not supported today with UAG 2010 SP2. Why? Because Windows 8 now includes the DirectAccess Connectivity Assistant as a part of the operating system.

 

BenoîtS – Simple and Secure by Design but business compliant.

Small tip for DirectAccess with Windows 8

With Windows 7, it was easy to know whether if DirectAccess was operational or not. We have the DirectAccess Connectivity Assistant illustrated bellow. The tool was included in the task bar and reachable quickly :

DAC

 

With Windows 8, if you use a brand new tablet (Not yet a surface for me ), just use Windows Charms to reach this interface and show properties of the “Workspace Connection”.

DAPROP1

 

But, many customers are experiencing Windows 8 on their existing laptops. In this situation, multiple clicks and mouse movements are required. In this case, be smart and just run “DAPROP.EXE”  from the start menu or from a PowerShell command line as illustrated bellow :

DAPROP2

 

Small tip but very useful.

 

Benoît – Simple and Secure by Design  but business compliant

Interesting DirectAccess scenario

DirectAccess can be used in many scenarios. With Windows 8 we will be able to offer new scenarios to customers. An interesting blog post of Jonas Blom show one of these new scenarios. Technical details are provided on his blog, so I will just develop the scenario you can apply it to.

 

Sometime Windows may crash (shits always append at the worst moment ). Most of the time this append when users does not have access to a IT support technician. In this situation, it would be a good idea to provide a previously prepared USB key with Windows To Go. The challenge will be to perform the domain join process in a secure way. We have multiple options :

  • Ask another colleague to get the ODJ package
  • User could be able to order and retrieve the ODJ package from any computer/smartphone connecting to a secure portal based on UAG

Once we get the file we can perform an automated domain join for the Windows to Go (Domain join, certificate provisioning and GPO). This solution provide a temporary solution until a IT technician can solve the problem.

 

BenoîtS – Simple and Secure by design but Business compliant.

Security Compliance Manager 3.0 Beta

Security Compliance Manager is a Microsoft solution Accelerator tool. The main objective of this tool is to provide security baselines for Microsoft operating systems  and applications and the ability to develop new security baselines. We will be able to use these baselines from a simple local Group Policy up to Desired Configuration Manager format.

 

The new version of the tool provide security baselines for :

  • Windows Server 2012
  • Windows 8
  • Internet Explorer 10
  • Office 2010

SCM3

 

If we take a closer look at Windows 8 or Windows Server 2012 nodes, we will find Windows 8 and Windows Server 2012 security guides. Great.

W8SECGUIDE

 

So this tool is a must to have in a Windows 7/8 deployment project.

 

Simple and Secure by Design but Business compliant

GPO pour Windows 8 et Windows Server 2012

Microsoft tiens à jour un fichier Excel référençant tous les paramètres de stratégies de groupe disponibles en fonction des systèmes d’exploitation. La dernière version de ce tableau inclus donc Windows 8 et Windows Server 2012. Celui-ci est disponible à l’emplacement suivant :

 

Cette nouvelle version précise maintenant :

  • Le niveau de schéma / domaine nécessaire
  • S’il est nécessaire de redémarrer/ fermer la session pour que le paramétrage prenne effet

 

Une mine d’information à conserver précieusement.

 

BenoîtS – Simple and Secure by Design but Business compliant