Sunday, December 26, 2010

Exchange Distribution Groups with external email Contacts as member

Sometimes, as vendor I would need to receive important emails sent to end-users; stuff like subscription expiry notifications, licensing renewal etc. Usually these emails are sent to Distribution groups of the end-user's organization.
 
Short of having an email account in the end-user's organization, I would request for my (external) email to be included as a member of such Distribution group. Its pretty straightforward except for the caveat that by default Exchange sets external Contacts to only receive emails from Authenticated senders. This automatically bars email coming from external sources such as Principals, ISPs etc.
 
Following is the PS command for creating an imaginary end-user Distribution group 'Licensing' and adding my Contact 'me@gmail.com' into it as member.
New-MailContact -Name "me@gmail.com" -ExternalEmailAddress "me@gmail.com"

Set-MailContact "me@gmail.com" -RequireSenderAuthenticationEnabled $False

New-DistributionGroup -Name "Licensing" Set-DistributionGroup "Licensing" -RequireSenderAuthenticationEnabled $false

Add-DistributionGroupMember "Licensing" -Member "me@gmail.com"





Thursday, December 16, 2010

Juniper ScreenOS & Fortigate FortiOS revisited 2010

This month, I had the opportunity of installing a Juniper SSG appliance (with ScreenOS) and two units of Fortigate (with FortiOS) for three separate clients. These two firewall brands really bring back interesting memories after years of deploying Watchguard which to date, STILL does not support IPv6 (what does that tell you about Watchguard's development cycles ?).

Checkout the list of IPv6 capable security product's here: https://www.icsalabs.com/technology-program/ipv6/ipv6-capable-security-products

At first look, it seems there's nothing much that have changed on the ScreenOS; I guess maybe most of Juniper's  development efforts were concentrated on the JunOS.

This could either be a good or a bad thing. In ScreenOS's case if it ain't broke, why fix it ?

As one of the first Active/Active capable firewalls that I had the opportunity to deploy, ScreenOS's NSRP is still the same reliable protocol it has always been.

It's Active/Active HA works on the principle of concurrent Virtual Security Groups (VSI) sharing the same cluster ID. Furthermore, it failovers PPPoE links too :)

The only downside is you'd need one IP addresses per Interface; one for each VSI group's interface. That would normally be translated into two IP addresses per HA interface/zone in a production environment.

FortiOS on the other hand works on the principle of Multicast ARP. From a first look, it operates as good, or even better than ScreenOS (maybe not the debugging bit) and you only need ONE IP addresses per HA interface. That simple capability saves your precious Public IP addresses (and end-user confusion) when doing HA on the Public IP segment.

And of course, ScreenOS stubbornly sticks with its trusted PPTP and L2TP as its user-based VPN methods while FortiOS have included all of the above AND SSL-based VPN as well. Mind you this includes SSL Tunnelling (OpenVPN) as well as Virtual Desktop functionalities (Java applet based). How cool is that ?

Maybe I'll try JunOS sometime and see if its worth cost-to-cost with FortiOS :)

Monday, November 29, 2010

Malaysia ISP recursive DNS servers

I've got this list from http://blog.datakl.com/2009/05/dns-isp/ ... 
for a quick reference in the future :)
  • TMnet DNS servers
    • 202.188.1.5
    • 202.188.0.133
    • 202.188.1.4
    • 202.188.0.132
  • Jaring DNS servers
    • 192.228.128.20
    • 192.228.128.18
    • 192.228.128.16
    • 161.142.227.17
    • 61.6.38.139
    • 161.142.2.17
    • 161.142.212.17
  • TimeNet DNS servers
    • 203.121.16.85
    • 203.121.16.120
  • OpenDNS  Server (overseas)
    • 208.67.222.222
    • 208.67.220.220

Monday, April 26, 2010

Upgrading to Exchange 2010

As soon as a new version of Microsoft Exchange comes along, there would be an immediate clamour for an upgrade/migrate request from customers. "Save us from Exchange 2007" they said (probably hoping that Exchange 2010 will be less PowerShell-centric; tough luck).


Its a very typical scenario here in Malaysia as we have assimilated the kiasu-ness that we have only just recently abhored and stuck our tongues at. Thankfully Microsoft have a clear migrate path for 2007 users.
Not so straightforward for 2003 and below users; or for people still stuck with Windows 2003 Server systems.
And realy vague on migration from non-Exchange platforms like Lotus Notes, IMAP/POP3 systems and yuck: Oracle Collaboration Suite :(


Let me be frank. Exchange 2010 is a pretty damn good software; cutting-edge. Better than 2007 and waaaaaayyyy better than 2003 or for that matter 5.5. But do you really need the functionalities that it has to offer or you just need the prestige (and bragging rights on who's running 64bit and who's not)?


- Consolidating MAPI access on CAS roles rather than on Mailbox role servers in 2007 (Public Folders are still accessed directly on Mailbox roles; onus for Sharepoint upgrade path).
- 2 server + 1 load-balancer makes a fully (single-site) redundant system.
- Database Availability Groups replacing the messy Cluster groups (however, there is still an IP resource cluster required for 2010)
- Consolidating CCR and SCR with DAG simplifies failover scenarios. Inter-server or inter-site ? DAG supports it.
- Advent of EWS Managed API which extends Exchange related tasks into PowerShell scripts which works with 2007 SP1 too :)
- Among other performance and database related capabilities.


In my next posts, I would be detailing a more intimate going-ons on the migration works relevant to Exchange 2010.