Arquivo

Archive for the ‘Power Shell’ Category

Sobre DNS Policies–Windows Server 2016–volume 7–Redirecionamento por horário

14 de agosto de 2017 Deixe um comentário

Saudações,

E hoje chegamos ao último volume da série sobre DNS Policies no Windows Server 2016. Para aqueles que ainda não viram, segue abaixo o link para os 6 últimos posts publicados:

Sobre DNS Policies – Windows Server 2016 – volume 01 – Teoria

Sobre DNS Policies – Windows Server 2016 – volume 02 – Balanceamento de Carga

Sobre DNS Policies – Windows Server 2016 – volume 03 – Gerenciamento de Tráfego de Rede baseado em Geo-Localização

Sobre DNS Policies – Windows Server 2016 – volume 04 – Split Brain DNS e Selective Recursion Control

Sobre DNS Policies – Windows Server 2016 – volume 05 – DNS Filtering

Sobre DNS Policies – Windows Server 2016 – volume 06 – Foresincs

Vamos hoje falar sobre redirecionamento por horário, ou seja, direcionar requisições DNS baseado na hora do dia.

Exemplo – Tenho uma farm de servidores de aplicação com  4 nodes e a partir de hoje, das 16 até as 18 horas terei que parar dois desses nodes para manutenção. Neste caso, as requisições serão encaminhadas somente para os dois nodes que estiverem ligados.

Exemplo 2 – Na minha farm de 4 nodes tenho 2 servidores com mais poder de processamento e os outros 2 têm uma absorção de carga menor. A região atendida pelos servidores de menor processamento irá receber uma carga gigantesca de acessos devido a um determinado evento que irá requerer o suporte a um numero muito maior de acessos aos quais essas máquinas podem receber. Em situações como esta podemos criar uma política em nosso DNS Server para que as requisições sejam direcionados em maior parte aos nodes com maior poder de processamento.

Vamos ilustrar novamente nosso ambiente para este post usando o mesmo de outros volumes desta série:

image

No desenho acima temos os servidores de Fortaleza e Belo Horizonte. Estes equipamentos não têm o mesmo poder de processamento que os alocados em São Paulo e Rio de Janeiro. A empresa promoverá uma ação de marketing que duplicará o numero de requisições por todas as filiais e você nota que CE e BH estão com a performance comprometida. Esta campanha ocorrerá pelos próximios dias das 15 até as 20 horas

Neste mini laboratório, vamos fazer com que o tráfego das subnets de CE e BH sejam direcionados em sua maioria para os servidores de SP e RJ.

Para tanto iremos usar o comando abaixo:

Add-DnsServerQueryResolutionPolicy -Name MktPeakTime -Action ALLOW -ZoneScope ‘SP_ZoneScope,4;RJ_ZoneScope,4;FOR_ZoneScope,1;BH_ZoneScope,1’ –TimeOfDay ‘EQ,15:00-20:00’ -ZoneName uilson.net

No comando acima eu criei uma política chamada “MktPeakTime” que distribuirá a carga das requisições aos servidores de aplicação da seguinte forma:

São Paulo e Rio de Janeiro – 40% cada

Fortaleza e Belo Horizonte- 10% cada

Relembrando – Foi criado um zone scope para cada localidade e o registro DNS de cada servidor criado no escopo da referida localidade. Se você não se lembra como criar escopos de zona, acima deste post você terá os links para os volumes anteriores desta série com o procedimento detalhado.

Quem leu os volmes anteriores desta série também sabe que os numeros definidos ao lado de cada zone escope caracteriza a quantidade de requisições que será enviada a um determinado servidor, por exemplo, no escopo de zona de São Paulo e Rio de Janeiro eu coloquei o valor “4”, ou seja, a cada 10 requisições, 4 irão para SP, 4 irão para o Rio, 1 para CE e 1 para BH. Este processo tb está bem explicado na série.

E assim finalizamos mais uma série de posts neste espaço. A partir de agora, vamos focar em Web Application Firewall do Azure com um post escrito pelo Solution Architect Diogo Bacelar que será postado aqui. Também iremos fazer um webcast em breve sobre este tema. Aguardem.

Espero que o tema possa ajuda-lo em suas tarefas diárias!

Abraços

Uilson

Anúncios

Sobre DNS Policies–Windows Server 2016–volume 04–Split-Brain DNS e Selective Recursion Control

29 de maio de 2017 Deixe um comentário

Saudações,

Peço desculpas pela demora na publicação do quarto volume desta série. Estive em dias de muito trabalho e alguns percalços pessoais. Mas de qualquer forma vamos ao conteúdo de hoje – Split-Brain DNS.

A quem está chegando agora, abaixo os links para os outros 3 posts da série:

Sobre DNS Policies – Windows Server 2016 – volume 01 – Teoria

Sobre DNS Policies – Windows Server 2016 – volume 02 – Balanceamento de Carga

Sobre DNS Policies – Windows Server 2016 – volume 03 – Gerenciamento de Tráfego de Rede baseado em Geo-Localização

De acordo com a teoria que coloquei no volume 1 desta série, com o recurso de Split-Brain DNS os registros são divididos em diferentes escopos de zona no mesmo servidor DNS. Os clientes DNS recebem uma resposta baseado onde de fato estes clientes estão – internos ou externos. Este recurso pode ser configurado em zonas integradas ao AD ou para DNS Standalone Servers.

Também iremos criar políticas de seletive recursion para mitigação e vulnerabilidades em ambientes como este.

Em tempo – Este laboratório foi criado em meu ambiente tendo como base o laboratório do artigo Split-Brain DNS Deployment Using Windows DNS Server Policies do pessoal do Networking Blog da Microsoft. Como não tinha montado nada semelhante, me espelhei no conteúdo deles para criar o meu. Para aqueles que notarem a semelhança do meu lab com o deles, fica aqui registrado que a idéia inicial é do link citado e deixo a eles o devido crédito.

Vamos então a parte prática!

Imaginemos que tenho um site que deverá ser acessado tanto por usuários internos quanto externos. Esse possui informações de produtos da minha empresa que a equipe compartilha com parceiros externos.

Meu DNS posui duas interfaces, uma interna e outra externa

Interna – IP 10.10.1.100

Externa – IP 200.185.0.55

Meu servidor de aplicação interno responde pelo IP 10.10.1.10 e meu servidor de aplicação externo responde pelo IP 66.56.40.10 (lembrando que estes são IP´s fictícios, os IP´s que usei no laboratório do meu ambiente são outros e aqui fica só para ilustração)

Objetivo – Usuários na minha rede interna, irão acessar o site produtos.uilson.net do back-end Server interno e usuários externos irão acessar o back-end server externo, conforme o desenho abaixo:

 

image

Com o cenário definido, vamos ao procedimento que torna tudo isso real:

Vamos começar criando um zone scope para o acesso interno, ou seja, os acessos que virão pela interface 10.10.1.100:

Add-DnsServerZoneScope –ZoneName “uilson.net” –Name “InternalAccess”

Iremos criar o zone scope somente para o acesso interno, ficando o acesso externo direto no zone uilson.net no escopo padrão.

Agora vamos criar criar os registros para os acessos interno e externo, sendo que, para o acesso interno, iremos cria-lo já dentro do zone scope que acabamos de criar:

Registro de acesso externo – Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “produtos” –IPv4Address “66.56.40.10”

Registro de acesso interno – Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “produtos” –IPv4Address “10.10.1.10” –ZoneScope “InternalAccess”

Agora que temos o zone scope e os registros criados, vamos à política que irá diferenciar acessos internos e externos:

Add-DnsServerQueryResolutionPolicy –Name “SplitBrainPolicy” –Action Allow –ServerInterface “eq,10.10.1.100” –ZoneScope “InternalAccess,1” –ZoneName uilson.net

Feito!!!! Temos agora nosso ambiente direcionando as requisições internas ao site produtos.uilson.net para o back-end server interno e os acessos externos indo diretamente para o servidor externo, conforme definido no escopo inicial.

Poderiamos dizer que temos o trabalho finalizado, certo? Errado! Deixar o ambiente simplesmente como está pode, em alguns casos, criar uma vulnerabilidade que precisa ser mitigada.

Lembre-se que neste exemplo temos um DNS Server resolvendo nomes para recursos internos e externos. O que pode ocorrer aqui é que requisições internas e externas passem fazer queries por endereços de internet, podendo expor o ambiente a um Reflection Attack ou DNS Amplification Attack – um DDoS.

Neste caso, as resoluções recursivas para nomes externos precisa ser bloqueada e para isso criaremos outra política que vem a ajudar na mitigação desta vulneravbilidade:

image

Desenho original do link: https://blogs.technet.microsoft.com/networking/2015/05/12/split-brain-dns-deployment-using-windows-dns-server-policies/

O link que postei sobre DDoS DNS Amplification Attack pede que a funcionalidade da recursiva seja desasbilitada no servidor DNS. Neste caso, vamos desabilitar este recurso que será usado somente para requisições internas.

Desabilitando a recursiva: Set-DnsServerRecursionScope –Name . –EnableRecursion $False

No comando acima, a recursiva está sendo desabilitada para o escope default (tudo que está em uilson.net).

Agora vamos habilitar a recursiva somente para um escopo de clientes internos:

Add-DnsServerRecursionScope –Name “RecursionInternalClients” –EnableRecursion $True

Agora vamos criar a política que irá permitir a recursiva somente para clientes internos;

Add-DnsServerQueryResolutionPolicy –Name “SplitBrainRecursionInternal”-Action ALLOW –ApplyOnRecursion –RecursionScope “RecursionInternalClients” –ServerInterfaceIP “EQ,10.10.1.100”

Agora temos nosso ambiente executando dentro de uma melhor prática para o recurso do Split-Brain DNS.

Espero mais uma vez que o conteúdo possa ser útil e não perca o volume 5 desta série. Iremos falar sobre Filtering com DNS Policies.

Abraços

Uilson

Usando PowerShell para corrigir vulnerabilidades via chave de registro

28 de março de 2017 Deixe um comentário

Saudações,

O post de hoje visa ajudar os administradores de rede e analistas de segurança no momento em que precisam planejar a mitigação e correção de alguns tipos de vulnerabilidades em estações de trabalho via chave de registro.

Normalmente, a empresa dispõe de uma ferramenta que faz o scan, encontra, classifica e exibe em relatório quais vulnerabilidades uma ou mais estações têm e como corrigir.

Agora, imaginem uma determinada vulnerabilidade a ser corrigida em diversas estações? Como fazer?

Uma forma é usar o comando PSEXEC do SysInternals para executar este trabalho. A partir de um arquivo de lote eu uma simples variável (%1), o problema pode ser resolvido. Entretanto, como nosso foco é disseminar todas as formas de otimização de tarefas com PowerShell, queria mostrar como o usei para resolver um problema num case real.

Recebemos a notificação de que uma determinada área da empresa precisava ter todas as estações com o parâmetro de SMB Signing habilitado. Este parâmetro criptografa todo fluxo de informações entre a estação e um file server, num processo semelhante ao do SMB Encryption, feito no Windows Server 2012 R2, entretanto, o processo aqui visa proteger estações com Windows 7 Professional.

Não existe uma console administrativa ou um processo via GUI para tal, portanto, como falei, ou você o faz via PSEXEC do SysInternals ou, no nosso caso, usando PowerShell.

O processo consiste na criação de uma chave de registry que vai habilitar o SMB Signing na estação:

Chave a ser criada – EnableSecuritySignature

Tipo – DWORD

Valor – 1

Endereço – HKLM\System\currentcontrolset\services\lanmanworkstation\parameters

Comando PowerShell a ser usado:

Invoke-Command -cn computername {New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\LanManWorkstation\Parameters" -Name EnableSecuritySignature -Value "1" -PropertyType DWORD -Force | Out-Null}

No comando acima, criamos a chave de registry remotamente em uma estação. Estou considerando aqui que o administrador tem amplo acesso ao equipamento remoto. Entretanto você pode se deparar com um ambiente em que seu usuário não tenha acesso àquela estação (ou grupo de estações) e precise declarar seu usuário. Neste caso você pode entrar com o seguinte comando:

$Auth = Get-Credential dominio\usuario
Invoke-Command -cn computername -Cred $Auth {New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\LanManWorkstation\Parameters" -Name EnableSecuritySignature -Value "1" -PropertyType DWORD -Force | Out-Null}

Ao executar este comando, você será solicitado a entrar com o usuário e senha com permissão de acesso na estação:

image

Ao entrar com as credenciais necessárias, o script faz criação da chave com o valor conforme citado acima.

Você pode conferir se a chave foi mesmo criada usando comando abaixo:

Invoke-Command -cn computername {Get-Item -Path "HKLM:\System\CurrentControlSet\Services\LanManWorkstation\Parameters"}

Abaixo o resultado:

image

Agora vamos considerar o fato de termos uma lista de estações a serem corrigidas. Como fazer? Você pode usar o PowerShell ISE e criar um script para isso, usando laços do comando For EACH:

ForEach ($WKS in (Get-Content C:\ComputerList.txt)){
    Invoke-Command -cn $WKS {New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\LanManWorkstation\Parameters" -Name EnableSecuritySignature -Value "1" -PropertyType DWORD -Force | Out-Null}
    }

Antes de executar o script acima, você precisa preencher o TXT citado na primeira linha e preencher com os nomes das estações. O processo será realizado em cada uma delas.

Espero que o conteúdo seja útil e ajude no seu dia a dia.

Abraços

Uilson

Criação e adequação em contas de parceiros externos via PowerShell

6 de março de 2017 Deixe um comentário

Saudações,

Neste primeiro post de 2017 vou compartilhar com vocês um trabalho feito a uns dias atrás na empresa onde trabalho.

Cenário – Uma consultoria foi contratada para dar suporte a uma aplicação on-premisses da empresa. O contrato tem duração da data de hoje até 31 de dezembro de 2017. Como se trata de uma solução de ERP instalada em um de nossos servidores, ficou acertado que 4 pessoas desta consultoria deveriam ter acesso como Administrator neste servidor para as devidas manutenções, migrações, etc. Entretanto, não posso simplesmente criar 4 novas contas no domínio e coloca-las como administrator de um servidor. Alguns critérios tiveram que ser seguidos para que as normas de segurança definidas pelo nosso time de Cyber Security não fossem quebradas.

Vou neste post mostrar como fiz, usando alguns exemplos em meu ambiente de laboratório.

Descrição do ambiente:

Domínio: uilson.net

Nome da empresa que vai alocar consultores: 123 Consultoria SA

Passos a serem seguidos na tarefa:

1. Criar uma OU específica para provedores externos

New-ADOrganizationalUnit -Name "ExternalProviders" -Path "DC=uilson,DC=net" -Description "OU para contas de usuários externos"

Acima criei a OU “ExternalProviders” que irá abrigar as OU´s de todos os meu parceiros externos que alocam pessoas em minha organização

2. Criar uma OU dentro daquela criada no item 1 descrevendo o nome da empresa

New-ADOrganizationalUnit -Name "123Consultoria" -Path "OU=ExternalProviders,DC=uilson,DC=net" -Description "OU para contas da 123 consultoria SA"

Acima criei a OU “123Consultoria” que vai ficar dentro da OU “ExternalProviders”.

3. Criar as contas de usuário já dentro dessa nova OU, definindo a senha provisória, solicitando alteração de senha no log on do usuário e seguindo as melhores práticas de segurança definir que cada conta será desabilitada em 31/12/2017

New-ADUser -Name "José da Silva 123 Consultoria" -SamAccountName jose.silva -UserPrincipalName jose.silva.ext@uilson.net -DisplayName "Jose da Silva – consultor externo" -Description "Usuário Consultor da 123 Consultoria" -Title "Jose da Silva – 123 Consultoria" -Enable $true -ChangePasswordAtLogon $true -AccountPassword (ConvertTo-SecureString "!!!zaq12wsx" -AsPlainText -force) -PassThru -Path "OU=123Consultoria,OU=ExternalProviders,DC=uilson,DC=net" | Set-ADAccountExpiration -DateTime "12/31/2017"

O comando acima cria o usuário “jose.silva” com uma senha pré-definida que deverá ser alterada no momento do primeiro log on do usuário, a localização da conta (dentro das OU´s que criamos anteriormente) e para casos como este de usuários externos, definição da data de expiração da conta, ou seja, o projeto ao que este usuário está alocado deverá se encerrar até 31/12/2017, data qual a conta será desabilitada.

O mesmo poderá ser repetido com outros usuários desta mesma empresa que vierem a integrar o quadro de consultores externos.

Agora vamos supor que o gestor do contrato com a “123 Consultoria” lhe peça pra listar a data de expiração da conta do consultor “José da Silva”, apenas para ter certeza de que a configuração de expiração da conta bate com a data final do contrato:

get-aduser jose.silva -Properties * | Select-Object Name,SamAccountName,AccountExpirationDate

No comando acima você receberá o seguinte resultado:

image

Vimos na imagem acima que a criação do usuário foi feita de forma a respeitar os processos de segurança da informação da empresa e também certifica que, em 31/12/2017 a conta do usuário listado não mais funcionará a partir da meia noite do dia citado.

Agora seu gerente quer saber quais são os recursos da “123 Consultoria” alocados na empresa. Sabendo qual a OU em que esses usuários estão criados você já pode fazer uma linha de comando mais elaborada:

Get-ADUser –Filter * –SearchBase “OU=123Consultoria,OU=ExternalProviders,DC=uilson,DC=net” | Select-Object Name,SamAccountName

Executando o comando acima você tem o resultado abaixo

image

Você pode mandar essas informações para seu gerente no corpo do email ou simplesmente  envie para um arquivo TXT e trate depois em um excel, basta incluir “> arquivo.txt” no fim da linha de comando exemplificada acima.

Depois de alguns dias, você recebe uma notificação de sua gestão dizendo que, pela complexidade do projeto no qual a 123 Consultoria está atuando, o tempo de contrato foi extendido, ou seja, não mais acabará em 31/12/2017 e sim em 31/12/2018. Dessa forma, os acessos da equipe alocada precisa continuar em funcionamento após a primeira data estipulada.

Neste caso você não precisa efetuar a alteração conta por conta. Simplesmente aplique o update para toda a OU “123Consultoria”:

O primeiro comando fará com que todos os usuários da 123 Consultoria tenham sua data de expiração alterada para 31/12/2018:

Get-ADUser -Filter * -SearchBase "OU=123Consultoria,OU=ExternalProviders,DC=uilson,DC=net" | Set-ADAccountExpiration -DateTime "12/31/2018"

Agora você pode tirar a prova para se certificar que a alteração foi feita usando o comando abaixo:

Get-ADUser -Filter * -SearchBase "OU=123Consultoria,OU=ExternalProviders,DC=uilson,DC=net" -Properties * | Select-Object Name,SamAccountName,AccountExpirationDate

Os comandos acima trazem o resultado na figura abaixo:

image

Com base na imagem acima, e tendo em mente os usuários externos da empresa, vamos para nosso último laboratório deste post. Depois de alguns meses de trabalho, o gerente da equipe de desenvolvimento entendeu que a consultora Hele de Jesus (userid – helena.jesus) desempenha um excelente trabalho no suporte ao produto ERP da empresa e lhe faz uma proposta de contratação como funcionária efetiva. A mesma aceita e agora vai fazer parte do quadro de funcionários.

Com todas as formalidades em dia, você da área de infra estrutura recebe uma solicitação para adequar o usuário de Helena ao padrão da empresa, ou seja, tem que mover a conta para a OU “DevTeam” que fica dentro de “ITDept”, mudar as descrições da conta e remover a data de expiração da conta, afinal, Helena agora é funcionária nossa!

Dessa vez vamos usar o editor de script´s PowerShell ISE, lembrando que para abrir este editor você apenas precisa digitar “ise” no prompt de comando do PowerShell. Como vamos rodar vários comandos, resolvi definir uma varíavel para o usuário “helena.jesus”. Veja como ficou abaixo:

$conta = "helena.jesus"
Get-ADUser $conta | Clear-ADAccountExpiration
Get-ADUser $conta |  Move-ADObject -TargetPath "OU=DevTeam,OU=ITDept,DC=uilson,DC=net"
Set-ADUser $conta -DisplayName "Helena de Jesus" -Description "Desenvolvedora ITDept" -Department "IT Department" -UserPrincipalName "helena.jesus@uilson.net" -Title "Helena de Jesus"

O script acima fica assim no ISE:

image

Após execução do Script, ainda vemos que um atributo permanece inalterado, conforme image abaixo:

image

O campo “Name” não foi alterado, permanece como “Helena de Jesus 123 Consultoria”. Isso ocorre porque este campo fica na propriedade DistinguishedName do usuário “helena.jesus”. Para que este campo seja renomeado corretamente, é preciso alterar o objeto “CN” do DistinguishedName. Abaixo mostro dois comandos, sendo o primeiro para listar o DistinguishedName do usuário e o segundo mostro como fazer a alteração necessária:

get-aduser helena.jesus | Select-Object distinguishedname

Rename-ADObject -Identity "CN=Helena de Jesus 123 Consultoria,OU=DevTeam,OU=ITDept,DC=uilson,DC=net" -NewName "Helena de Jesus"

image

Na tela acima você vê os resultados da aplicação dos comandos.

Agora o objeto aparece corretamente no AD:

image

Além disso, vemos que os procedimentos adotados removeram a data de expiração da conta:

image

Neste post vimos como configurar acessos no Active Directory para consultores externos seguindo as melhores práticas de segurança e todos os

Espero que possa ser útil no dia a dia de vocês.

Quero pedir desculpas pela demora em postar neste ano. Estou estudando para as provas da CompTIA. Vou começar com Cloud Essentials (o livro vc pode comprar no link no lado superior direito). Depois vou estudar Security+, depois vem Cloud+ e CSA (Cyber Security Analyst) – você pode ter uma visão geral de todas essas certificações em https://certification.comptia.org/pt/certificações

Seguiremos este ano com posts voltados a todo tipo de otimização de tarefas com PowerShell, Web Application Proxy e Azure AD Application Proxy.

Abraços

Uilson

DNS Server–Configurando a Global Query Block List via PowerShell

28 de novembro de 2016 Deixe um comentário

Saudações,

Aos que estão acompanhando a nossa série de artigos sobre otimização de tarefas com PowerShell, hoje vou fazer um “adendo” ao 5o. post – Otimização de tarefas com PowerShell – DNS Server.

Um dos pontos de atenção nas empresas nos últimos anos é a configuração do acesso ao proxy usando o registro wpad do DNS Server. O mesmo pode ser configurado via DHCP também, mas, deixarei isso para um próximo post.

Por questões de segurança, desde o Windows Server 2008, o registro WPAD e ISATAP (registro que auxilia na comunicação de dipsositivos IPv4 e IPv6), estão bloqueados para uso. Entretanto, o administrador do ambiente pode escolher entre:

1. Ativar um desses registros – via PowerShell com via linha de comando DNSCMD

2. Desativar a Global Query Global List

Um exemplo de como configurar essa funcionalidade via linha de comando foi dada no meu artigo de 16/07/2013 onde citei a configuração do WPAD via DNS usando o DNSCMD.

No nosso caso em que estamos destrinchando o PowerShell para nosso dia a dia, estou deixando aqui um exemplo prático de como usar o comando Get-DnsServerGlobalQueryBlockList e Set-DnsServerGlobalQueryBlockList

No primeiro exemplo vamos listar os hosts que estão bloqueados pelo Global Query Block List:

Get-DnsServerGlobalQueryBlockList

Em seguinda vamos liberar o uso do registro WPAD:

Set-DnsServerGlobalQueryBlockList –List “isatap” –Passthru

O comando acima vai reconstruir a Global Query Block List deixando bloqueado somente o registro “ISATAP”.

Agora vamos reconstruir a Global Query Block List inclindo, além do ISATAP, o WPAD também;

Set-DnsServerGlobalQueryBlockList –List “wpad, isatap” –Passthru

Se você quiser, também pode desabilitar a Global Query Block List (o que não recomendo):

Set-DnsServerGlobalQueryBlockList –Enable $False

E para habilitar de novo:

Set-DnsServerGlobalQueryBlockList –Enable $True

Abaixo um exemplo prático de como você visualiza todos os comandos citados:

image

No próximo post quero voltar ao Web Application Proxy, mostrando como configurar seu ambiente para aplicações com autenticação Kerberos.

Fique ligado aqui no blog e na fan page – facebook.com/usouzajr.

Abraços

Uilson

Otimizando tarefas com PowerShell–Administração DNS Server

16 de novembro de 2016 Deixe um comentário

Saudações,

Chegamos hoje ao quinto artigo da série “Otimizando tarefas com PowerShell”. Dessa vez vamos falar sobre administração do DNS.

Para quem ainda não viu, abaixo os 4 primeiros posts publicados:

1. Otimizando tarefas com PowerShell – Administrando Active Directory Users and Computers

2. Otimizando tarefas com PowerShell – Implementação e administração Web Application Proxy

3. Otimizando tarefas com PowerShell – Implementando e administrando AD Federation Services

4. Otimizando tarefas com PowerShell – Implementando e administrando Internet Information Services – IIS

Publiquei tb um artigo no TechNet Wiki sobre Administração do AD Directory Services via PowerShell com coneitos mais avançados que o primeiro desta série.

Podemos levar em consideração o ambiente fictício dos últimos 4 posts:

Domínio – uilson.net

Vamos considerar um ambiente básico onde o DNS está junto com o AD e também considerar a instalação de um novo servidor de resolução de nomes com as configurações básicas, criação de zones, hosts, etc.

1. Instalando e configurando a Role via Powershell:

A principio, todo domain controller já vem com o DNS Server instalado. Neste caso vamos simular um segundo DNS Server sendo instalado e que será integrado ao nosso Active Directory.

Como já mostrado em outros artigos desta série vamos usar o cmdlet “Add-WindowsFeature” ou “Install-WindowsFeature”:

Install-WindowsFeature DNS –IncludeManagementTools

No comando acima eu pedi a inclusão da console de gerenciamento, mas, vamos mostrar aqui como administrar seu DNS sem usa-la.

2. Configurando forward, reverse e stub zones (primárias)

Sabemos que podemos ter dois tipos de forward zone no DNS – Com integração no AD (que é o tipo mais comum para redes internas, tanto que um servidor promovido a Domain Controller já instala a role do DNS junto) e sem integração, ou seja, aquele DNS Server que poderá ser usado para resolução de nomes externos

Para criar uma Forward Lookup Zone integrada ao AD – Add-DnsServerPrimaryZone -Name "uilson.net" -ReplicationScope "Forest" –PassThru 

O comando acima vai criar um forward zone primária integrada ao AD, ou seja, todas as informações que forem criadas nesta zona serão armazenadas no base do AD.

Para criar uma Forward Lookup Zone sem integração com o AD – Add-DnsServerPrimaryZone -Name "uilson.net" -ZoneFile "uilson.net"

O Zone File armazena todas as configurações e registros criados neste forward lookup zone, uma vez que não há integração com o AD. Esse arquivo fica na pasta c:\windows\system32\dns do seu servidor DNS. De forma que, para zonas sem integração com o AD é interessante manter um backup destes arquivos para imediato restore em caso de necessidade.

Agora vamos ver como criar as zonas reversas, ou seja, aquelas que fazem a resolução IP-Nome. Abaixo os comandos que você deve usar para esta finalidade:

Para criar uma Reverse Lookup Zone integrada a seu AD – Add-DnsServerPrimaryZone -NetworkID "10.1.1.0/24" -ReplicationScope "Forest"

Para criar uma zona reversa sem integração com o AD – Add-DnsServerPrimaryZone -NetworkID 10.1.1.0/24 -ZoneFile "0.1.10.in-addr.arpa.dns"

Outra tipo de zone que você pode criar no DNS Server é a Stub Zone. Ela facilita a resolução de nomes em ambientes complexos. Os endereços da filial A serão mais rapidamente resolvidos pela filial C que se conectam via WAN em distâncias grandes.

Como os exemplos acima, você poderá criar uma stub zone de forma integrada, não integrada e também uma reverse stub zone.

Para criar uma stub zone não integrada com o AD – Add-DnsServerStubZone -Name "filialrj.uilson.net "192.168.1.1" -PassThru -ZoneFile "filialrj_uilsonnet.dns"

No exemplo acima criei uma stub zone não integrada ao AD para uma filial no Rio de Janeiro dentro da arvore uilson.net.

Com base no cenário do exemplo acima, segue o comando para criar uma stub zone integrada ao AD:

Add-DnsServerStubZone -Name "filialrj.uilson.net" -MasterServers 192.168.1.1 -PassThru -ReplicationScope "Forest"

Você também pode criar uma reverse stub zone – Add-DnsServerStubZone -NetworkId 10.10.1.0/24 -MasterServers 192.168.1.1 -PassThru -ReplicationScope Forest – neste exemplo, integrada ao AD.

3. Criando Zonas Secundárias

Para criação de uma Reserve Lookup Zone integrada ao AD em um DNS Secundário, ou seja, uma zona secundária que irá receber informações de uma zona primária criada conforme mostramos no item 2 deste post, você deve usar o comando abaixo:

Integrada ao AD – Add-DnsServerSecondaryZone –Name “uilson.net” –ReplicationScope “Forest” –MasterServers 10.10.1.1

Associada a um Zone File – Add-DnsServerSecondaryZone -Name "uilson.net" -ZoneFile "uilson.net" -MasterServers 10.10.1.1

4. Configurando propriedades dos zones

DNS Forwarder e DNS Conditional Forwarder

Um dos pontos a serem configurados em uma zona de encaminhamento no DNS Server é o serviço de Forwarder.

O servidor DNS que você configura como Forwarder irá receber as requisições de resolução de nomes externas encaminhadas do seu DNS Interno.

Neste caso, temos duas maneiras de configurar a lista de Forwarders:

1. Set-DnsServerForwarder – Este comando irá começar a lista de IP´s externos do zero, ou seja, usado em situações em que você acabou de instalar e configurar seu DNS Server.

2. Add-DnsServerForwarder – Este comando irá adicionar IP´s a uma lista de forwarders já existente.

OBS: Se você usar o comando Set-DnsServerForwarder em uma lista de forwarders já existente, você vai “zerar” a lista e usar aquele IP que o comando definir no momento em que for executado, portanto, cuidado!

Para criar um nova lista de forwarders – Set-DnsServerForwarder -IPAddress "192.168.0.1" –PassThru

Para adicionar um IP a uma lista de forwarders – Add-DnsServerForwarder -IPAddress 192.168.0.1 –PassThru

Outra configuração interessante a ser feita é a do Conditional Forwarder, funcionalidade que foi introduzida a partir do Windows Server 2003. Um Conditional Forwarder permite a resolver nomes de um rede privada ou externa, ajudando a acelerar a resolução. Quando o DNS recebe a requisição de um cliente para resolver o nome de um host que não está em sua zona autoritativa, o processo começa a partir do root name do servidor e continua até a resolução do nome. Quando você configura um Conditional Forwarder, o DNS local encaminhará a requisição para a zona autoritativa do domínio de destino.

De igual forma aos exemplos mostrados neste post, você pode criar uma zona Conditional Forwarder de forma integrada a seu AD Loal ou não.

O link abaixo fala de Zonas Conditional Forwarder para Windows Server 2003, mas, o conceito explicado pode ser usado em qualquer situação a frente, ou seja, Windows Server 2008, 2012, 2016, etc:

https://support.microsoft.com/en-us/kb/304491 – Conditional Forwarding in Windows Server 2003

Agora vamos a prática:

Para criar uma Conditional Forwarder Zone integrada a seu AD: Add-DnsServerConditionalForwarderZone -Name "contoso.com" -ReplicationScope "Forest" -MasterServers 172.16.10.1

Para criar uma Conditional Forwarder Zone sem integração com seu AD: Add-DnsServerConditionalForwarderZone -Name "contoso.com" -MasterServers 172.16.10.1 –PassThru

Root Hints

Para adicionar um endereço a minha lista de root hints – Add-DnsServerRootHint -NameServer "root.contoso.com" -IPAddress 172.23.90.128

Zone Transfers

Quando você configura uma zona secundária, precisa habilitar a transferência dos dados da primária.

Para habilitar o zone transfer – Start-DnsServerZoneTransfer -Name "uilson.net"

DNS Policy

Ao invés de deixar um ou outro exemplo sobre DNS Policy, vou colocar o link pra um artigo que escrevi em 24/06/2015 – Nele mostrei um cenário completo onde você pode configurar o DNS Policy. Essa feature vem a partir do Windows Server 2016. Clique aqui para ler o post.

Tem muito mais

Os exemplos citados acima são apenas alguns daqueles que podem ser usados para configurar e administrar seu DNS Server via PowerShell. Muitos outros existem e vou deixar um link aqui com todos os cmdlets do DNS Server com exemplos práticos.

5. Criação de Registros

A criação de registros em uma zona é feita de forma automática. Entretanto, imagine a situação em que você precise registrar um host que aponte a um web server, um application server ou back-end server.

Vamos ver abaixo como criar um registro A que venha de encontro a esse propósito.

Cenário: Temos um web server no domínio uilson.net. O mesmo tem uma aplicação que deverá ser publicada e usada internamente ou externamente. No IIS eu configurei esta aplicação com o host header sistemas.uilson.net. O IP deste servidor é 10.10.1.50. Veja abaixo como este registro é criado:

Add-DnsServerResourceRecord -ZoneName "uilson.net" -A -Name "sistemas" -IPv4Address "10.10.1.50"

Nesse link você encontra exemplos práticos de como criar os demais tipos de registro (AAAA, CNAME, etc) – https://technet.microsoft.com/en-us/library/jj649925.aspx

6. Consultas

Neste ponto em que nosso laboratório já está totalmente configurado. Vamos ver os comandos que você pode usar para verificar as configurações de seu DNS Server:

Get-DnsServer

Este comando traz todas as configurações de seu DNS Server. Voce pode usar também o parâmetro –computername para pegar informações remotamente.

image

Get-DnsServerZone

Este comando traz todas as Zones criadas no seu DNS Server. Voce pode usar também o parâmetro –computername para pegar informações remotamente.

image

Get-DnsServerResourceRecord -ZoneName uilson.net

O comando acima lista todos os registros na zone uilson.net:

image

Estas são apenas algumas das muitas consultas que podem ser feitas. No item abaixo você encontra o link que poderá ver exemplos práticos de todas elas.

7. Referências para estudo

Neste link você encontra todos, exatamente todos os comandos DNS para PowerShell com exemplos práticos – https://technet.microsoft.com/en-us/library/jj649850.aspx

8. Conclusão

Neste post mostrei para você exemplos práticos de instalação, configuração e administração do DNS Server via PowerShell.

Espero que o conteúdo possa ser útil e lhe ajudar em suas tarefas diárias.

Abraços

Uilson

Otimizando tarefas com PowerShell–Implementando e administrando Internet Information Services–IIS

28 de julho de 2016 Deixe um comentário

Saudações,

Hoje vamos entrar no quarto post da série “Otimizando Tarefas com PowerShell”. Pra quem está chegando agora e não conhecia o blog Microsoft Space, estou trabalhando em uma série de artigos relacionados a PowerShell, conforme abaixo:

1. Otimizando tarefas com PowerShell – Administrando Active Directory Users and Computers

2. Otimizando tarefas com PowerShell – Implementação e administração Web Application Proxy

3. Otimizando tarefas com PowerShell – Implementando e administrando AD Federation Services

Vamos continuar usando o ambiente fictício criado nos posts anteriores.

Imagine que você precisa instalar o IIS em uma farm de servidores que vão estar balanceando a carga. Vc teria habilitar a feature em um por um, mesmo usando o Server Manager de um único servidor para isso. Vamos mostrar a seguir como fazer de forma otimizada e mais rápidamente. Ou então você vai analisar um ambiente em que o IIS esteja em um Server Core ou até mesmo Nano Server.

Algo importante que esqueci de mencionar no segundo e terceiro artigos da série é que os comandos de instalação de roles e features estão armazenados no módulo ServerManager do PowerShell, portanto, se ao tentarem fazer o teste com os comandos citados nos artigos anteriores vocês receberem alguma mensagem de erro, façam o carregamento do módulo conforme abaixo:

Import-Module ServerManager

1. Instalando o IIS:

Como vocês já devem saber, o IIS pode ser instalado em sua totalidade, ou seja, com todas as features ou somente aquelas que você precisar para o proposito da sua infra.

Com o comando abaixo você instala o IIS com todas as features do role:

add-windowsfeature web-server –includeallsubfeature

Recomendo fortemente aquilo que sempre falo em post´s neste blog e em outros espaços, além das palestras e webcasts que entreguei; faça um planejamento prévio, converse com sua área de desenvolvimento para entender o que você vai precisar do seu IIS, qual o tipo de aplicação que irá hospedar e as features exatas que você vai precisar.

Para sabermos quais as features do IIS disponíveis, podemos usar o comando get-windowsfeature parametrizando pelas funções do IIS:

get-windowsfeature | Where-Object {$_.Name –like “Web*”}

image

Na coluna “Name” da figura acima, você tem a listagem de todas as features do IIS. Tomando como exemplo a sessão “Application Development”, eu posso instalar todos os itens da mesma, declarando todos os parâmetros, ou posso escolher uma ou mais funcionalidades tais como ASP, ASP.NET 3.5, etc, usando os parâmetros separadamente. Lembrando que as funcionalidades vitais de cada feature são instaladas automaticamente, mesmo que eu não as declare na minha linha de comando (exemplo – se eu declarar somente a feature Web-Security, a funcionalidade Web-Filtering será habilitada automaticamente).

Em nosso laboratório vamos instalar o IIS pensando em autenticação básica, autenticação integrada, protocolos http e https. Além desses, vamos usar o serviço de armazenamento de certificados digitais, o CCS (Centralized Certificate Store – sobre o qual escrevi um post detalhado com um passo a passo bem completo). Veja abaixo como fica o comando para instalação:

add-windowsfeature web-server, web-webserver, web-default-doc, web-http-errors, web-static-content, web-http-redirect, web-health, web-security, web-basic-auth, web-certprovider, web-cert-auth, web-ip-security, web-windows-auth, web-app-dev

A imagem abaixo mostra o progresso da instalação:

image

Veja agora através do comando get-feature, as funcionalidades do IIS que foram instaladas com o comando usado acima:

image

OBS: Não instalei aqui a console de gerenciamento do IIS que você encontra em Start/Administrative Tools. Vamos focar na implementação e administração do IIS somente via powershell. Se você prefere gerenciar a partir da console, basta adicionar o parâmetro –IncludeManagementTools no fim do comando, ou na figura acima, você tem a sessão Management Tools com o parâmetro Web-Mgmt-Tools.

Agora que temos o IIS instalado, vamos aos métodos para administra-lo através do Powershell.

2. Criando um web-site

Vamos criar um site com os dados abaixo:

Nome – PortalUilson.net

Biding – https://www.uilson.net

Path – c:\webapp

Autenticação – Windows Integrated

Documento Default – iisstart.htm

Vai pegar o certificado através do Centralized Certificate Store.

1. Criando WebSite:

É importante que você já carregue o módulo do IIS com o comando: import-module WebAdministration

No prompt de comando, você já poderá ver como está configurado o Default Web Site conforme figura abaixo:

image

Com o comando “dir iis:” você visualiza três “pastas” do IIS disponíveis: 1. AppPools (Os application pools criados), 2. Sites (Seus WebSites, applications e virtual directories), 3. SSLBindings (Todos os bindings criados com certificado digital – porta 443).

Para listar os sites criados use o comando dir iis:\Sites para ter o resultado abaixo:

image

Acima você que o Default Web Site tem o ID 1 (importante na hora de determinar e configurar a parte de log do IIS), está em status “Started”, mostra o Physical Path e a parte do Binding rodando em http na porta padrão (80).

Para simplificar, você pode entrar no IIS pelo PowerShell digitando “IIS:” e teclando ENTER:

image

Viram como facilita?

Agora vamos criar nosso novo Web Site conforme descrevi:

Vamos criar a pasta onde vai ficar a aplicação web:

new-item c:\webapp –type directory

Com esse comando criamos a pasta webapp. Copiei os arquivos do site inicial do IIS para podermos efetuar o teste de acesso a página.

Comando para criar o site:

iis:

New-Item Sites\PortalUilson.net –bindings @{protocol=”http”;BindingInformation=”:80:www.uilson.net”} –physicalPath c:\webapp

image

O ID ficou meio estranho pra visualisar mas, é 1949349561. É com esse ID que ele vai criar a pasta de log da aplicação.

Na imagem acima você pode ver que eu já criei o site com o acesso a porta 80 no host header http://www.uilson.net . Eu poderia ter usado o comando acima sem o host header e poderia deixar um binding para porta 80 do localhost e poderia criar outro binding na mesma porta definindo a URL com o comando abaixo:

New-WebBinding -Name PortalUilson.net -IPAddress "*" -Port 80 -HostHeader www.uilson.net

Veja também que nosso site está em estado “Started”, ou seja, está escutando requisições na porta 80 a partir da URL que definimos. Caso houvesse algum conflito de porta, ele estaria em status “Stoped”, ou caso fosse necessário poderiamos para-lo com o comando abaixo:

Stop-WebSite PortalUilson.net

Para colocar o site no ar novamente, basta executar o comando abaixo:

Start-WebSite PortalUilson.net 

image

Agora que já temos nosso ambiente pronto, vamos começar a ver outros detalhes tais como log e documento default.

Em nosso laboratório criei um site simples sem nenhum application ou virtual directory. Nesse caso temos que definir o documento default que irá iniciar a pagina default do site. Caso contrário teremos erro no acesso.

Vamos verificar quais são os documentos que constam da lista de Default Document e qual documento está no topo da mesma. Para isso você vai usar o comando abaixo:

Get-WebConfigurationProperty -Filter //defaultDocument/files/add -PSPath ‘IIS:\Sites\PortalUilson.net’ -Name value | select value

image

Veja que no nosso site (PortalUilson.net) já temos Default.htm, Default.asp, index.htm, index.html e issstart.htm. Precisamos configurar o iisstart.htm no topo da lista, pois ele é o arquivo a ser chamado pela URL definida anteriormente.

Durante o período de estudos para confecção deste post, não encontrei uma linha de comando que fizesse a alteação da ordem dos arquivos, colocando ele no topo. Caso tentasse adiciona-lo como parâmetro para coloca-lo no topo, recebia uma msg de erro. Resolvi esse problema removendo o iisstart.htm da lista com o comando abaixo:

Remove-WebConfigurationProperty //defaultdocument/files "IIS:\sites\PortalUilson.net" -name collection -AtElement @{value="iisstart.htm"}

Depois verifiquei com o Get-WebConfigurationProperty para me certificar de que ele não constava mais na lista:

image

Agora vamos configurar o iisstart.htm como defult document do nosso site. Abaixo vou executar um comando que irá coloca-lo no topo da lista de arquivos do default document:

Add-WebConfiguration //defaultDocument/files "IIS:\sites\PortalUilson.net" -atIndex 0 -Value @{value="iisstart.htm"}

image

Você pode ver na imagem acima que o arquivo iisstart.htm aparece no fim do documento, entretanto, o parâmetro “atIndex 0” do comando aplicado acima o coloca no topo da ordem do default document.

3. Application Pool e métodos de autenticação

Já temos nosso site criado e configurado. Agora vamos verificar a parte do application pool dele:

Abaixo mostro como visualisar os application pools criados no IIS

image

Na imagem acima vemos que o Default Web Site já tem seu Application Pool definido, porém, o site do nosso laboratório ainda não.

Abaixo o comando para criação de um application pool:

image

OBS: O comando New-Item criou uma nova application pool no IIS. Como você pode ver na figura acima, estamos posicionados na pasta de Application Pools do IIS. Poderiamos executar esse comando mesmo em outra pasta ou na raiz do IIS da seguinte forma:  New-Item IIS:\AppPools\PortalUilson.AppPool

Agora vamos associar nosso Applicaton Pool com o site PortalUilson.net com o comando: Set-ItemProperty ‘IIS:\Sites\PortalUilson.net’ -Name applicationPool -Value PortalUilson.AppPool

Com a execução do comando acima, você verá agora que o site criado em nosso laboratório agora tem um application pool para ele:

image

Vamos definir uma conta para gerenciar essa application pool:

Set-ItemProperty iis:\AppPools\PortalUilson.AppPool -name processModel -value @{userName="appuser";password="WebAppPool@2016";identitytype=3}

No comando acima defini uma conta local (username = appuser e senha = AppPool@2016) classificando com IdentityType 3 – o Identity type se refere ao tipo de conta que você vai usar em sua Application Pool. O número do identity mudaria caso você fosse usar outro tipo de autenticação, exemplo: Network Service.

No link abaixo, você tem uma explanação detalhada da parte de Itentity Type:

http://www.iis.net/configreference/system.applicationhost/applicationpools/add/processmodel

Agora vamos ver as propriedades de nosso application pool com o comando get-item PortalUilson.AppPool | Select-Object *

image

Para ver os dados de usuário usamos o comando Get-ItemProperty PortalUilson.AppPool -name "processmodel.username"

image

Veja na figura acima que a penultima linha (Value) traz o nome da conta que configuramos nos passos acima.

Podemos ver também que nosso Application Pool está configurado para usar a versão 4.0 do .NET Framework:

image

Caso sua aplicação peça outra versão, você deverá tê-la instalada no servidor. A instalação de outras versões do .NET pode ser feita nas features do IIS conforme descrito no começo deste post.

Se você tiver um Application Pool rodando o .NET Framework na versão 2.0 e quiser mudar para a 4.0, use o comando abaixo:

Set-ItemProperty PortalUilson.AppPool managedRuntimeVersion v4.0

Com o conceito de Web Application Pool definido, vamos agora vamos falar sobre autenticação.

Lembre-se do começo deste post em que instalamos o IIS com diversos métodos de autenticação (basic, integrada, etc). Quero que o site site tenha autenticação integrada, entretanto, o IIS vem com autenticação anônima (por default) habilitada.

Nos comandos abaixo vamos desabilitar a autenticação anônima e habilitar autenticação integrada (lembrando que, para este fim a aplicação já deve estar preparada para tal):

Desabilitando Anonymous: Set-WebConfiguration system.webserver/security/authentication/anonymousAuthentication -PSPath IIS:\sites\PortalUilson.net -Value @{enabled="False"}

Habilitando Windows Integrated: Set-WebConfiguration system.webserver/security/authentication/WindowsAuthentication -PSPath IIS:\sites\PortalUilson.net -Value @{enabled="True"}

4. Logging e Backup

Depois de instalar e configurar o IIS, criar e configurar o novo site, iremos agora definir onde gravar os log´s do mesmo. Por default o IIS coloca os log´s de acesso na pasta padrão da role: c:\inetpub\logs\LogFiles\WebisteID#:

image

No nosso caso vamos configurar o log para que seja gravado numa pasta diferente. Vou configurar para gravar em C:\weblogs\PortalUilson.net. Para tanto vamos usar os comandos abaixo:

Alteração do log para a pasta citada acima:

Set-ItemProperty IIS:\sites\PortalUilson.net -name logFile -value @{format=’W3C’;directory=’C:\weblogs\PortalUilson.net’}

Listando as propriedades de logging do nosso siteget-ItemProperty IIS:\sites\PortalUilson.net -name logFile:

image

No link a seguir, você encontra diversas formas de interagir com logging do IIS via PowerShell, inclusive alterando os campos do arquivo:

https://gallery.technet.microsoft.com/office/Set-IIS-Log-Fields-via-ee9c19b3

Com tudo pronto no nosso laboratório, vamos demonstrar agora como fazer o backup das configurações do IIS. A melhor forme de garantir seu ambiente é um backup do servidor usando a ferramenta da sua empresa, mas, para situações em que você precisa de um restore rápido é interessante ter um backup das configurações do IIS feito no próprio web server.

Para efetuar um backup rápido de suas configurações do IIS use o comando abaixo:

Backup-WebConfiguration –Name IISLab

image

Nesse comando eu fiz um backup das configurações do meu servidor IIS com o nome de “IISLab”.

Para verificar um ou mais backup´s feitos em seu ambiente use o comando Get-WebConfigurationBackup:

image

Como você pode ver na figura acima, posicionei na pasta c:\windows\system32\inetsrv\backup, onde o IIS grava os arquivos de backup gerados pelo comando que usamos a pouco:

image

5. SSL Settings – Agora é a sua vez de por a mão na massa!

Agora é com você!

Se leu todo post com atenção, testou em seu ambiente pessoal e ficou entusiasmado com a possibilidade de administrar seu IIS sem a Console de Gerenciamento, leia o conteúdo dos links abaixo e configure a parte SSL do IIS 8.5. Não foge dos conceitos que coloquei aqui e tudo pode ser encontrado no site iis.net da Microsoft.

Criando SSL Bindings no IIS – http://www.iis.net/learn/manage/powershell/powershell-snap-in-configuring-ssl-with-the-iis-powershell-snap-in

Na instalação do IIS você viu que coloquei também o recurso do CCS – Centralized Certificate Store. No começo deste post eu deixei um link com um artigo que escrevi sobre esse tema mostrando todo conceito e todos os passos (um lab completo) para habilitar o CCS. Para fazer o mesmo procedimento via PowerShell, clique no link abaixo:

https://technet.microsoft.com/en-us/magazine/jj937171.aspx

Além de ensinar a configurar o CCS, o link acima traz um exemplo de como instalar o IIS com as mesmas configurações em vários servidores, caso sua aplicação esteja definida para rodar numa farm.

E assim concluímos mais um post da série “Otimizando tarefas com PowerShell”. Cobrimos todos os passos para a instalação e administração do IIS 8.5 do Windows Server 2012 R2 via cmdlet.

Espero que o conteúdo tenha sido útil e caso tenha dúvidas ou críticas, por favor, deixe seu comentário ou me deixe uma msg em minha pag pessoal em http://facebook.com/usouzajr

Abraços

Uilson

%d blogueiros gostam disto: