Decidi escrever um post sobre este assunto, pois existe uma série de alternativas e dúvidas de como gerenciar o papel de parede das estações de trabalho via GPOs. Segue abaixo algumas destas questões:

1) Copiar o arquivo para estação de trabalho ou carregar o papel de parede a partir rede?

2) Optando pela primeira opção, como copiar o arquivo? De onde copiar o arquivo?

3) Como delegar a mudança do papel de parede para outro departamento? (Marketing ou RH, por exemplo)

4) Mudar o nome do arquivo a cada novo papel de parede ou manter o mesmo?

5) Quais são as policies que precisam ser modificadas?

Ao longo do artigo vou respondendo as perguntas, comentando cada resposta e ao final faço um passo a passo de como fazer toda a configuração.

Nota: Para ambientes pequenos, algumas das opções abaixo podem não representar a melhor opção, por gerar uma sobre carga administrativa desnecessária, logo, as recomendações apresentadas neste artigo são mais relevantes para ambientes com mais de 200 estações de trabalho.

1) Copiar o arquivo para estação de trabalho ou carregar o papel de parede a partir rede?

Resposta: Copiar o arquivo para a estação de trabalho

Explicação: Mesmo que a cópia do arquivo gere tráfego de utilização de rede, isso só acontecerá a cada mudança do papel de parede, ou seja, a cópia para a estação do usuário é a melhor solução por gerar menor tráfego de rede.

 

2) Optando pela primeira opção, como copiar o arquivo? De onde copiar o arquivo?

Resposta (Como copiar): Através de uma GPO com um script de startup rodando um arquivo batch.

Explicação (Como copiar): A minha recomendação para cópia do arquivo de papel de parede (*.jpg) para a estação de trabalho é que seja realizada através de um arquivo batch que compara a versão existem com a versão da rede,(usando COMP), se foram iguais, não faz nada, se forem diferentes faz a cópia do arquivo.(usando COPY) O batch que faz isso segue abaixo:

rem --------------------------------------------------------
set file1=\\hunecke.com\sysvol\hunecke.com\Policies\{C81C30B9-8725-463B-BC70-F774D9E38D9D}\Machine\Scripts\Startup\wallpaper1.jpg
set file2=C:\Windows\Web\Wallpaper\Windows\wallpaper1jpg
echo n | COMP %file1% %file2%
if errorlevel 1 copy %file1% %file2%
rem --------------------------------------------------------

Obviamente que o batch pode ser substituído pelo ROBOCOPY.EXE, porém além de sua chamada ser mais lenta que o COMP, o executável não está presente em todos os sistemas operacionais por padrão.

O caminho para criação do script de startup é Computer Configuration/Policies/Windows Settings/Scripts (Startup/Shutdown), conforme abaixo:

Resposta (De onde copiar): A partir da pasta \Machine\Scripts\Startup da GPO

Explicação (De onde copiar): Ao invés de copiar de um servidor de arquivos, você pode distribuir a carga entre todos os controladores de domínios, desta forma a estação copia o arquivo do servidor que fez sua autenticação. Se a estrutura da Sites and Service do Active Directory estiver corretamente configurada, a estação buscará o arquivo do servidor “mais próximo”.

 

3) Como delegar a mudança do papel de parede para outro departamento? (Marketing ou RH, por exemplo)

Resposta: Copiar o arquivo *.jpg para o \Machine\Scripts\Startup a partir de um compartilhamento da área departamental de Marketing ou RH, por exemplo.

Explicação: Este é um fator de sucesso para o gerenciamento do papel de parede. Normalmente as alterações de papel de parede são demandas por outros departamentos como, por exemplo, Marketing e RH, e acontecem aos 46 minutos do segundo tempo (fazendo uma correlação com o futebol). Neste horário não há mais ninguém em TI para fazer alguma alteração na pasta, ou mesmo na GPO. Por isso recomendo criar uma pasta na área departamental chamada Wallpaper e criar um agendamento no servidor de arquivos ou mesmo no controlador de domínio para copiar o arquivo de tempos em tempo para a pasta Machine\Scripts\Startup. Desta forma, o departamento tem autonomia para modificar o papel de parede para as estações de trabalho. Utilize o mesmo batch para copiar o arquivo da área departamental para a pasta Machine\Scripts\Startup.

rem --------------------------------------------------------
set file1=\\fileserver01\deptos\RH\Wallpaper\wallpaper1jpg
set file2=\\hunecke.com\sysvol\hunecke.com\Policies\{C81C30B9-8725-463B-BC70-F774D9E38D9D}\Machine\Scripts\Startup\wallpaper1.jpg
echo n | COMP %file1% %file2%
if errorlevel 1 copy %file1% %file2%
rem --------------------------------------------------------

Depois de testar o script acima configure em uma tarefa agendada em algum servidor para rodar o script de 30 em 30 minutos, por exemplo.

Importante: Controle as permissões de acesso à pasta Wallpaper da área departamental, caso contrário algum usuário mal intencionado poder modificar o papel de parede de todas as estações.

 

4) Mudar o nome do arquivo a cada novo papel de parede ou manter o mesmo?

Resposta: Manter o mesmo nome do arquivo

Explicação: De certa forma esta pergunta já foi respondida acima, não faz sentido alterar o nome do arquivo, isso geraria a necessidade de modificar a GPO a cada novo papel de parede, ou seja, use sempre o mesmo nome de arquivo, preferencialmente armazenado na pasta C:\Windows\Web\Wallpaper\Windows. O controle de histórico deverá ser feito na pasta departamental de RH ou Marketing.

5) Quais são as policies que precisam ser modificadas?

Resposta: Apenas a policy Desktop Wallpaper precisa ser modificada. O caminho desta GPO é User Configuration/Administrative Templates/Desktop/Desktop, conforme abaixo:

A configuração necessária é:

• Enable
• Wallpaper Name
• Wallpaper Style

Explicação: Nos “velhos tempos” do Windows 95/98 era necessário também habilitar a policy Active Desktop que não é mais necessário para clientes Windows XP SP3 ou superior. Além da GPO de configuração apresentada acima, configure na mesma GPO a execução do script de startup que chamará o batch apresentado no item 2 acima.

Em resumo, para fazer o gerenciamento do papel de parede das estações de trabalho via GPO, siga os passos abaixo:

1) Crie uma pasta Wallpaper na área departamental de Marketing ou RH; (atenção para as permissões nesta pasta);

2) Crie um GPO com a configuração apresentada no item 5 (User Configuration) e com o script de Startup apresentado no Item 2 (Computer Configuration);

3) Faça um link da GPO na OU onde estão os usuários e outro link na OU onde estão as contas de computador das estações de trabalho;

3) Crie uma tarefa agendada no servidor para copiar o arquivo *.jpg da área departamental para a pasta Machine\Scripts\Startup da GPO;

4) Para testar, reinicie a estação de trabalho.

Espero que estes pontos auxiliem nas definições de como gerenciar o papel de parede através de GPOs. Caso tenho alguma dúvida, envie um email usando a opção Email Blog Author no canto superior direito.

O Márcio escreveu um post bem interessante para verificar a configuração do horário de verão de todos os computadores da rede a partir do SCCM. Veja no link:
http://marciohunecke.wordpress.com/2010/10/06/usando-o-sccm-para-evitar-surpresas-com-o-horario-de-verao/

Faça a configuração do horário de verão em toda a sua rede e confirme que está tudo ok com o SCCM. Assim no dia 18/10/2010 não haverão surpresas.

Parabéns Márcio.

Seque abaixo uma lista de ajustes necessários na documentação padrão para instalação do Commerce Server 2009 em ambiente com múltiplos servidores.

1) Na definição de permissões de acesso ao arquivo CatalogAuthorizationStore.xml incluir a permissão de Read and Execute também para o usuário RunTimeUser (http://msdn.microsoft.com/en-US/library/dd452302(v=CS.90).aspx).

2) Na definição de permissão para as bases de dados, modificar a permissão do usuário RunTimeUser na tabela DefaultSite_ProductCatalog de ctlg_catalogReaderRole por ctlg_catalogWriterRole (http://msdn.microsoft.com/en-us/library/dd464535(CS.90).aspx).

3) Na lista de tabelas das bases de dados o nome correto da tabela é DefaultSite_Marketing_Lists (com 2 underlines) e não DefaultSite_MarketingLists (http://msdn.microsoft.com/en-us/library/dd464535(CS.90).aspx).

4) Mesmo que indicado no link: http://msdn.microsoft.com/en-us/library/dd442343(v=CS.90).aspx  não é recomendado criar os registros SPN apontando para o SQL Server e usuário RunTimeUser, isso gerará erro de conflito de SPN (Event ID 3 - 0x7  KDC_ERR_S_PRINCIPAL_UNKNOWN) . A recomendação é instalar a atualização e seguir os procedimento do artigo: http://support.microsoft.com/kb/975603.

Recentemente estava em um projeto envolvendo uma avaliação do Active Directory R2 e me deparei com objetos no container ForeignSecurityPrincipals, até então desconhecidos para mim.

Pesquisei um pouco sobre o container e descobri algumas coisas interessantes:

1) Este container somente é visualizado na ferramenta Active Directory Uses and Computers (DSA.MSC) quando habilitada a opção “Advanced Features” no menu View.

2) Este container é pré-populado com 4 objetos padrões durante a criação do domínio, conforme abaixo:

3) Quando existe uma relação de confiança, este container mantém uma cópia de todos os objetos de domínios externos (trusted domain) para permitir que estes sejam incluídos em grupos do domínio e usados também no SIDHistory

4) Este container pode e deve ser limpo após a remoção da relação de confiança. Por exemplo, em um ambiente de unificação de domínios, após estar tudo unificado em 1 domínio os objetos externos podem ser excluídos.

No meu caso os 4 objetos padrões deste container haviam sido removidos por engano e precisei recriá-los. Interessante que estes grupos são criados automaticamente quando alguns grupos especiais do Windows são incluídos em alguns grupos BuiltIn. Por exemplo: se você incluir o grupo especial INTERACTIVE no grupo BuiltIn Users, o objeto S-1-5-4, conforme abaixo é criado.

Da mesma forma para a tabela abaixo. O grupo especial da coluna da esquerda sendo incluído no grupo BuiltIn da coluna da direita.

Ao invés de fazer manualmente fiz um script para facilitar a criação dos 4 objetos, basta ajustar o caminho LDAP na primeira linha do script (set LDAP….) conforme o nome do seu domínio.

set LDAP=DC=hunecke,DC=com

dsmod group "CN=Pre-Windows 2000 Compatible Access,CN=Builtin,%LDAP%" -addmbr "CN=Authenticated Users,CN=WellKnown Security Principals,CN=Configuration,%LDAP%"

dsmod group "CN=Users,CN=Builtin,%LDAP%" -addmbr "CN=Authenticated Users,CN=WellKnown Security Principals,CN=Configuration,%LDAP%"

dsmod group "CN=IIS_IUSRS,CN=Builtin,%LDAP%" -addmbr "CN=IUSR,CN=WellKnown Security Principals,CN=Configuration,%LDAP%"

dsmod group "CN=Users,CN=Builtin,%LDAP%" -addmbr "CN=INTERACTIVE,CN=WellKnown Security Principals,CN=Configuration,%LDAP%"

dsmod group "CN=Windows Authorization Access Group,CN=Builtin,%LDAP%" -addmbr "CN=Enterprise Domain Controllers,CN=WellKnown Security Principals,CN=Configuration,%LDAP%"

Mais informações sobre grupos especiais do Windows veja no post: http://blogs.technet.com/b/mhunecke/archive/2010/09/29/rela-231-227-o-de-objetos-padr-245-es-do-windows-e-respectivo-sid.aspx