padawan_IT's questions

Primeiro, quero descrever o ambiente:

Servidor:

Windows Server 2016 (mantém a pasta de compartilhamento SMB da rede)

Clientes:

Mac OS X (El Capitan/Sierra), todos os usuários usam isso e têm ACESSO TOTAL à raiz do compartilhamento de rede e todas as subpastas, etc. Eles não estão no domínio, mas usam todas as mesmas credenciais para se conectar aos compartilhamentos de rede. Use um software que não seja compatível com o MAC OS mais recente.

Agora vamos ao problema:

Quando os usuários acessam um arquivo Excel no compartilhamento de rede, eles não podem salvá-lo novamente com o mesmo nome. Eles podem excluir os arquivos, renomeá-los, movê-los, etc. Portanto, agora eles precisam abrir um arquivo do Excel, salvá-lo com um nome diferente, excluir o anterior e renomear o novo de volta para o antigo. Não é super ruim, mas bastante irritante. Outros produtos de software do Office funcionam conforme o esperado (Word, Powerpoint e assim por diante), apenas o Excel causando esse problema.

O que eu tentei/verifiquei até agora:

• Certifique-se de que .temporaryitems na raiz do compartilhamento de rede forneça acesso total aos usuários.
• Certifiquei-me de que ninguém mais estava acessando o mesmo arquivo que eu estava usando
• Função de salvamento automático desabilitada no Excel
• Criação de .DS_Store desativada em compartilhamentos de rede

Qual é a mensagem de erro:

Não foi possível salvá-lo em bla.xlsx, salvei o arquivo como [nome de arquivo hexadecimal aleatório com cerca de 8 dígitos]. (Observação: esse arquivo pode ser encontrado na pasta .temporaryitems)

Soluções que meu chefe não aceita:

• Altere o compartilhamento de rede para cifs ou afp em vez de smb (as razões por trás disso não importam)

Solução alternativa que pensei, mas meu chefe não está muito feliz:

• Criou um compartilhamento de rede (smb) em seu NAS. Funciona perfeito lá. Boss reclama que não será incluído nos backups. Então pensei apenas em criar uma VM no servidor e fazer o backup. Boss concorda um pouco com isso, mas prefere uma solução sem uma solução alternativa.

Posso ter esquecido coisas que tentei, porque as mensagens de erro iniciais e o comportamento de erro eram FUBAR e ajustei as configurações para agora parecerem como descrito acima.

Para sua informação, se eu salvar um arquivo do Excel com um novo nome, posso salvá-lo com o mesmo nome quantas vezes quiser, a menos que feche o arquivo. Depois de fechar o arquivo e reabri-lo, a "diversão" começa.

Instalamos o Office365 (com Exchange hospedado e AD-Sync) na rede de um cliente. Alguns deles experimentam um comportamento estranho de perspectiva. O usuário chega a esta mesa, inicializa seu computador e inicia o Outlook. Em seguida, ele é solicitado a fornecer uma senha. Ele coloca e funciona. No dia seguinte acontece de novo.

Tentamos fechar o Outlook e reiniciá-lo -> não solicitou a senha.

Tentamos reiniciar o computador -> não solicitou a senha.

Limpar o Credential Manager ou desabilitar o modo em cache não ajudou. Alguma ideia de qual poderia ser a origem desse problema? Meu google-fu encontrou apenas um outro tópico com esse tipo de comportamento (avisos uma vez por dia) e isso estava no fórum da ESET sem solução. Também usamos o ESET, mas o problema existe antes de mudarmos o cliente do Kaspersky para o ESET.

Não consigo alterar seu tipo de autenticação em suas configurações. A opção não existe em sua perspectiva. Achei que poderia usar o Kerberos e, após 10 horas (duração máxima de um ticket), solicitaria novamente uma senha.

Os clientes usam o Windows 10 de 64 bits com o Outlook 2016.