Printbrm, cadê as minhas portas?

Para quem deseja migrar servidores de impressão Windows, a Microsoft disponibiliza o Print Migration Wizard. Bem, mas este não é o foco do artigo. Vamos ao que realmente interessa.

Dias atrás me deparei com o seguinte problema: haviam dois servidores de terminal service. No primeiro deles foram instaladas e configuradas mais de 400 impressoras com portas UNC que direcionavam as impressões para outro servidor de impressão. Para não repetir a instalação das mais de 400 impressoras na segunda máquina, foi utilizado o Print Migration Wizard (Printbrm) para facilitar a tarefa. As impressoras foram exportadas da primeira máquina e importadas para a segunda, no entanto, após a conclusão da operação, verificou-se que as portas UNC não foram importadas no segundo servidor.

Bem, nenhum erro foi gerado em lugar algum e a importação tanto pela interface gráfica, quanto pela linha de comando, informava que a operação havia sido concluída com sucesso.

Após quebrar a cabeça um pouco verifiquei que no registro do primeiro servidor, a chave HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Ports, possuia todos os valores correspondentes as portas das impressoras e, na segunda máquina, não constavam os mesmos dados.

Fiquei intrigado e resolvi fazer alguns testes com o Printbrm e cheguei a uma conclusão. A ferramenta apenas transfere portas LPR e Standard TCP/IP, o que faz todo sentido, pois, nos servidores de impressão, as portas de impressoras sempre apontam para o endereço IP da impressora ou elas são conectadas diretamente a máquina.

As portas configuradas com UNC path são portas locais que contém o caminho \\ServidorDeImpressao\Impressora. Por se tratar de portas locais, elas não devem ser exportadas mesmo, pois são portas locais e pode variar entre diferentes computadores.

Bem, com tudo isso, para resolver o problema, no servidor de origem, as impressoras foram migradas entre as máquinas utilizando o Printbrm. Para transferir as portas, foi exportada a chave de registro HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Ports da máquina de origem para um arquivo .reg. Em seguida, o mesmo foi importado no servidor de destino. Para finalizar, foi necessário reiniciar o serviço Print Spooler:

> net stop spooler && net start spooler

Voilà! As impressoras e as respectivas portas UNC foram transferidas entre os servidores.

Um abraço e até a próxima!

Erro "Access is denied" ao efetuar logon em servidor de terminal service

Recentemente, me deparei com um problema um tanto bizarro. Ao tentar efetuar logon em servidor de terminal services com o Windows Server 2008 R2 SP1 instalado, utilizando uma conta do Active Directory que era membro de muitos grupos, era obtida a mensagem de erro: "Access is Denied".

Bem, ao olhar no event viewer, nenhum erro foi encontrado. Ao efetuar logon com conta, diretamente na máquina, o erro não acontecia. Ao testar em um servidor com o Windows Server 2008 SP2, o logon era efetuado com sucesso, sem erros.

Primeiramente, poderia-se pensar no problema do limite de 1015 grupos suportado pelo Active Directory, conforme descrito no artigo http://support.microsoft.com/kb/328889/en-us, porém, a conta era membro de muitos grupos, mas não chegava a 1015.

Após várias pesquisas e testes, um companheiro meu encontrou a reposta. Neste artigo da Microsoft, é descrito o valor MaxTokenSize e fala justamente sobre o problema do usuário ser membro de muitos grupos. No entanto, o documento diz que é só instalar o último service pack do sistema operacional que o problema é resolvido.

Neste caso, o último service pack estava instalado :( . Bem, encontrou-se então outro documento, situado neste link: http://support.microsoft.com/kb/938118/en-us. Ele mostra como alterar o valor MaxTokenSize.

Assim, no servidor de terminal service com problemas, foi criado o valor abaixo no registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Entrada: MaxTokenSize
Tipo: REG_DWORD
Valor: 65535

Em seguida, o servidor foi reiniciado. Após isso, o problema foi resolvido e os usuários conseguiram efetuar logon sem problemas!

 

Um abraço e até a próxima!

Bloquear gravação de arquivos indesejados em compartilhamentos do Samba

O Windows Server, a partir da versão 2003 R2, possui o recurso File Screening, o qual é possível bloquear a gravação de arquivos no servidor, utilizando uma lista com extensões. Por exemplo, para a criação de uma política que bloqueia arquivos de música, as extensões mp3, wma, ogg, entrariam para a lista.

Bem, felizmente, para quem utiliza a dupla Linux/Samba, também é possível realizar tal bloqueio e de forma simples. Vamos supor que se deseja negar a gravação dos arquivos de música citados acima nos compartilhamentos.

No arquivo de configuração do Samba, vá até a seção das opções do compartilhamento e insira a diretiva abaixo:

veto files = /*.mp3/*.wma/*.ogg/

Na realidade, a política se aplica a arquivos que terminam com o nome .mp3, .wma e .ogg. Desta forma, também possível, por exemplo, bloquear arquivos que contém a string xxx no nome:

veto files = /*xxx*/

Abaixo há um exemplo da diretiva aplicada a um compartilhamento:

[documentos]
        comment = Documentos da rede
        path = /var/documentos
        valid users = @usuarios
        write list = @admin
        read only = No
        create mask = 0770
        directory mask = 0770
        veto files = /*.mp3/

Lembrando que após esta alteração é necessário reiniciar o daemon do Samba.

Esta diretiva irá não só bloquear a gravação dos arquivos, mas também irá ocultar os que já existem. Os usuários não conseguirão visualizá-los ao acessar a pasta compartilhada.

Uma outra dica é excluir ou mover os arquivos indesejados nas pastas compartilhadas do servidor de arquivos:

# find /var/documentos -name "*.mp3" -exec rm -fv {} \; (Para excluir os arquivos)

# find /var/documentos -name "*.mp3" -exec mv {} /var/lixo \; (Para mover os arquivos)

Um abraço e até a próxima.