If you want to see my LinkedIn profile, click on this button:
I was looking at all of my ideajam.net idea posts today. I decided to make an average.
I have 17 idea posts, with the following votes:
18, 16, 27, 29, 15, 4, 25, -16, 26, -5, 31, 26, 4, 1, 30, 46, and 31
Total Votes= 308
308 / 17 = My Ideajam Average 18.12
I haven’t figured out how to put an ideajam into my wordpress blog yet, so here’s is just the link:
Administrators can use the Domino console command Trace when testing connectivity issues.
For our company this is a useful and frequently used tool. Not all of our sites are connected internally with fat, secure, reliable connectivity lines.
We often switch between Internet and MPLS and sometimes the lines go down.
When testing connectivity from one server to another, or to test connectivity after changing a connection document, you can use the trace command. Read the rest of this entry »
I feel like talking like a cave man because the concept is like starting fire when people start to understand the benefits.
For a long time, I’ve been a pundit of “DON’T USE STATIC IP CONNECTION DOCUMENTS!” Not everyone will listen, maybe because I sound like a radical cavalier consultant admin who knows everything – offering up such new fangled ideas to an organization who does not have a global active directory container or single company-wide DNS suffix.
Here’s why STATIC is so bad: Read the rest of this entry »
We have sites in South America where network connectivity is very unreliable. We have MPLS lines connecting the remote offices in those locations, and we also have Internet access from each of the offices.
When setting up our replication/mail routing architecture in these locations where connectivity is unstable we got a little creative.
First, we have our hub servers in the Home office in Hong Kong. These hub servers do all of the replication from Hub to spoke. This cuts down on the overall replication overhead on the network. The idea is that cluster cache doesn’t have to be rebuilt every time if we have only the hubs replicating to the spokes. At the end of the day, network utilization and time required to replicate is actually lower.
We also put clusters in each site. This alleviates downtime in the event that one of the servers goes down. Since we have clusters, we can set the connection document to replicate with the cluster instead of the individual servers. This provides much benefit because replication still occurs if one server is down. It also reduces the network utilization in half because replication will only occur one time, to the cluster, instead of twice to each individual server. Read the rest of this entry »
We have two hub servers in our environment that are clustered.
We use these as replication hubs to all of our spokes (local and remote sites). Additionally, these act as sort of a mail hub since all of our remotes sites are not directly connected to our home office site. Lastly, they also serve as outbound SMTP gateways.
Any mail that is sent from Chile to a user in Spain gets routed through Hong Kong since their is not a direct connection from Chile to Spain.
All servers in each site are in their own NNN (Notes Named Network). The Hong Kong site servers are in their own NNN. The hubs are in their own NNN.
This allows us to route mail through Hong Kong where necessary using mail connection documents. Read the rest of this entry »
Today while setting up a replication connection between some busy hubs that provide webmail access, route outbound SMTP traffic, and replicate databases, plus are named as the home server for some databases – both clustered
…to a new remote server cluster in America that serves as a mail server, and soon to be webmail server.
I was trying to increase the efficiency of the replication between the busy hubs, the slow network connection, and the remote mail server, so that mailbox replication would be as fast as possible.
The current webmail server is located on the hubs for these remote mail servers (a trick through DNS and the webmail redirect).