a) Registros Netbios comuns a WINS e DNS.
b) Falha na integração com Active Directory.
c) Servidor autoritativo para um domínio.
d) Aguardando resposta do servidor raiz.
e) Transferência de zona incremental.

Em um serviço de resolução de nomes (Domain Name System – Sistema de Nomes de Domínios, ou apenas DNS) é possível dividir em zonas as informações a serem fornecidas pelos servidores. Uma zona armazena informações sobre um ou mais domínios (esses últimos denominados subdomínios). Os subdomínios criados em uma zona podem ser tanto administrados pelo próprio servidor DNS que criou a zona originalmente quanto delegados a um outro servidor. Além da delegação, a zona pode ser completamente replicada a um servidor secundário para fins de redundância e alta disponibilidade.

A partir do momento em que uma zona é criada em um servidor secundário para redundância (zona secundária) ela é automaticamente replicada com o servidor principal. Para coordenar esta sincronização os servidores mantém um número de versão para a zona. Caso a versão do servidor solicitante seja inferior à versão do servidor principal é iniciada uma transferência de zona. Nas primeiras implementações DNS esta replicação enviava informações completas da zona (transferência do tipo AXFR) . A partir da RFC 1995 foi proposto o IXFR (opção correta para a questão do concurso), transferência que envia apenas as mudanças para o servidor secundário, de maneira incremental. Os acrônimos AXFR e IXFR representam os opcodes das transferências.

O serviço DNS passou por revisões recentes e teve adicionado características interessantes visando aprimorar segurança e flexibilidade, dentre elas:

• Serviço de notificação sobre mudanças em zonas, disponível a partir do Windows 2000;
• DNSSEC,  extensões que mitigam ataques do tipo spoofing e man-in-the-middle que está disponível nativamente no Windows Server 2008 R2 e Windows 7 (mais informações no DNSSEC Deployment Guide). O DNSSEC ganhou popularidade por evitar a vulnerabilidade exposta na descoberta do famoso bug na especificação original do DNS em 2008 (em breve artigo sobre DNSSEC aqui!);
• Suporte a IPv6, a partir do Windows Server 2008.

a) cada usuário criado em D será armazenado em um controlador de domínio utilizando uma política de round-robin.
Errado. Todos os objetos do Active Directory são armazenados em todos os controladores de domínio do domínio. Não confundir com o RODC (Read-Only Domain Controller), possibilidade disponibilizada a partir do Windows Server 2008. O RODC se encaixa em cenários de escritório remoto em que é necessária uma cópia apenas leitura do domínio por razões de segurança.

b) cada BDC (Backup Domain Controller) sincroniza sua hora local com o relógio do PDC (Primary Domain Controller) desse domínio.
Errado. O conceito de Backup Domain Controller existia no Windows NT 4 e não é utilizado no Windows Server 2003. De qualquer maneira cabe ainda ao PDC Emulator a missão de sincronizar horário. Recomenda-se que ele seja sincronizado com um servidor NTP externo. PDC Emulator sincroniza os DCs e os DCs sincronizam as estações e outros servidores da rede.

Mais em How Windows Time Service Works.
�
c) o nível de funcionalidade de domínio Windows Server 2003 pode ser habilitado, permitindo que o domínio seja renomeado.
Correto. O nível funcional da floresta em Windows Server 2003 traz várias melhorias ao Active Directory. Dentre elas, renomear o domínio. Para a elevação de nível é necessário que todos os controladores de domínio estejam executando Windows Server 2003.

Mais informações em New features for Active Directory e Raise the forest functional level

d) o número máximo de grupos permitido em D é 65536 (n x 16384), onde n é o número de controladores de domínio.
Errado. Não há relação entre número de controladores de domínio e quantidade máxima de objetos (dentre eles, grupos). Vale a pena uma lida no artigo Active Directory Maximum Limits – Scalability.

e) uma estação Windows XP não pode participar de D como cliente.
Errado. O Windows XP está entre os clientes suportados por um domínio nível funcional 2000, 2003 ou 2008. Para Windows 95, Windows 98 e Windows NT faz-se necessário instalação do cliente Active Directory.

(Analista de Redes INMETRO – 2007)
Acerca dos serviços de diretório e LDAP, julgue os seguintes itens.

- No Windows Server 2003, é possível sincronizar o Active Directory com o Novell Directory Services por meio do MSDSS.
Correto. A ferramenta MSDSS está presente no Microsoft Windows Services for NetWare, um conjunto de ferramentas de migração e compatibilidade com a plataforma de diretório da Novell.

-  O Active Directory é implementado usando a estrutura do X.500 para os dados do diretório.
Correto. Item bem controverso. O LDAP, protocolo implementado pelo Active Directory, foi inspirado no X.500 mas se tornou uma especificação própria a partir de 1994. A motivação que veio do X.500 foi em especial a hierarquia de árvore em nós, cada um com respectivos atributos e valores.

Fonte: Active Directory’s LDAP Compliance

- Um servidor normal pode ser promovido a controlador de domínio apenas por meio da execução do comando DCPROMO do Executar do menu Iniciar.
Correto. O único caminho para se promover um servidor a controlador de domínio é via DCPROMO. O NTDSUTIL pode ser utilizado apenas para rebaixar um Domain Controller, em especial em casos em que a retirada via DCPROMO tenha falhado. Outra observação interessante são os avanços do DCPROMO no Windows Server 2008.

- As opções de autenticação no LDAP se restringem a autenticação simples com SSL/TLS e com Security Layer.
Errado. As duas alternativas do item são referem-se à mesma funcionalidade, autenticação utilizando SSL (Security Socket Layer). A autenticação padrão do LDAP não utiliza nenhuma criptografia.

How to troubleshoot LDAP over SSL connection problems – http://support.microsoft.com/kb/938703/en-us
How to enable LDAP over SSL with a third-party certification authority – http://support.microsoft.com/kb/938703/en-us

(PETROBRÁS – 2008)
Para servidores com Windows Server é CORRETO afirmar que:
 

Managing DNS Records – http://technet.microsoft.com/en-us/library/bb727018.aspx

 2) o recurso round robin de um servidor DNS pode ser utilizado para realizar o balanceamento de carga entre servidores Web.
Correto. Servidores DNS devolvem uma lista de registros ordenados por round robin quando há mais de um registro para um mesmo nome. Se forem cadastrados vários registros tipo A para o nome do servidor web (webserver.dominio.com, por exemplo), ao se fazer uma consulta por este nome será devolvida a lista de IPs dos servidores ordenada por round robin. Este arranjo também confere alta disponibilidade, já que se o primeiro IP fornecido não estiver acessível o cliente DNS resolverá os seguintes da lista, um a um.

O artigo Configuring round robin (http://technet.microsoft.com/en-us/library/cc787484(WS.10).aspx) explica o funcionamento do Round Robin. O DNS do Windows Server tem também a possibilidade de priorizar um endereço IP que esteja “mais próximo” (na mesma subrede) do host solicitante. O artigo Prioritizing local subnets (http://technet.microsoft.com/en-us/library/cc787373(WS.10).aspx) explica este procedimento.

 3) os servidores DHCP devem ser configurados com endereço IP dinâmico. 
Errado. Servidores DHCP tem por função fornecer endereço IP e outras configurações de rede a adaptadores de rede. Sendo assim, servidores DHCP devem possuir IP fixo. A instalação do serviço DHCP faz esta recomendação quando da instalação. No documento DHCP server role: Configuring a DHCP server (http://technet.microsoft.com/en-us/library/cc756865(WS.10).aspx) a recomendação também está expressa como um dos requisitos para a instalação do DHCP. 

 4) um servidor DHCP pode fornecer a uma estação cliente um endereço de IP padrão para um servidor DNS.
Correto. Além de endereço IP o servidor DHCP pode fornecer configurações adicionais para a placa de rede. Uma listagem de servidores DNS a serem usados está na listagem de possíveis configurações a serem passadas para um host que envia uma solicitação. Uma listagem completa das configurações possíveis pode ser obtida em http://technet.microsoft.com/en-us/library/cc958929.aspx.

RFC 2131 Dynamic Host Configuration Protocol - http://www.ietf.org/rfc/rfc2131.txt 

 5) um servidor DNS pode atuar, simultaneamente, como servidor primário para algumas zonas, enquanto atua também como servidor secundário para outras.
Correto. Uma zona DNS é primária se foi criada e pode ser gerenciada diretamente a partir de determinado servidor DNS. Uma zona secundária é uma cópia read only de uma zona primária contida em outro servidor. Não confudir zona primária e zona secundária em um servidor DNS com servidor DNS primário e servidor DNS secundário em um cliente. Não necessariamente um servidor DNS primário configurado em um cliente deve conter uma zona primária. Não necessariamente um servidor DNS secundário deve conter uma zona secundária. 

A Technet Libraryexplica no artigo Understanding zones and zone transfer (http://technet.microsoft.com/en-us/library/cc781340(WS.10).aspx) como funciona a transferência de zonas entre servidores DNS. Uma configuração interessante é utilizar a replicação de zonas para permitir interoperabilidade entre servidores DNS Linux e Windows.

Para iniciar a série, separei uma questão que cobra conteúdo sobre discos e armazenamento. Ele foi cobrada no concurso de analista do Tribunal Superior Eleitoral de 2007.

(TSE 2007 – Analista de desenvolvimento)

a) O Windows Server 2003 possibilita que se gerencie a utilização do espaço em disco pelos usuários definindo-se cotas em disco. As cotas podem ser definidas para volumes FAT ou FAT32, mas não para volumes NTFS.
Errado. O Windows Server 2003 implementa sim as cotas, mas apenas para volumes NTFS. (http://technet.microsoft.com/en-us/library/cc776144(WS.10).aspx). A partir do Windows Server 2008 o suporte a cotas está otimizado e suporta cenários mais flexíveis (http://technet.microsoft.com/pt-br/library/cc772421(WS.10).aspx).

b) O Windows Server 2003 suporta os níveis RAID 1, 2 e 3. No nível 1, são utilizados três ou mais volumes, cada um em uma unidade de disco. Esse nível provê tolerância a falhas com menos sobrecarga que o espelhamento.
Errado. O Windows Server 2003 suporta RAID 0, RAID 1 e RAID 5.

Em poucas palavras:
RAID 0 – Arranjo de vários discos idênticos dividos em faixas (stripes) que somam espaço e aumentam o desempenho. Os espaços em disco se somam. Como desvantagem vale notar que se um disco do arranjo falhar não é possível recuperação de informações;

RAID 1 – Arranjo de a partir de dois discos que permite redundância: todos os dados são gravados em ambos os discos e, caso um falhe, a informação pode ser restituída a partir do disco saudável.

RAID 5 – Arranjo de a partir de três discos que reserva um dos discos para guardar informações de paridade. Assim, caso haja perda de dados, a informação pode ser reconstituída a partir dos indices de paridade buscando em outro disco saudável.

HOW TO: Establish a Striped Volume (RAID 0) in Windows Server 2003:  http://support.microsoft.com/kb/323433/en-us
How to mirror the system and boot partition (RAID1) in Windows Server 2003: http://support.microsoft.com/kb/323432/en-us
How To Establish a Striped Volume with Parity (RAID-5) in Windows Server 2003: http://support.microsoft.com/kb/323434/en-us

c) A Microsoft Interface Definition Language (MIDL) é usada na codificação dos corpos dos procedimentos remotos. A compilação de um procedimento codificado na MIDL produz o código executável do procedimento remoto.
Errado. A MIDL gera códigos intermediários em C (e não executáveis). Mais sobre em http://msdn.microsoft.com/en-us/library/aa367091(VS.85).aspx.

d) No Windows XP, o sistema de arquivos NTFS usa clusters como unidade de alocação em disco. Um cluster é composto por setores em disco e o seu tamanho pode ser configurado quando um sistema de arquivos NTFS é formatado.
Correto. O NTFS permite na formatação de um disco escolher o tamanho da unidade de alocação. O mesmo não acontece com unidades FAT, como mostrado na figura abaixo:

Esta série de posts continuará. Quem tiver mais questões de concursos sobre Windows Server pode mandar para roberto@redes.unb.br.