Microsoft Exchange and Remote Desktop Services Specialists

SEMblog

Microsoft Exchange Server and
Blackberry Enterprise Server news, views and fixes.

Case Study 2 Part 3 - Network Rebuild - Networking

This is part three of a three part posting of a recent case study.

Part 1 - Part 2

Networking

With all the changes we had to look at the networking. 

Internet Access

With the server in the data centre, the issue of bandwidth over the WAN connection became critical. 

Therefore the client upgraded their line to a 2mb SDSL line, although due to the distance from the exchange, we only get about 1.5mb. 

A second internet connection was also brought in. This is a basic connection which will be used for backup purposes only. In the meantime we have put a wireless connection on to it for use as a guest wireless. No connection to the production network. In the event of a failure of the SDSL line, a cable will be moved to use the backup connection. Not completely automated, but for this client, good enough. 

The servers in the data centre are connected to the production network via a site to site IPSEC VPN. This VPN is managed by pfSense, which sits in a virtual machine. Using the VMWARE virtual switches, the internal servers are isolated from the internet. 

As I wrote in part 2 about the servers, all traffic between the two servers and traffic from the internet goes across the VPN. What this means is that if the primary SDSL link is dropped, then all I have to do is reconfigure the VPN to use the backup connection. No need to make any DNS changes, and data remains under our control. 

All three internet connections - the SDSL, ADSL backup and data centre are covered by OpenDNS to provide a first line of protection against nasty's, but also stopping staff from browsing to sites they shouldn't be. For the guest wireless, the settings are more strict, so that the link cannot be abused. 

Internal Network

A production wireless network was also introduced, using two access points that have covered most of the building. This gives freedom to locate printers and other networking hardware. 

We also used the Windows 7 excuse to remove the last desktop printers, so the only printers left are networked. Although a HP Deskjet 4 which has been recently serviced was reprieved and a Jet Direct card picked up off eBay for £20 meant it was back in action as a network printer. 

When I did the original network I implemented a dual speed network. This is where all workstations are connected to a 10/100 switch, with a gb uplink to a 1000 switch. This was retained. A further switch was put in between the router from the ISP and the software firewall. This allows a machine to be connected to be outside the firewall. 

An APC UPS with a built in network card was also retained, which has more than enough capacity for the two servers and with the APC network tool installed on all the virtual servers, it will shut them down gracefully. 

Network Documentation

The network is documented live through OneNote. An Office 2010 licence has been used on one of the domain controllers which allows access to OneNote. Of course this is replicated live. As changes are made, they can be quickly updated in OneNote. So while the network documentation isn't any kind of formal, well written format, it is in such a way that could allow the network to be rebuilt. 

Did everything go to plan?

Given the size of the job, and the massive change that went through, things went quite smoothly. 

One of the servers was dead on arrival, BT took a while to install the SDSL line, and then more time to get the backup ADSL line to run at a decent speed. 

Printer publishing didn't work correctly, I had to completely redo group policy, the VPN didn't work initially for the clients and I completely forgot about expiring passwords with the roaming users (its been a while since I ran a large laptop fleet). Drive mappings initially worked when they felt like it. 

However overall the client is very pleased with what they have. 

Finally

At the end of 2010, the client's location had issues with access due to the weather. However the replacement network configuration allows all staff with computers at home to work from home, connecting via remote desktop gateway. 

The future

Now this work has been done, we can look ahead. 

With complete control over the entire platform server and workstation side, internal applications can be developed easily. An internal web application is already under development, and I have told the web developer to develop for Internet Explorer 9. It is my intention to implement the new IE 9 jump lists. A Blackberry interface is also under development, as this can be accessed via the BES Express that has been installed. The new Blackberry Playbook is being looked at with some interest. 

This new deployment provides a firm platform for some time to come, while significantly increasing the productivity of the end users. 

Project Conclusion

By making use of VPN technology and the server that has been located in the cloud, we have removed the dependency on any one ISP. This plays a key part in any business continuity, and in the day to day use of remote access for the mobile workers. It also means that as new internet technologies, such as Fibre to the Cabinet become available, those can be easily implemented with very little disruption to the business. 

Crucially though, by using native to Windows and Exchange technologies, the complexity of the network has not increased very much. There is very little proprietary technology in the network, so there is no vendor dependency other than Microsoft and VMWARE.

By using virtual machines, we have removed most of the hardware dependency, so replacement servers could be deployed from pretty much anyone in the event of a significant problem. 

Finally, it just works. Since it went live in late September 2010, it has not provided any major problems.  The business just gets on with what it does. 

Comments are closed