How NIMS™ Was Deployed for
Tens of Thousands of Students
at the University of Kentucky and
Embry-Riddle Aeronautical University
www.novell.com
Matt DeFoor
Directory Engineer
University of Kentucky
mattd@uky.edu
University of Kentucky at a Glance
• Facts
 Public,
land-grant university
 Enrollment (FTE)=32,584
• Includes Lexington Community College
 Home
of me, mattd@uky.edu (and a few others)
 Shoes optional
The “Education” of Novell Internet
Messaging System™ (NIMS)
•
•
•
•
•
•
•
•
•
•
Brief history of e-mail at the University of Kentucky (UKY)
Proposal to implementation
Design of UKY NIMS system
Design of separate NIMS tree
Design and implementation of DirXML™
Customization—templates and software
Problems, pitfalls, and ways to avoid them
Leveraging Novell eDirectory™
Summary
Questions and answers
Brief History of E-mail at UKY
• IBM mainframe
• cc:Mail
• Sendmail and Qualcomm’s Qpopper
Request for Proposals to Replace
Aging Sendmail and POP Service
• Proposed system requirements
 POP,
IMAP, web access
 25 MB quota per user
 Directory-enabled
 Calendar support
 Scan mail for viruses
• Timeline
 First
proposal—February 2001
 NIMS approved for implementation—April, 2001
 Production deadline—August 4, 2001
Mail Systems to Be Replaced—or Not
• All centrally supported mail systems
 IBM
mainframe
 Campus POP server
 UNIX mail for students in engineering labs
• System not to be replaced—Microsoft Exchange
 Needed
for “power users”
Proposal Accepted
and Real Work Begins
• Deadline: August 4, 2001
• UKY Mail Team
 The
NetWare® group (NIMS admins)
 Graphics people
 PR people
 Old mail system admins
 Meetings, meetings, meetings
• By the way—NIMS v3 wasn’t released yet
Spec and Order Hardware
• Five Dell PowerEdge 6450
• Dual 700 Mhz XEON Processors
• 4 GB RAM
• 18 GB RAID1 system drives
• Two Dell PowerEdge 2550
• Dual 1Ghz Processors
• 2 GB RAM
• 18 GB RAID1 system drives
• Dell SAN—1.6 TB of usable space
• PowerVault 660F
• Three PowerVault 224Fs
Design of UKY NIMS System
• Distributed messaging architecture
 Flexible
 Redundant
 Scalable
 More
complex
Initial Design of UKY NIMS System
• Initial production environment
 Windows
NT 4.0 server running McAfee SMTP
WebShield 4.51
 One NIMS SMTP server
• Also running POP3D for legacy clients
 Two
“client” access servers: POP3D, IMAPD, ModWebd
 Two back-end servers connect to SAN for access
to mail store
Initial Design of UKY NIMS System
(cont.)
Initial Design and Implementation
of UKY NIMS System
Volume configurations
SMTP, SMTP1, CLIENT1, and CLIENT2
4 GB SYS volumes—RAID1; 64 Kb block size; block sub-allocation = on
12 GB SPOOL volumes—RAID1; 64 Kb block size; block sub-allocation = on
NMAP1 and NMAP2
4 GB SYS volumes—RAID1; 64 Kb block size; block sub-allocation = on
12 GB SPOOL volumes—RAID1; 64 Kb block size; block sub-allocation = on
800 GB PV volumes—RAID5; 64 Kb block size; block sub-allocation = on
Current Design and Implementation
of UKY NIMS System (cont.)
• Production environment
 Two
SMTP servers running Antivirus Agent
• Also running POP3D for legacy clients
 Two
“client” access servers: POP3D, IMAPD, ModWebd
 Two back-end servers connect to SAN for access
to mail store
Current Design and Implementation
of UKY NIMS System (cont.)
Current Design and Implementation
of UKY NIMS System (cont.)
Volume configurations
SMTP, SMTP1, CLIENT1 and CLIENT2
4 GB SYS volumes—RAID1; 64Kb block size; block sub-allocation = on
12 GB SPOOL volumes—RAID1; 64Kb block size; block sub-allocation = on
NMAP1 and NMAP2
4 GB SYS volumes—RAID1; 64Kb block size; block sub-allocation = on
12 GB SPOOL volumes—RAID1; 64Kb block size; block sub-allocation = off
800 GB PV volumes—RAID5; 64Kb block size; block sub-allocation = off
Tree Structure Design
• The file/print tree [UKY] is the result
of a distributed design run amok…
courtesy of Gary Porter
• We could have leveraged our existing Tree,
but we didn’t feel comfortable
 One
wrong move by a local admin could
seriously affect mail delivery for 44,000 users
Dynamic vs. Static
Tree Structure Design
(cont.)
• Dynamic
 The
UKY Tree is a dynamic tree where servers
are added and removed, schema is extended
and partitioned and replicated across campus
and some WAN links
• Static
 Static
tree—one where the addition of servers,
schema extensions, and partition operations
were limited and under our control
Dynamic vs. Static
Tree Structure Design
(cont.)
So the plan was simple…we’ll have a separate Tree
and sync the two with DirXML…no sweat*
* “No sweat!” is a trademark of UKY
Separate Tree for Mail System
• Ergo…The One True Directory [TOTD]*
 This
is an inside joke among NIMS admins
 Active Directory is referred to as the savior of our
supposed directory problems—even though it only
has a few thousand users and [TOTD] has over 43,000
 The [TOTD] tree is used for everything from web page
authentication to VPN access to RADIUS
authentication
• Oh, did I mention that they can use the same userid
and password to access each of these services?
* [TOTD] is a trademark of UKY
TOTD Tree Structure
• TOTD design and structure
 Consists
of six servers
 NetWare 5.1 SP3 + various patches
 Pure IP
 Novell eDirectory v85.12a
TOTD Tree Structure
(cont.)
TOTD Tree Structure
Standard security container
(cont.)
TOTD Tree Structure
Server objects
Volumes objects
LDAP group and server objects
(cont.)
TOTD Tree Structure
Contains administrative objects,
e.g., postmaster, groups, etc.
(cont.)
TOTD Tree Structure
(cont.)
Group objects
used for aliases
TOTD Tree Structure
Approximately 44,000
hashed objects—serviced
by two different NMAP
servers
(cont.)
TOTD Tree Structure
(cont.)
NIMS Messaging
Server Objects;
Parent Objects;
Templates; Mailing
Lists
TOTD Tree Structure
(cont.)
• Partitions



Three servers hold a partition of [ROOT]
All servers hold a partition of UKY and Internet services
Three servers hold a partition of DirXML DriverSet
Sync TOTD with UKY
DirXML—How We Did It
•
•
•
•
•
•
•
Learn DirXML
Learn XML
Learn XSLT
Determine what attributes to sync
Configure Filters
Write custom Create Rules and Stylesheets
Novell Consulting—validate DirXML
implementation
• No Sweat!™
Plan for Moving Existing Mail to NIMS
• Develop software to move…
 Existing
mailboxes
 Existing aliases
 Existing forwarding
• Test the migration
Develop Custom Operational Software
• Keeping things user-friendly
 Form-based
login for WebAccess via SSL
• Perl program to perform actual login from web form data
• Revise program to handle WebAccess session cookie
(introduced with NIMS 3.0 RC2)
 Form-based
change password page
• Perl program to affect password change from web form data
Customized Form Login Page
• Ease of use
• Provide information on
the login form page
• Redirect to our custom
pages on failed logins
• Log in via SSL, then
redirect out of SSL
• Public templates
weren’t available
Customized Redirect Pages
Customized Redirect Pages
(cont.)
Customized Password Page
• NIMS


NIMS requires login to
WebAcess/WebMail
Confusing if SSL is required
• Custom




Always performed via SSL
You can implement
password restrictions
Doesn’t require MobWeb
to change the password
Easier to use
Population and Maintenance
of NIMS Users in eDirectory
• Perl program to automatically add users from
campus User Account Management System (UAMS)
• Perl program to push pre-populated calendar file
to each user
• Perl program to handle deleted accounts
 Aging
before removing mailboxes and mail directories
• Web front-end to IMSAudit data
Web Front-end to IMSAudit Data
Web Front-end to IMSAudit Data
(cont.)
Customized WebAccess Template
Customized WebAccess Template
(cont.)
Customized WebAccess Template
(cont.)
Customized WebAccess Template
(cont.)
•Example of pre-populated Calendar entry
Customized WebAccess Template
•Example of pre-populated Calendar entry
(cont.)
Problems, Pitfalls
and Ways to Avoid Them
• Modweb/WebAccess
 Limit
your end-user expectations
• WebAccess/WebMail is your thin friend,
not your fat client
• PR will be your friend
 Don’t
let bad PR
give you a black eye
PR Do’s and Don’ts
Do
Don’t
• Tell your users about
• Tell your users you are moving
the new system
• Tell your users of the
to a new system one week
before the changeover
• Tell your users—who all use
benefits of the new system
the POP protocol—that they
must go to IMAP
• Tell your users they now have
• Make them believe this is now
web access to their mail
• Come up with a catchy name
for your new mail system
the only mail access they have
• Have a stupid name like
U-Connect@UK
Problems, Pitfalls
and Ways to Avoid Them
• Antivirus gateway (a problem before NIMS 3.02b)
 McAfee
Webshield SMTP for Windows NT
 Doesn’t support S/MIME attachments
 Malformed messages would cause the queue
to stop processing
 Obsolete because of antivirus agent
Using NIMS to Leverage NDS at UKY
• NIMS (TOTD) tree design recap
• Using TOTD tree for wireless authentication
• Using TOTD tree for campus software download
authentication
• Using TOTD tree for authentication only
(no e-mail)
 Simply
disable mail access in IMS configuration
page of NWAdmin
Monitoring NIMS
• Babymon

Monitors NIMS agent connectivity

Monitors abends
NDS
Other OS problems
• ZENworks for Servers (ZfS)


• Multi-router Traffic Grapher (MRTG)





CPU utilization
Messages received
IMAP, Modweb and POP connections
Kb transferred
NIC statistics
Monitoring NIMS with MRTG
Monitoring NIMS with MRTG
(cont.)
Monitoring NIMS with MRTG
(cont.)
Monitoring NIMS with MRTG
(cont.)
NIMS Resources and Errata
•
•
•
•
•
•
•
www.nimsinfo.com
www.myrealbox.com
Nimstalk@nimsinfo.com
Nimsdev@nimsinfo.com
novell.support.collaboration.internet-messaging-system
www.perldap.org
Multi-router Traffic Graffer (MRTG)
 http://people.ee.ethz.ch/~oetiker/webtools/mrtg/
gear up,
rope in,
and climb on
wiN
big
with Novell
Provisioning
solutions
pick up your entry card today
at the
Novell
Provisioning
table
in the
one Net solutions lab