MicromissionS

Microsoft has just released the Beta version of the new Exchange server 2010 with code name “E14”.

Exchange 2010 comes with new features and improvements:

1.    Improved Storage Reliability: E14 has brought new 70% I/O reduction, with new architecture the fail over designed around the mailbox database level instead of Server level “known as DB mobility”; which enable Organizations to run High-Available Exchange environment without dealing with clustering, RAID Disks or Enterprise disks solutions (SAN).

2.    MailTips: no more over-quota email message sent accidently.

3.    Conversation View.

4.    More internet browsers support for OWA.

All of these and will continue…

One of the important security issues is to keep the internal resources hidden and unknown from outside.

Received: from Internal-FQDN-NAME-1 ([PUBLIC-IP-ADDRESS]) by bay0-pamc1-f5.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2444); Fri, 03 Apr 2009 10:40:14 -0700

Received: from Internal-FQDN-NAME-2 (INTERNAL-IP-ADDRESS-1) by Internal-FQDN-NAME-1 (INTERNAL-IP-ADDRESS-2) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 03 Apr 2009 20:40:50 +0300

Received: from Internal-FQDN-NAME-3 ([INTERNAL-IP-ADDRESS-3]) by Internal-FQDN-NAME-2 ([INTERNAL-IP-ADDRESS-1]) with mapi; Fri, 03 Apr 2009 20:42:12 +0300

In Exchange 2007, by default “ANONYMOUS LOGON” has “Send Routing Header” permission granted on the all send connectors, and this is the key subject.

If we remove “Send Routing Header” permission from “ANONYMOUS LOGON” on the Internet-Send-Connector, then all of the information about the internal server will be removed from the message header.

ADSIEdit.MSC -> CN=Configuration -> CN=Services -> CN=Microsoft Exchange -> CN=”Organization Name” -> CN=Administrative Groups -> CN=Exchange Administrative Group -> CN=Routing Groups -> CN=Exchange routing Group -> CN=Connections -> CN=”Send Connector Name”

By running the command below the “Send Routing Header” permission will be removed from “ANONYMOUS LOGON” on the Internet-Send-Connector:

Get-SendConnector “Connector Name” | Remove-ADPermission -AccessRight ExtendedRight -ExtendedRights “ms-Exch-Send-Headers-Routing” -user “NT AUTHORITY\Anonymous Logon”

Noting that the “Microsoft Exchange Transport” Service have to be restarted in order to get effective.

I don’t know why I did not find it anywhere as part of the pre-migration process; because if you have it, your installation of mailbox role will keep failing.

While Microsoft keeps saying the LDAP filters are supported in Exchange 2007, but you cannot edit them from Exchange 2007 console, if you try migrating to Exchange 2007 mailbox role, and if you have Recipient Policy or Address List that is configured with LDAP filters you may experience:

Error:

The Exchange server address list service failed to respond. This could be because of an address list or email address policy configuration error.

The service can’t work properly because Email Address Policy ‘CN=NAME,CN=Recipient Policies,CN=First Organization,CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=DOMAIN,DC=COM’ has an invalid filter rule (PurportedSearch). The error is ‘ANR is not supported.’. Use the Exchange Management Console to correct this problem. New users, contacts, and groups won’t be fully provisioned until this is fixed.

That because not all LDAP filters are supported in Exchange 2007. In Exchange 2007 new OPATH filters replace the old LDAP ones, so before migrating the mailbox role it is very important to make sure of the LDAP filters used in the Recipient Policies & Address Lists are compatible with OPATH ones.

One of the best security practices is to host the Edge Transport role in a isolated zone, but it needs to communicate with the internet and the Hub Transport.

Edge Transport / Hub Transport subscription is designed to have one way trust relationship in a way that Edge transport trusts the internal Active Directory, and here is the rules:

For Hub Transport:

· SMTP “TCP port: 25” traffic to/from Edge Transport.

· Outbound Secure LDAP for EdgeSync “TCP port: 50636” traffic to Edge Transport.

· DNS “UDP port: 51” traffic to an internal DNS (Hub Transport must be able to resolve the Edge Transport).

For Edge Transport:

· SMTP “TCP port: 25” traffic to/from HUB Transport and to the internet.

· Inbound Secure LDAP for EdgeSync “TCP port: 50636” traffic from HUB Transport.

DNS “UDP port: 51” traffic to an internal and external DNS (Edge Transport must be able to resolve the HUB Transport and the external MX records).

While I am in the process of mail system migration to MS Exchange 2007 SCC, I faced two problems to setup the failover clustering for Windows Server 2008.

With Background:

· Clustering nodes: HP Prolaint DL 380 G5

· Shared Storage: HP EVA 4100

This environment did not pass the validation test, each time the test ran the result end with two errors:

Found duplicate IP address IPV6IPADDRESS on node NODE1-FQDN adapter Local Area Connection* # and node NODE2-FQDN adapter Local Area Connection* # Microsoft Failover Cluster Virtual Adapter

Cluster Disk 0 does not support Persistent Reservation.

After about 2 days of research I found that the duplicate IP address problem is raised because of “Teredo” interface is enabled. Teredo is IPv6 tunneling technology over IPv4, it is technology intended home users, It enables NAT traversal for peer-to-peer applications, Teredo is not intended for use in enterprise or any server environment, Teredo uses a static IPv6 address that is consistent across all machines, and because the address on all nodes is the same the Validate wizard detects it as a duplicate IP Address. Teredo is disabled by default on server installations. There may be something about my environment that enabled it; since I don’t need it I disabled it.

To Turn Off Teredo:

1. Open Device Manager

2. Click View, then Show Hidden Devices

3. Under Network Adapters find “Teredo Tunneling Pseudo-Interface”

4. Right Click and select Disable

Additional instructions to disable Teredo

So ran the validation test again with one problem still raised the Persistent reservation.

Windows 2008 uses Persistent SCSI reservations. The SCSI Reserve command and the SCSI Persistent Reserve command are specified by the SCSI standards. Servers can use these commands to prevent HBA ports in other servers from accessing the LUN, This prevents accidental data corruption that is caused when a server overwrites data on another server, This is why you can add your disks to both nodes before the cluster is configured, The Reserve and Persistent Reserve commands are often used by clustering software to control access to SAN Volume Controller virtual disks (VDisks), If a server is not shut down or removed from the server cluster in a controlled way, the server reserves and persistent reserves are maintained, This prevents other servers from accessing data that is no longer in use by the server that holds the reservation, In this situation, you might want to release the reservation and allow a new server to access the VDisk, If you ever had a node in a cluster hang and not failover to other nodes in the cluster this will help by letting a different node force access to the disk and allow failover.

After that the good news my SAN solution support Persistent Reservation, just by choosing “Microsoft Windows LH” as host type, and if it is not listed we can choose custom type then type in the custom type field the following HEX number 00000004198009A8.

After all validation test has been passed.

Two days ago my stuff experienced a dead CAS server because of poor hardware. The recovery process is to bring new box install OS with same name of the dead one then install Exchange 2007 CAS role, but when trying to install Exchange 2007 CAS on the new machine it keeps raise

The Exchange Server is in an inconsistent state. Only disaster recovery mode is available.

With some research I found that the Active Directory still contains information about the dead server, so this information must be removed; by mean of Active Directory Service Interfaces (ADSI) Edit (Adsiedit.msc) navigate and delete object of old CAS

CN=Configuration, DC= Domain Name, DC=com, CN=Services, CN=Microsoft Exchange, CN=Organization Name, CN=Administrative Groups, CN= Exchange Administrative Group, CN=Servers, CN=%Server Name%

Then run Exchange 2007 CAS installation and it completed smoothly.

It is very important for us when we plan to deploy any sensitive service such Exchange 2007 roles we must put the hardware quality and performance into consideration to avoid such a disaster.

My client asked me to if it possible to upgrade his Windows-2000 DC which host Enterprise Root CA, in order to upgrade all DCs in the his network to Windows 2003…

So I started the task by deploying a new Windows 2003 DC, then I installed a new CA in the while on the old DC backing up CA database and its logs in addition to the private key, and exporting the CA registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

So now we have a complete backup of the old CA service, on the new machine, and we have now the new CA installed now we have to proceed into the second step of the migration.

Now suspend CA service on the old box, and restore CA service on the new box, by importing the registry keys –don’t forget to rename CAServerName value to the new server name under-

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\%CA-NAME%

Now the new server is ready to import CA DB, by finishing this process you can kill the old CA service from the old server.

To make this happen, you first need to prevent Exchange users from sending e-mail to the Internet: 

1. Create a new mail-enabled group in Exchange that will be used to identify all users who have this restriction. 
2. Add any users to have incoming mail restricted to this group. 
3. Create a new SMTP Connector on the Exchange server and associate it with the appropriate Exchange server. 
4. Under the Delivery Restrictions tab of the connector’s Properties, add the created group to the “Reject messages from:” section.

Now, you need to configure Exchange to prohibit users from receiving Internet-based e-mail:

1. In Active Directory Users and Computers, go to the Properties page for the group (or individual user) for which you want to restrict e-mail access. 
2. Under the Exchange General tab, click Delivery Restrictions. 
3. Check the box labeled “Accept messages: From authenticated users only.” 
4. Click OK to close all dialogs.

The “authenticated users” checkbox is new to Exchange Server 2003, and essentially limits mail traffic to only those who can successfully authenticate with the server (i.e., other Exchange users).

Today a client complained that he has low performance server & DNS problem on his Exchange server, so huge number  of the following-described log with different destination email addresses were logged in the event viewer

A non-delivery report with a status code of 5.4.0 was generated for recipient rfc822;XXXX@ZZZZ.YYY (Message-ID  <n[20).  
Causes: This message indicates a DNS problem or an IP address configuration problem  
Solution: Check the DNS using nslookup or dnsq. Verify the IP address is in IPv4 literal format.
For more information, click http://www.microsoft.com/contentredirect.asp.

After checking the server it was cleared that there is no DNS problem and the DNS is configured properly… but what the logs in the event viewer are and how they are logged in this huge number…

When I looked into the description I found that the email addresses are not appear to be legit, so I realized that the server was attacked by NDR attack because the SMTP miss configured as Open-relay, so I applied exactly MS-KB909005  http://support.microsoft.com/default.aspx?kbid=909005

But why this problem raised, whish address how it is very important to make sure from our server configuration and making sure to hardening the services hosted on the servers

Many times I was asked about dynamic VLAN and how it works.
It is known that VLANs can be a powerful tool for reducing unnecessary broadcast and multicast traffic, but when changing hosts locations or to connect them to other switch, you’ve got to make those changes manually on the switch in case of using static VLANs. With Dynamic VLANs, the changes are made - how else?
- Dynamically.

Dynamic VLANs are implemented using VLAN Membership Policy Server “VMPS”.
VMPS makes VLAN membership to be based on the source MAC address of the connected machine to switch port.