O pior é aguentar as risadas do pessoal mais experiente quando eu falo das minhas peripécias.
"Professor, eu tenho 2 servidores de AD mas eles não estão replicando, o que pode ser?"
Ai você ouve: "AHAHAHA PUTA DOMINIO ZICADO MEU! Olha honestamente, termine seu curso, quando voce ficar mais experiente é melhor voce fazer tudo novamente, documentado, etc. e tal"
Sim é uma boa idéia. Mas meu, já tem 05 meses que eu instalei este domínio tanta configuração foi feita no anti virus, nas policies etc... Tudo de novo é meio cruel
Pensei com meus botões: Vou tentar remover a "role" (nota: role = regra/serviço em ingles não vai pensando besteira) de Active Directory e colocar no AD novamente.
VAmos lá pela interface gráfica... "NAO FOI POSSIVEL REMOVER POIS NAO FOI ENCONTRADO OUTRO SERVIDOR DE DOMINIO"..... eu pensei... PATACAPARÉU!
Fui via linha de comando: Iniciar, executar, dcpromo.exe
Mesmo erro. Ai eu já quase chutando o balde, quero dizer o gabinete, resolvi procurar na internet uma solução.
Depois de várias formas de pesquisa em ingles, portugues, javanes, mandarim, consegui chegar na KB da microsoft que me mostrava a luz no fim do túnel.
http://support.microsoft.com/kb/332199/pt-br
Resumindo, quando um de seus servidores de AD pararem de replicar use a famosa prática do TIRA-E-POE. se der pau na hora de remover a regra de AD, digite na linha de comando:
dcpromo /forceremoval
Finalmente consegui remover o AD sem ter que formatar aquela máquina que tinha tudo funcionando. Inclui no AD novamente e voilá! REPLICA!!! problema resolvido sem ter que fazer tudo novamente.
CUIDADO!! NUNCA JAMAIS NEVER USE ESTA TÉCNICA SE O SEU SERVIDOR FOR O ULTIMO SERVIDOR DE ACTIVE DIRECTORY!!! Obviamente voce não vai ter que fazer tudo isso se for o ultimo servidor, mas caso esteja tentando apenas resolver o problema e não querendo remover a regra permanentemente, este comando remove e apaga todos os objetos do active directory e NÃO FAZ BACKUP.
Depois, quando sobrar mais um tempinho, vou mostrar pra voces que um de meus servidores DNS dava erro de 5 em 5 minutos e tinha que reiniciar o serviço. Depois de muito tempo, descobri que o anti-virus tinha um pouco a ver com a solução, que postarei em breve.
quarta-feira, 24 de fevereiro de 2010
terça-feira, 2 de fevereiro de 2010
Usuário com perfil Móvel precisa ser administrador?!?!
Isso só acontece comigo. Pra todos os instrutores que perguntei:
"Usuário com perfil móvel precisa ser administrador da máquina local?"
Todos responderam, "Claro que Não!"
Pois é. Na minha rede precisa. NÃO TEM na TechNet e em lugar nenhum uma explicação para este tipo de problema. A PROVAVEL causa para este tipo de situação inusitada é que ao invés de deixar o sistema criar a pasta do usuário automaticamente, eu criei cada pasta de usuário (são poucas) e copiei o perfil deles para dentro destas pastas.
Antes que alguem possa dizer "Que burro", claro que eu fiz o usuário como proprietário da pasta etc, e tals. Teoricamente tudo estava correto. Mas para fazer funcionar na máquina local o usuário precisa ser ADMINISTRADOR!!
Não adianta colocar usuário avançado, debugger users, etc. etc. tem que ser administrador.
O meu instrutor do Curso de "Administrando Ambientes Windows 2003 Server" me deu uma idéia para tentar dar um "override" neste problema.
Passo 1) Faça todos os usuários darem um login com seu perfil na máquina que utilizam. No perfil de cada usuário no AD, retire a linha que indica o caminho do perfil. Isso fará com que o perfil do usuário se torne local.
Eles fazem um logoff e o perfil é salvo na máquina local. Antes deles fazerem login novamente veja abaixo:
Passo 2) Para os iniciantes, basta selecionar todos os usuários que se aplicam a isto de uma só vez, da mesma forma que voce seleciona vários arquivos, clicando no primeiro, depois segura SHIFT e clica no ultimo.
Clique com o botao direito do mouse, e selecione Properties, digite a linha //ServerName/Profiles/%username%
Legendas:
a) ServerName = Nome do seu servidor onde estão armazenados os perfis móveis
b) Profiles = Subdiretório onde estão as pastas do usuário
c) %username% = isto faz com que seja atribuido o nome de login do usuário. Se o login do dito cujo for tiburcio, digitando %username% será automaticamente atribuido tiburcio no nome da pasta. PRECISA colocar o sinal de % antes e depois.
d) / = backslash ( \ ) . O editor do blog não deixa digitar caminhos
Passo 3) REMOVA todas as pastas de usuário que estão no diretório //ServerName/Profiles precisa remover tudo, caso contrário não funcionará (ao falar remover presume-se que voce é esperto e vai MOVER para uma outra pasta qualquer antes de apagar definitivamente.)
Passo 4) Quando todas as pastas de perfil móvel estiverem devidamente apagadas ou movidas, diga aos usuários para fazerem logon novamente. Eles trabalharão normalmente, e quando fizerem o logoff para irem embora, o próprio AD vai criar as novas pastas de usuários e copiar o perfil dentro delas naquele caminho que voce digitou (lembra? //Servername/Profiles/%username%) .
Desta forma, com a criação automática de cada pasta não será mais necessário (teoricamente) deixar o usuário como administrador.
No meu caso, resolveu apenas parcialmente o problema, pois alguns perfis ainda necessitam ser administradores da máquina local, mas a maioria não.
Se voce tem como, e caso seus usuários não possuam nada importante no perfil, EXCLUA TUDO e comece novamente. NUNCA JAMAIS crie voce mesmo a pasta para seu usuário. Deixe o AD fazer pra voce!
AD = Active Directory
"Usuário com perfil móvel precisa ser administrador da máquina local?"
Todos responderam, "Claro que Não!"
Pois é. Na minha rede precisa. NÃO TEM na TechNet e em lugar nenhum uma explicação para este tipo de problema. A PROVAVEL causa para este tipo de situação inusitada é que ao invés de deixar o sistema criar a pasta do usuário automaticamente, eu criei cada pasta de usuário (são poucas) e copiei o perfil deles para dentro destas pastas.
Antes que alguem possa dizer "Que burro", claro que eu fiz o usuário como proprietário da pasta etc, e tals. Teoricamente tudo estava correto. Mas para fazer funcionar na máquina local o usuário precisa ser ADMINISTRADOR!!
Não adianta colocar usuário avançado, debugger users, etc. etc. tem que ser administrador.
O meu instrutor do Curso de "Administrando Ambientes Windows 2003 Server" me deu uma idéia para tentar dar um "override" neste problema.
Passo 1) Faça todos os usuários darem um login com seu perfil na máquina que utilizam. No perfil de cada usuário no AD, retire a linha que indica o caminho do perfil. Isso fará com que o perfil do usuário se torne local.
Eles fazem um logoff e o perfil é salvo na máquina local. Antes deles fazerem login novamente veja abaixo:
Passo 2) Para os iniciantes, basta selecionar todos os usuários que se aplicam a isto de uma só vez, da mesma forma que voce seleciona vários arquivos, clicando no primeiro, depois segura SHIFT e clica no ultimo.
Clique com o botao direito do mouse, e selecione Properties, digite a linha //ServerName/Profiles/%username%
Legendas:
a) ServerName = Nome do seu servidor onde estão armazenados os perfis móveis
b) Profiles = Subdiretório onde estão as pastas do usuário
c) %username% = isto faz com que seja atribuido o nome de login do usuário. Se o login do dito cujo for tiburcio, digitando %username% será automaticamente atribuido tiburcio no nome da pasta. PRECISA colocar o sinal de % antes e depois.
d) / = backslash ( \ ) . O editor do blog não deixa digitar caminhos
Passo 3) REMOVA todas as pastas de usuário que estão no diretório //ServerName/Profiles precisa remover tudo, caso contrário não funcionará (ao falar remover presume-se que voce é esperto e vai MOVER para uma outra pasta qualquer antes de apagar definitivamente.)
Passo 4) Quando todas as pastas de perfil móvel estiverem devidamente apagadas ou movidas, diga aos usuários para fazerem logon novamente. Eles trabalharão normalmente, e quando fizerem o logoff para irem embora, o próprio AD vai criar as novas pastas de usuários e copiar o perfil dentro delas naquele caminho que voce digitou (lembra? //Servername/Profiles/%username%) .
Desta forma, com a criação automática de cada pasta não será mais necessário (teoricamente) deixar o usuário como administrador.
No meu caso, resolveu apenas parcialmente o problema, pois alguns perfis ainda necessitam ser administradores da máquina local, mas a maioria não.
Se voce tem como, e caso seus usuários não possuam nada importante no perfil, EXCLUA TUDO e comece novamente. NUNCA JAMAIS crie voce mesmo a pasta para seu usuário. Deixe o AD fazer pra voce!
AD = Active Directory
Atualizando Políticas de Grupo na Estação
Pois é. Certo dia, verifiquei que alguns usuários espertinhos estavam usando de alguns "exploits" nas politicas de grupo para fazer as maiores atrapalhadas na estação como instalar Bit Torrent, e ficar baixando música.
Fiz uma atualização na política mas nem a pau que atualizava. Reiniciava o computador, desligava, ligava (tudo isso no horário de expediente! rssrs) e nada. Fucei na internet, e verifiquei um comando chamado GPUPDATE.EXE
Tentei várias vezes, verifiquei a ajuda no GPUPDATE /? mas mesmo assim não funcionava
Mandei um e-mail para meu instrutor do Curso 70-270, Jaime Nagase (http://jimotech.blogspot.com) que respondeu:
Tiburcio e suas peripécias (taí o porquê deste site).. basta digitar GPUPDATE /sync /force.
Pois é. Se o GPUPDATE não funcionar de imediato, nem o GPUPDATE /force, acrescente o comando /sync. Ele vai pedir para fazer logoff e reiniciar a máquina, e a política vai ser aplicada.
Para verificar se a política foi realmente aplicada, utilize GPRESULT.
Dica: Utilize prompt de comando para executar estes comandos.
Fiz uma atualização na política mas nem a pau que atualizava. Reiniciava o computador, desligava, ligava (tudo isso no horário de expediente! rssrs) e nada. Fucei na internet, e verifiquei um comando chamado GPUPDATE.EXE
Tentei várias vezes, verifiquei a ajuda no GPUPDATE /? mas mesmo assim não funcionava
Mandei um e-mail para meu instrutor do Curso 70-270, Jaime Nagase (http://jimotech.blogspot.com) que respondeu:
Tiburcio e suas peripécias (taí o porquê deste site).. basta digitar GPUPDATE /sync /force.
Pois é. Se o GPUPDATE não funcionar de imediato, nem o GPUPDATE /force, acrescente o comando /sync. Ele vai pedir para fazer logoff e reiniciar a máquina, e a política vai ser aplicada.
Para verificar se a política foi realmente aplicada, utilize GPRESULT.
Dica: Utilize prompt de comando para executar estes comandos.
Assinar:
Postagens (Atom)