Planning Exchange 2003 deployment

Interesting features of Exchange 2003 running in native mode are listed below. They should be considered in the planning of exchange organization.

1) Dynamic distribution groups are created based on the results of an LDAP query. Different from static distribution groups that are manually assigned members.
2) Site Replication Service (SRS) is used to replicate configuration information between Active Directory and Exchange 5.5. SRS enables AD to mimic exchange 5.5 directory allowing other Exchange 5.5 server to replicate information to it.
3) Microsoft Exchange 2000 chat service, conferencing service, instant messaging server, key management service, connector for lotus cc:Mail and MS mail connector are exchange 2000 server not support on 2003.
4) Outlook 2003 offline cached exchange mode works with exchange 2003. It stores mailboxes on client in .ost file.
5) It uses RPC over HTTP, therefore supports remote connection over internet.
6) Routing groups can be created that links server connected over slow bandwidth links. Connectors can be defined b/w these groups and cost assigned to them to prefer one over the other.
7) Exchange requires a local global catalog server. It is required for log on, group membership and store services.
8) Offline address lists are supported. These are stored in public folder. Users download the address list data file from a public folder.
9) Free/busy information is used for scheduling meetings.

Centralized deployment means all exchange servers are in a single routing group. Capacity planning tools such as exchange server simulation tool (LoadSim.exe) and Exchange stress and performance (ESP) and Jetstress can be used.

Securing DHCP in windows network

Few of the important pts to monitor and enhance DHCP security in windows network are listed below:

1) Enable 'DHCP audit logging' for each DHCP server. Logs are created in %windir%system32\dhcp directory. Lookout for BAD_ADDRESS entries in the log which may point to IP address conflict or a rogue DHCP server or client
2) Use Restricted Groups feature of Group Policy to enable automatic monitoring and control of modification in membership of DHCP administrators group. Any unauthorized member is automatically deleted from membership
3) Use dhcploc.exe, a windows XP support tool to locate rogue DHCP servers. The tool works by sending a DHCPREQUEST message and getting DHCPACK response as a result. One such tool for solaris platform is dhcp_probe developed by Network Systems Group, at Princeton's University office of IT.
4) Maintain control over membership of DHCP administrators group
5) Windows 2000 and 2003 servers have a built-in mechanism for authorization of DHCP servers. They will only lease addresses to client, after verification from a domain controller that their IP is in the list of authorized DHCP servers

AWstats web reporting tool

AWstats is a free and useful web site statistics reporting tool. Written in perl, it is quite customizable. Some of the prominent features are:

One tool for analyzing web, ftp and email traffic
Can generate reports via command line or as a cgi script. Reports directly generated from command line are limited in layout and features. e.g it doesn't support frames
Allows reverse DNS lookup to get hostnames, where possible instead of IP
Allows restricted access via IP and username
Filtering based on IP, browser and page visited is possible. Regular expressions are supported
Permits filtering of different sections of report
Provides limited customization of web report. Items such as HTML head section, end section, logo and logo link, colors and layout can be modified
Has a extensible plug-in based architecture. Third-party plug-ins, which extend core features are available
It is possible to create new charts by defining rows and columns
Configuration changes can be made easily from a single text configuration file

Automatic restart of veritas application

'OnlineRetryLimit' is the paramter used for restarting failed resource (application) in veritas cluster. By default Veritas does a failover to standby node in case of failure of a critical resource. It does not attempt to restart the failed resource. 'OnlineRetryLimit' forces VCS to attempt to restart failed resource, the no of times, as specified in the parameter. It offlines the whole service group and brings it online again for this purpose. Failover will proceed in case of failure of restart attempts.

Maintenance of veritas cluster enabled app

Maintenance of a veritas cluster service group can be done as follows:

1) Execute /sbin/gabconfig -c -n1 on the active service group node
2) Modify the file /etc/gabtab on the active service group node to reflect as follows:
/sbin/gabconfig -c -n1
3) Freeze the service group by excuting, hagrp -freeze [service_group] command
4) Manually stop the service group application. Veritas cluster will detect the failure but won't perform a failover as the service group is frozen
5) Apply patch or configuration change to the application
6) Manually start the service group application. Veritas cluster will detect the availability of service group in its next monitoring cycle
7) Unfreeze the service group, hagrp -unfreeze [service_group]. Even if veritas hasn't detected the availability of app after manual startup, it won't perform a failover as it waits for the application to come up on its own. Eventually it will detect that application is already live and will update its status

JES installation

Sequence of installation is as follows:

1) Install software including Java Messaging Server, Directory Server, Communication Services Delegated Administrator, Enterprise Web Server, Administration server for web and directory/messaging, directory preparation tool and access manager.

2) Configure directory server, execute directory preparation tool (comm_setup.pl), configure administration server and messaging server.

3) Migrate directory entries from previous version. Execute db2ldif -s o=email on previous version, remove the 13 directory entries and upload using ldapmodify -a.

4) Execute Upgrade5to6.pl to upgrade messaging server configuration. It generates four files to migrate MTA configuration, messaging server configuration, backup groups configuration and mboxlist message store berkely db format.

5) Upload individual mailboxes to the new server