Práticas recomendadas de atribuição de letras da unidade de rede

Question

Estamos trabalhando na migração do Novell para o Active Directory. Durante a transição, vamos avaliar nossos mapeamentos de drives à luz dos padrões atuais para ver se o que estamos fazendo ainda se encaixa, está alinhado com as melhores práticas, simplificar a administração dos recursos, etc. Atualmente, temos 11 diferentes mapeamentos de unidade mapeados. Isso parece, para mim, ser um pouco demais e um pouco confuso para os usuários finais. Esses mapeamentos de unidade também parecem estar relacionados a algumas convenções mais antigas que existiam na organização e que terminaram sendo semelhantes às seguintes:

• K: \ - Mapeamento da unidade de CD-ROM física do servidor Novell
• N: \ - scripts e utilitários administrativos de TI
• S: \ - A pasta base de outro usuário, se necessário
• Mapeamento T: \ - dBase III (esperamos que isso desapareça após a migração)
• U: \ - Projeto ou outros compartilhamentos de grupo
• V: \ - Projeto ou outros compartilhamentos de grupo
• W: \ - Trabalho (compartilhamento de trabalho departamental ou de unidade)
• X: \ - Aplicativos compartilham
• Y: \ - Pasta pessoal
• Z: \ - Volume do sistema

Essa é uma estrutura muito confusa para os usuários, tanto usuários finais quanto de TI, dentro de nossa organização. Gostaria de perguntar sobre as práticas recomendadas do setor e como os outros projetam seus mapeamentos de unidade. Quais são algumas das coisas em que devemos estar cientes e como você compensa ou controla esses itens? Quais são as coisas que devem ser consideradas de uma perspectiva de gerenciamento e manutenção?

Nossos clientes serão o Windows XP, o Windows Server 2003, o Windows 7 Pro e o Windows Server 2008. Mais adiante, gostaríamos de incorporar também clientes Linux e Macintosh OS X (10.6 ou mais recentes) em nossos mapeamentos de unidade.

Qualquer ajuda, ideias, recursos ou links que você possa fornecer seria muito apreciado.

    

Answer 1

Nós enfrentamos essa pergunta exatamente pela mesma razão há um ano e meio atrás. Os principais problemas são três:

1. As redes da Novell são historicamente baseadas em letras de unidades. Todos sabem que a unidade U: é para o diretório pessoal do usuário e S: é para Compartilhada. E assim por diante.
2. As redes da Microsoft são muito menos ligadas a letras de drives e a Microsoft vem pressionando o endereçamento de estilo UNC desde o advento do Active Directory. Estabelecimentos da Microsoft há muito estabelecidos tendem a usar o que estiver disponível para letras de drive, com alguns padrões para aplicativos antigos que exigem uma letra de unidade.
3. Os usuários devem alterar os procedimentos estabelecidos. Eles simplesmente NÃO lançarão letras de drive para o lado em favor dos UNCs e continuarão a ligar para o helpdesk com "O drive Y: está inativo".

Por causa de 1 e 3, ainda estávamos usando letras de drive um ano após a migração da Microsoft. Os usuários estão se acostumando com o UNC abordando algumas coisas, mas nosso volume compartilhado, um volume massivo e monolítico, precisava ser dividido devido a razões de tamanho na SAN. Em vez de forçar todos a lidar com as UNCs, descobrimos como fazer volumes montados no diretório em um cluster.

Se você tiver a opção (como poucos usuários do Mac), o Microsoft DFS pode facilitar bastante as coisas aqui. Crie uma única letra de unidade, com os diretórios de nível superior sendo, em essência, o antigo mapeamento de letra de unidade. Em um ambiente puro do Windows, isso pode funcionar bem. Qualquer coisa que use o Samba, no entanto, não pode usá-lo. Os usuários têm apenas uma letra de unidade, e a mudança de 14 letras de unidade para uma única com caminhos como "S: \ K-Drive \" é muito fácil. Nós temos muitos usuários de Mac, então não pudemos seguir esse caminho.

As letras de unidade que padronizamos em nosso login-script (outra retenção dos dias da Novell):

• P: = O volume compartilhado monolítico
• S: = Volume de trabalho de aula do aluno (o uso diminui lentamente à medida que tudo muda para o Blackboard)
• U: = Diretório inicial
• W: = repositório de software do usuário final
• X: = Certos pacotes de software instalados na rede, principalmente focados em torno do nosso sistema ERP
• Y: = scripts de administração e coisas

Também operamos um registro de letra de unidade em nosso grupo Administrador do Windows. Se uma unidade for mapeada em um script de login, será documentado quem está fazendo isso. Isso poupa muito sofrimento se dois departamentos quiserem mapear uma unidade T: para diferentes lugares e compartilhar a equipe.

Os padrões que posso recomendar são:

• Mantenha as letras das unidades obrigatórias centralmente no mínimo.
• Operar um registro de letra de unidade em seu grupo geral de coordenação de administração
• Se necessário, faça uma auditoria periódica dos métodos de mapeamento de unidade em relação ao que você espera que eles sejam.

Answer 2

Na minha humilde opinião, se você conseguir passar pelo conceito de "cartas de dirigir" ... esqueça-as completamente. Os caminhos UNC podem levá-lo muito mais longe e você não encontrará colisões de nomenclatura. Você também pode querer consolidar seus vários nomes de servidores & compartilha em uma única (ou algumas) raízes DFS. Isso fornecerá um único caminho UNC a ser usado para encontrar qualquer & todos os compartilhamentos relevantes para os usuários ... e fornecem opções para configurar replicação, failover e escalabilidade.

    

Answer 3

Mantenha C: como o volume do sistema. Por mais que eu não acredite que ainda aconteça, ainda acontece onde o software é codificado para instalar em C: (esses desenvolvedores devem ser filmados).

Mantenha os próximos após C: (E :, F :, G :) reservados para dispositivos físicos (CD / DVD, mídia removível, etc.).

Além disso, tento combinar as coisas com o que elas começam (obviamente com graus limitados de sucesso à medida que o número de mapeamentos de unidade aumenta).

H: = Dirigir em casa | P: = Drive de projeto ou Personal Drive
etc ...

    

Answer 4

Eu uso N: para NETWORK. Ele é mapeado para uma hierarquia DFS que abrange servidores multipel em uma estrutura de pastas transparente para os usuários.

Eu uso outras letras conforme apropriado em servidores (X: = dadosa, S = Sql, T = Temp, L = logs - note que isso é para servidores, portanto, TEMP é o dríquete para os bancos de dados temporários).

Os usuários normalmente sempre só veem a única árvore. Existem outras duas por razões tecnológicas (não mapeadas).

    

Answer 5

Utilizamos principalmente a unidade P: para a unidade pessoal do usuário. E um S: drive para compartilhamento de empresa. Essas são as duas principais letras que usamos.

Uma boa prática, já que você estará usando o Active Directory, é usar os Objetos de Diretiva de Grupo para decidir quem receberá uma letra de unidade e quem não será. Você pode definir scripts de login para mapear uma unidade compartilhada com base em um filtro de grupo de segurança.

Por exemplo, você tem um departamento de faturamento que precisa de acesso a uma unidade Q :. Você configuraria um novo GPO que teria o script de login para mapear a unidade Q e aplicaria o filtro de segurança ao Billing_security_group, para que sejam os únicos a obter a unidade Q.

Mais informações sobre a filtragem de grupos de segurança aqui: link

    

Answer 6

Veja meu comentário no post de squillmans.

Em um ambiente que eu suporte:

• H: Homedrive
• G: Drive comum (dividido em pastas para cada divisão)
• I: unidade de TI

etc.etc.

Eu também gostaria de acrescentar que você provavelmente deseja implementar a Enumeração Baseada em Acesso quando for para o Windows. A Novell lida nativamente, mas isso não permitirá que os usuários vejam arquivos ou pastas aos quais não têm acesso.

    

Answer 7

Não mapeie um diretório específico do usuário. Redirecione a pasta "Meus documentos" para um compartilhamento de rede usando um GPO.

Em seguida, faça algumas perguntas comerciais para a empresa. Como as pessoas trabalham, com que tipo de informação lidam em um nível compartilhado / de grupo. Escolha alguns dos grandes (departamentos, clientes, projetos) e mapeie unidades para o nível superior de cada um desses diretórios.