Archive

Archive for December, 2011

Referência de portas–Exchange Server 2010 SP2

December 26th, 2011 No comments

 

Se você possuir qualquer dúvida envolvendo portas TCP/UDP que são utilizadas pelos serviços do Exchange Server, use este artigo como referência:

http://technet.microsoft.com/en-us/library/bb331973.aspx

Winking smile

Share

Post to Twitter

Uma possibilidade para desmascarar delays em aplicações Windows

December 26th, 2011 No comments

 

Reclamações de atraso na resposta de transações SQL, lentidão na leitura ou pesquisa de emails. Problemas bem recorrentes no dia-a-dia das empresas. Muitas vezes você não encontrou a verdadeira causa por uma má configuração de quando ou não fazer logging de timout de disco. Leia este artigo, uma pista na sua investigação pode deixar de ser mascarada após este entendimento:

http://blogs.msdn.com/b/san/archive/2011/08/15/the-windows-disk-timeout-value-understanding-why-this-should-be-set-to-a-small-value.aspx

Winking smile

Share

Post to Twitter

Categories: Troubleshooting Tags: ,

Accepted Domains: Escolha corretamente

December 26th, 2011 No comments

 

Ainda existem muitas dúvidas envolvendo qual o tipo de Accepted Domain eu devo selecionar na criação. Aqui vai a dica:

Authoritative domains: A sua organização TEM conhecimento de cada um dos recipientes do domínio. Ou seja, se a sua organização deve entregar mensagens para este domínio e todos os recipientes se encontram dentro da organização (Mailbox User, Mail-Enabled User, Mail-Contact User). Mesmo que o recipiente esteja em outro sistema de emails, mas existe um Mail-Contact criado na sua organização. Neste caso, a sua organização poderá gerar mensagens NDR caso a mensagem não seja entregue;

External Relay domains: A sua organização NÃO TEM conhecimento de qualquer recipiente do domínio. Ou seja, todos os recipientes encontra-se em outro sistema de emails ou outra organização do Exchange e a sua organização irá apenas redirecionar a mensagem. Neste caso, a sua organização não irá gerar qualquer mensagem NDR, já que não é autoritativa sobre o domínio;

Internal Relay domains: A sua organização TEM conhecimento sobre PARTE dos recipientes do do domínio. Ou seja, parte dos recipientes encontram-se na sua organização e parte em outro sistema de emails ou outra organização do Exchange. Caso o recipiente não esteja dentro da organização, a mensagem será redirecionada através de um Send Connector. Importante salientar que no caso de a sua organização utilizar um Edge Transport, você não poderá configurar este Edge Transport como Source Server no Send Connector que irá enviar as mensagens para recipientes não encontrados dentro da organização para o domínio que está configurado como Internet Relay. Você deverá indicar um Hub Transport como Source Server para este Send Connector e um outro Smart Host senão o Edge Transport. Isso deve-se ao fator de o Edge Transport já estar configurado para aceitar todas as mensagens deste domínio através da configuração feita no Internal Relay Accepted Domain.

Winking smile

Share

Post to Twitter

Melhorando o uso das Transport Rules

December 22nd, 2011 No comments

Guys!

Utilizar atributos do AD (Predicates) otimizará o uso das Transport Rules nas mais diversas situações. Este é um ótimo artigo do Bharat Suneja, diretamente do Exchange Team, em comemoração ao Squeaky Lobster day!

http://blogs.technet.com/b/exchange/archive/2011/09/26/does-your-transport-think-it-s-squeaky-lobster-day-in-your-countryorregion.aspx

 ;)

Share

Post to Twitter

Categories: Exchange 2010 Tags:

Exchange Server cada vez mais orientado e disponível aos provedores

December 22nd, 2011 No comments

Exchange Server 2010
Fonte: computer.co.uk

        Quem diria, ao trabalhar com o Exchange Server 2000, ou 2003 que seria possível um dia efetuar uma implementação em ambientes de provedores, considerando problemas complexos e importantes como billing. Hoje o time de produto suporta totalmente este modelo de implementação, inclusive com guias de implementação abordando escalabilidade, testes, dimensionamento do Active Directory.

        Mesmo sendo um modelo de uso que está longe da maioria dos profissionais de mensageria, a leitura do guia trará uma visão ainda mais profunda do poder multi-cenário que a versão atual do Exchange Server é capaz de suportar:

http://blogs.technet.com/b/exchange/archive/2011/12/06/exchange-2010-service-pack-2-and-hosting.aspx

;)

Share

Post to Twitter

Categories: Exchange 2010 Tags:

RODC Filtered Attribut Set

December 7th, 2011 No comments

 

Sabemos que o RODC possui uma copia somente leitura do banco de dados do DC gravavel, porém somente alguns atributos são replicados para o RODC. Temos uma opção chamada de RODC filtered Attribut Set onde podemos filtrar (não permitir) de forma dinamica que certos atributos seja replicado para o RODC.

Abaixo segue uma lista com os atributos que são configurados no RODC Filtered Attribut Set por padrão:

ms-PKI-DPAPIMasterKeys
ms-PKI-AccountCredentials
ms-PKI-RoamingTimeStamp
ms-FVE-KeyPackage
ms-FVE-RecoveryPassword
ms-TPM-OwnerInformation

Esses atributos que são configurados por padrão no RODC Fileterd Attribut Set, está relacioanado a credenciais de usuários.

Vamos então a um seguinte cenario:

Temos uma aplicação em nosso ambiente que armazena alguns dados no banco de dados do AD, e não queremos que os atributos com informações dessa aplicação seja replicado para os RODCs do nosso ambiente, o que temos que fazer?

Existem duas forma de se fazer isso no nosso ambiente, segue abaixo as duas formas:

1º Podemos inserir esses atributos no RODC Filtered Attribut Set (irei mostrar mais adiante o processo para inserir os atributos no RODC Filtered Attribut Set), com isso os atributos não serão replicados.

2º Marcar o atributo como confidencial (irei mostrar mais adiante o processo para marcar o atributo como confidencial), isso faz com que o grupo Authenticated Users não tenha a permissão de ler os atributos incluidos no RODC, ou seja, se o Servidor RODC for comprometido a conta do RODC não terá permissão sobre os atributos que são marcados como confidencial. Só como observação, no ambiente do AD padrão o grupo Authenticated Users possui permissão de leitura em todos os atributos.

Temos uma outra situação em que um usuário malicioso pode tentar forçar a replicação dos atributos que estão no RODC Filtered Attribut Set, nesse caso se o RODC tentar replicar esses atributos a partir de um DC com Windows Server 2008, esse replicação será negada. Porém se esse replicação for a partir de um DC com Windows Server 2003, a replicação poderá acontecer. Por esse motivo a Microsoft recomenda para que quando utilizar o RODC Filtered Attribut Set, que o nivel funcional da floresta esteja selecionado para Windows Server 2008. Só lembrando que se o nivel funcional da floresta for alterado para Windows Server 2008, não será possivel termos DC com Windows Server 2003.

Sabemos também que quando temos um RODC no ambiente, por padrão ele irá tentar fazer a replicação atraves de um DC com Windows Server 2008, porém um usuário malicioso pode forçar o RODC replicar atraves de um DC com Windows Server 2003, por essa razão é recomendavel que o nivel da floresta seja no minimo Windows Server 2008. Uma outra observação, para utilizarmos o RODC temos que ter pelo menos um DC com Windows Server 2008. Abaixo segue link que explica como essa replicação pode ser feita atravez de um DC com Windows Server 2003:

http://technet.microsoft.com/pt-br/library/cc755310(WS.10).aspx

Existem alguns atributos que não podem ser adicionados no RODC FAS, são os atributos critio de sistema que são fundamentais para o funcionamento do ambiente de AD, um exemplo de atributos criticos estão relacionados com: LSA, SAM, Kerberos, etc.

Agora vamos aprender como inserimos atributos no RODC FAS (utilizaremos um atributo ficticio chamado “Contoso-App-Password”:

1 – A primeira coisa a fazer é determinar o atual valor do atributo searchFlags, para isso vá em Start > Prompt de Comando > e digite o seguinte comando “ldifde –d CN=Contoso-App-Password,CN=Schema,CN=Configuration,DC=<domain> –f en_ldif –l searchflags

2 – O resultado desse comando devera ser o seguinte:

dn: CN=Contoso-App-Password,CN=Schema,CN=Configuration,DC=<domain>

changetype: add

searchFlags: 0

3 – Copie o resultado do comando para um novo arquivo de nome “en-fas.ldif”.

4 – Modifique o novo arquivo “en-fas.ldif” com os seguintes valores, e após salve o arquivo:

dn: CN=Contoso-App-Password,CN=Schema,CN=Configuration,DC=<domain>

changetype: modify

add: schemaUpdateNow

schemaUpdateNow: 1

replace: searchFlags

searchFlags: 640

5 – Digite o seguinte comando para importar o arquivo “en-fas.ldif” que foi modificado:

ldifde –i -f en-fas.ldif

Agora vamos verificar se o o atributo foi adicionado ao RODC FAS corretamento:

1 – Vá em Start > Administrative tolls > ADSI Edit.

2 – No ADSI Edit clique em connect to.

3 – Slecione Schema e clique ok.

4 – Na arvore de console clique em Schema e clique em CN=Schema,CN=Configuration,DC=<domain> container.

5 – No painel de detalhe procure o atributo CN=Contoso-App-Password e clique em propriedades.

6 – Na lista verifique se que as flag RODC_Filtered esteja selecionada. Para colocar o atributo como confidencial, basta selecionar a flag Confidential.

 

Segue abaixo link de referencia:

 

http://technet.microsoft.com/pt-br/library/cc754794(WS.10).aspx

Share

Post to Twitter

Service Pack 2 Exchange 2010

December 7th, 2011 No comments
Saiu o Service Pack 2 do Exchange 2010, e além de adicionar os rollups do Service Pack1 também traz as seguintes features:
Leitura recomendada.
Obs: ainda não fiz a instalação de teste, vou fazer isso hoje a noite.
Abraço a todos.
Share

Post to Twitter

Categories: Exchange 2010 Tags:

Não é possível visualizar anexos no OWA 2003 quando enviados do OWA 2010

December 6th, 2011 2 comments

Fala pessoal, estou meio sumido! Alegre

Segue uma questão que encontrei em um cliente e foi um tanto difícil encontrar referências e KBs a respeito. Segue a descrição.

Cenário:

Exchange 2003 e 2010 em coexistência.

UsuárioA possui mailbox no Exchange 2010 e envia um e-mail com anexo utilizando OWA, para o UsuárioB que possui mailbox no Exchange 2003 e utiliza o OWA 2003.

O e-mail é recebido pelo UsuárioB no OWA, o ícone do anexo aparece, conforme figura abaixo:

image

Porém, quando você abre a mensagem, não há nenhum anexo:

image

 

Causa:

Depois de muito procurar (as vezes é complicado buscar KBs, você se expressa de uma forma e o título pode estar totalmente diferente Alegre ), encontrei um KB da Microsoft relatando a causa, no mínimo estranha.

This behavior is by design and is the result of enabling Silverlight on the Exchange Server 2010 Client Accss Server (CAS).

Se você habilita o Silverlight (da própria Microsoft Smiley de boca aberta) no servidor CAS, acontece isso nesse cenário.


Solução:

Method 1:

Log onto the CAS server with the appropriate Administrator permissions.
Disable silverlight from the Exchange Server 2010 Management Shell using the following cmdlet.

Set-OwaVirtualDirectory -Identity "Servername\Owa (Default Web Site)" -SilverLightEnabled $False

Where Servername is the name of the Client Access Server.  This action must be performed on each Client Access Server in the organization that is used.

Method 2:

Use a client that does not use the Silverlight (e.g., where Silverlight is not installed) to compose the e-mail message.

 

O KB foi retirado da base de dados de conhecimento da Microsoft, segue link original: http://support.microsoft.com/kb/2400041

 

Apliquei o método 1, foi tranquilo sem precisar reinicar nenhum serviço ou mesmo o aplicativo do OWA no IIS:

Set-OwaVirtualDirectory -Identity "Meu_CAS\Owa (Default Web Site)" -SilverLightEnabled $False

Olhem só o resultado:

image

image

 

Abs.

Tiago Ferreira

Share

Post to Twitter