By Susan Sales Harkins and Gustav Brock

Nothing frustrates the full spectrum of Access users — from casual user to developer — quite like a corrupted database. With a little know-how, you might get lucky enough to repair the database or at least recover the data. Sometimes, a third-party product that specializes in recovering data from a corrupted database can help. But you could end up rebuilding and re-entering data. (Or rather, your replacement will rebuild and re-enter it.)

A more proactive approach to the situation is to avoid corruption in the first place. Here are some strategies for preventing your databases from becoming corrupted.

Note: This information is also available as a PDF download.

#1: Split your database

If more than one person will access the database, split it into two pieces: a backend that stores the data in tables and a front end that contains everything else (forms and reports). Access has a wizard that holds your hand through the process so there’s no excuse not to split a shared database. Name the two ends appropriately. Remember, the backend contains your “gold” — your data. With the data and interface objects in separate databases, you can easily replace the front end from a backup, if necessary. In addition, this setup makes enhancements easier to incorporate into your system.

There is some discussion about whether the front end should be stored on a network server (and shared) or on a local drive. This decision really has no impact on corruption, so the choice is yours. If possible, consider write-protecting a shared front end. If the worst happens and something destroys the front end, simply obtain a fresh copy of it to replace the broken one and reboot the local system.

#2: Store temporary tables in a backend

If a database creates, populates, and then deletes temporary tables, keep those tables in a separate backend database to prevent bloat. Name the additional backend accordingly, making its purpose obvious. This additional backend can be shared or local.

#3: Don’t use memo fields

Avoid using memo fields if possible. They often, indirectly, cause corruption. Even though the database in these cases often can be repaired, some content in the memo fields might be lost. If you need memo fields, keep them in separate tables and create a one-to-one relationship to the parent table(s). Even better, move memo tables to a separate backend database file and name the file accordingly, to indicate its purpose.

#4: Don’t store picture files

Usually, you shouldn’t store picture files in a database. If you must, treat them the same way you would a memo field (see #3). Access has no problem attaching tables from multiple backend databases.

#5: Create temporary tables to speed up queries

If you run complex or nested queries (where one query pulls data from others that hit still others), Access may write a lot of temporary data that you never see. Most often, this happens when a query that works with a small amount of data performs slowly, putting stress on the JET engine. If Access chokes during this process, you can end up with a corrupt backend file.

To prevent this problem, write some of the temporary data to temporary tables. There’s no universal propecia new york method to recommend. Analyze the specifics and run some tests to find the best solution. However, sometimes the use of just one temporary table can minimize the chance of corruption and speed up the queries by a factor of 10 or more.

#6: Be careful with wireless networks (WiFi)

A connection may work fine, but multiple users or powerful neighborhood networks (or other noise sources) can abruptly cut off the connection. That can corrupt the database file if you are writing to it at the time. This type of interference isn’t a problem if users are mostly reading from the database.

#7: Be careful with WAN connections

A WAN connection that covers any connection from a local system to a server via the Internet can cause trouble. Reading the database may be slow but acceptable. However, writing to the database is error prone and can cause corruption. When bottlenecked traffic interrupts data transfer, Access times out, believing the connection has been lost. This behavior usually leaves the backend database in a corrupted state.

#8: Don’t put Mac and Windows users on the same network

If Mac and Windows users share the same network and experience problems, establish a separate network for database users. Macs are extremely noisy, and typical Mac applications generate vast amounts of network traffic when moving large graphics files and printing. In a shared environment, use only high-quality network components.

It’s best to keep the database traffic separate from the graphics traffic, as much as possible. You can accomplish this by allowing administrative workstations to connect directly to the server with the shared database via a local switch.

#9: Troubleshoot network hardware

If corruption just happens from time to time, you may have to deal with a network hardware issue. First, try to narrow down the workstation and swap the error-prone station with another. If the issue follows the workstation, you know that’s the source. It might be easiest to get rid of the workstation.

If the problem isn’t specific to the workstation, the error is most likely to be found in the connection from the workplace to the network switch — including the actual switch port. If the cable’s in good shape, swap the ports between the workstations. If the error source now swaps too, replace the switch; if not replace the cable. If cables aren’t permanently installed or don’t cross from floor to floor, you can try replacing them before swapping workstations.

#10: Check the server’s configuration

Sometimes, the configuration for the server where you’ve stored the shared backend database file is the culprit. You’ll need a specialist to track down and resolve this type of problem. There are several possibilities, from server parameters to a malfunctioning disc controller to a misconfigured RAID array.

You can temporarily move the backend file to a different location, like one of the popular NAS devices or a shared folder on a workstation. If the problem with corruption goes away, call the specialist. If not, the corruption’s source is somewhere else (#1 through #9).

Microsoft Access may not be right for all situations, but it does have its place — at least according to database expert Susan Harkins. Here’s her take on some of the more common complaints she’s encountered from IT pros who like to kick Access around.

---

Until Vista came along, Access was easily the most maligned and misunderstood offering in the Microsoft Windows family. While Vista has earned its reputation, Access hasn’t. It’s true that Access can be a problem child, but with proper discipline, Access performs well and has its place in every organization. Still, professionals tend to spit on the floor when someone suggests Access as a possible database solution.

Note: This information is also available as a PDF download.

#1: It grew!

It’s common to use Access for small, noncritical tasks even if a larger, more robust system is available. Occasionally, an Access database grows beyond its original purpose. After a year or two of use, an Access database can become vital to the organization. It doesn’t happen often, but it does happen. At this point, the IT professional faces a challenge — revamp the Access database or upgrade, and both require a lot of work.

Some IT professionals grumble… the original developer should’ve predicted the future and used a more sophisticated platform. That attitude is counter productive. Successful databases evolve over time. It is difficult to predict, with any certainty, the future use of a database that begins in the lower levels of an organization. Most never move up. They continue to serve their original purpose or users cast them aside.

If an Access database works its way up to the department or enterprise level, celebrate its triumph instead of trashing its creator. After all, if the database evolved and grew, your organization is growing, and that’s good news for everyone.

#2: I have to support what?

Non-programmers create most Access databases. Administrators, managers, assistants, and clerks use Access to store and analyze data, without any help from IT. While the database might get the job done, it’s usually inefficient and difficult to maintain. Invariably, these innovative folks end up calling IT to help resolve a bug or add a new feature. Some IT professionals simply refuse to help, and understandably so. That kind of problem-solving and debugging is difficult and time-consuming.

If the database comes from a company honcho, the IT department might have no choice but to support the database. In an effort to be proactive, some IT departments have banned Access from their organization. Unfortunately, that drastic step doesn’t benefit end users. They’ll use Excel, or worse, they’ll call IT when they need a database. The real solution is to understand how Access fits into your organization.

#3: Access isn’t a professional database

Access has the reputation of being a toy and not a real database. It’s undeserved, but a lot of IT professionals simply won’t use it.

Many Access developers came from a non-programming background. They found a hole and they filled it. Unfortunately, some professional programmers look down their noses at these enterprising folks, and thereby at Access. Despite the snub, Access is the most popular desktop database on the market.

#4: VBA isn’t a pure language

Access uses Visual Basic for Applications (VBA) as its development language. Technically, VBA is a subset of Visual Basic (VB), so many IT pros believe Access has less value than VB. It’s cockeyed thinking because one has nothing to do with the other. Professionals have many tools and they apply them efficiently, if they’re smart. A subset of VB, used appropriately, is no less valuable that VB itself.

#5: It’s too easy

The most ridiculous reason for avoiding Access is that it’s just too easy to use — bul…I mean, rubbish! That’s exactly why the smart professional uses it. Don’t hamstring your organization, support it. If Access can solve a problem quickly, use it, even if the database is just a temporary fix that frees you up to flex your robust system muscles with a real database.

#6: If you build it, something will corrupt it

Admittedly, corruption is one area where Access does drop the ball. Regardless of the source, corruption is a real problem. For some IT professionals, it’s ammunition.

But the truth is, used correctly, Access rarely falls victim to corruption. Unfortunately, the majority of Access users don’t always use it correctly. The debate goes on, but many IT pros simply won’t support Access because of its vulnerability to corruption. To learn how to avoid Access corruption, see 10 ways to prevent Access database corruption.

#7: Money — ’nuff said

Access applications are cheaper to build and maintain than the more sophisticated productions of SQL Server and Oracle. If the Access developer promises a $5,000 project and the SQL Server developer wants $50,000 just to get started, who’s more likely to get the job? That doesn’t mean that Access is the best database for the project, but the SQL Server developer must convince the client that a high-end system and ongoing support are necessary. Otherwise, Access just might rule the day.

#8: Access isn’t an enterprise solution

Most organizations have different levels of responsibility. That level often determines how IT fulfills a need (or if at all). For instance, most databases have one purpose and often, just one user. The database sits on the user’s system and no one else sees it, uses it, or even knows it exists. For these users, Access is a flexible and quick solution. At the top of the organization are the enterprise needs, which are more critical and require more sophisticated and powerful tools. The organization depends on these solutions and they’re usually complex and expensive to develop and maintain.

No one demands that an organization use Access at the enterprise level (although I have seen it used, and expertly so, at this level). So why insist that lower levels use an enterprise database system? It’s an unreasonable demand. Use the right tool for the job, no more, no less.

#9: File-server applications are inferior

Technically, Access is a file-server application and not a client-server application. That means that Access does all its processing on one server. Client-server applications process on both sides of the network. While that propecia muscle growth arrangement is more flexible, it also comes with overhead.

File-server applications aren’t inferior; but they are different. Used appropriately, they’re efficient and capable of outperforming client-server applications.

#10: Access is hard to deploy

Most Access applications need Access, just as an Excel spreadsheet requires Excel. That complicates deployment somewhat. First, Access is a huge application. Second, there are several versions. (I have more versions of Access than pairs of shoes in my closet!) However, if your organization uses Microsoft Office, most of your systems probably have Access installed. On the other hand, upgrades can also be a nuisance, if not outright challenging.

Still, you’re going to run into these problems with any application, not just Access. In addition, if you want to maintain Access and avoid deployment issues, consider turning your databases into Web-based applications. For more on this, see 10 reasons to turn your Access applications into Web-based applications.

#11: Poor security

While most Access developers swear by its security model, the truth is, Access security simply isn’t as robust as you might need. You can password-protect and even encrypt data, but Access doesn’t offer the same level of security as SQL Server. (Unfortunately, the security model isn’t even available in Access 2007.)

A compromised database quickly becomes a problem for IT to solve. You didn’t create the mess, but you’ll get to clean it up. At best, educate users not to use Access for confidential or sensitive data. (Well… you can try.)

Linux makes networking simple and secure — if you know a few tricks. Jack Wallen shares some pointers to help admins knock out various Linux networking tasks with a minimum of effort.

---

Networking is a must-have on all levels of computing. Be it home or corporate, networking is the one aspect of computing that is, without a shadow of a doubt, a deal breaker. And with some help, the Linux operating system can be the king of networking, in both ease of use and security. But that doesn’t mean the average (and sometimes even the above-average) user can’t use some help. These tips should help make Linux networking go a little more smoothly.

Note: This information is also available as a PDF download.

#1: Make use of your /etc/hosts file

The hosts file is used for static host names and offers a quick way to create networking shortcuts. One of the first things I do on a Linux machine is add various machines to the /etc/hosts file. This saves me from having to type a lot of IP addresses. The format of an address for this file is:

For example, if I use one machine for a backup location at IP address 192.168.1.101, I could enter:

Now if I have to connect to that machine, say with secure shell, I can just type ssh -v -l username backups to make the connection.

#2: Keep out unwanted users with /etc/hosts.deny

Yet another helpful “hosts” file is the hosts.deny file. This file allows you to create access control based on client or server names. This is helpful in many ways. You can block blacklist domains from gaining access to your network or you can block certain users from gaining access to certain machines. But no matter how you use it, the format is the same.

Let’s say you want to block the domain bad.domain.name from gaining access to a machine. To do this, open up the /etc/hosts.deny file (you will need either root or sudo privileges) and add this to the bottom of the file:

Save it and you’re good to go.

#3: Let WICD handle your wireless woes

I can’t tell you how many times I have found myself banging my head against a server rack. For the longest time Linux and wireless networking were simply not good bedfellows. But that is quickly becoming a thing of the past. With modern distributions, wireless card detection has become a no-brainer. The issue now is encryption.

Many of the Linux wireless tools have trouble when any encryption is involved. But the WICD tool takes care of this. Now, connecting to WPA or WPA2 encrypted wireless networks is simple. Add to that the amazingly easy GUI employed by WICD and you can check one nasty headache off your list.

#4: Download and install a front end for iptables

You can’t assume that just because you are using Linux, you are secure. You still need some security. And the best security you can have with Linux is iptables. The only problem with iptables is that it can be challenging (especially for the new user). Fortunately, there are outstanding graphical front ends for iptables. One of the best is Firestarter. This front end makes employing iptables a simple process, so you won’t keep bypassing security out of fear of the learning curve.

#5: Get to know the command-line tools

Let’s face it: If you’re running Linux, there might be an instance where you will need to restart your network and you won’t have access to the GUI. In this particular case, knowing that /etc/rc.d/network restart will do the trick will solve your problem. Of course, that’s not the only networking command-line tool. You’ll also want to know tools like dhclient, traceroute, samba, ping, and netstat.

#6: Hard-code your DNS server addresses

I don’t know how many times I have had networking problems that pointed directly at missing DNS server addresses. To this end, I have made it habit to hard-code my DNS servers into the /etc/resolv.conf file. The format of the entries is:

where IP_ADDRESS is the actual address of your name server. You can have as many name servers listed as you need.

#7: Install ClamAV

If you run a mail server, an antivirus is essential. Even though you are running Linux and you know your mail server is immune to 99.9999999% of the viruses in the wild, that doesn’t mean all those clients that download mail from your server are immune. With this in mind, you will make your administrating life far easier if you install an antivirus like ClamAV onto your Linux mail server. It will give you peace of mind and enough security to ensure that your users most likely won’t come knocking at your office door demanding retribution.

#8: Know how to configure an IP address manually

Yes, there are GUI tools for this. And yes, they all work very well. But as you will eventually find if you administer any operating system long enough, it’s never bad to have backup tools to help you do your job. And one of the best backup tools for Linux networking is the ifconfig command. Not only will this command return to you (with no arguments) your network card information, it will also allow you to configure your network card manually. This is done like so:

Of course, you will want to plug in your particular information as it applies to the above.

#9: Get to know your /etc/interfaces (Ubuntu) or /etc/sysconfig/network-scripts (Red Hat/Fedora) file(s)

This file (or files) is where the information for each network interface is stored. The format for this file is:

As you can see above, all of my interfaces are set up for dhcp. This is my laptop, which goes with me everywhere, so dhcp is a necessity. But what if I use the wired interface in only one location? For that, I can hard-code the information here under the eth0 interface like so (for Ubuntu):

Or like so (For Red Hat/Fedora):

Again, you would plug in all the information suited to your network and your device.

#10: Don’t forget smbpasswd when setting up Samba

Nearly every time clients come to me with Samba issues, the problem is that they haven’t added the user and a password with smbpasswd. Without doing this, propecia msd the user will not be able to authenticate to the Samba server. And when using smbpasswd to add a new user, you have to add the “-a” switch like so:

After you hit Enter, you will be asked for the users’ password (twice). NOTE: You must have root access (or sudo) to pull this off.

These 10 quick tips should help make various aspects of Linux networking easier. You never know when you’ll wind up having to rely on the command line or you’ll need to enlist the help of a graphical front end for iptables. Now, if you do, you should be good to go.

Microsoft Access may not be the king of databases, but it does offer a number of advantages over solutions like SQL Server and Oracle in certain situations. Access guru Susan Harkins counts the ways.

---

Nothing starts a fire quicker than saying, “Hey, let’s use Access. Yeah, Access can do it!” Oh my… just thinking about it makes me want to don a fire retardant pocket protector. Seriously, though: Access elicits real passion. Developers and IT folk either love it or hate it. There’s no reason why you should use a tool you hate, but you should strive to use the tool that’s best for the job.

The truly smart and effective IT professional knows that there are many tools. The key is to know which database engine is the best for the job at hand. Why throw massive resources at a simple need? In other words, you don’t want to pay for a Rolls Royce engine if you’re building a go-cart. Knowing when and when not to use Access will help your budget and make you look good, whether you’re a freelance developer or you’re managing IT resources.

Note: This information is also available as a PDF download.

#1: It’s cheap

Access is a desktop database and its place in the hierarchy — layered between Excel and SQL Server — determines its price. Access costs the same as any other desktop application. Acquiring a copy of Access won’t require a loan or a call to investors.

The large client-server databases, such as SQL Server and Oracle, require specific hardware and expensive licensing. After the project’s up and running, a client-server database needs a dedicated administrator. Access requires none of that.

On the other hand, Access is a desktop application. That means that everyone who uses a customized database application needs Access installed on their local system. All those copies of Access can be expensive. One alternative is to invest the time and money it takes to turn your database into a runtime application. (Access 2007 doesn’t support this option.)

#2: It’s easy

Anybody with just a bit of time and reasonable intelligence can learn to use Access. It doesn’t take weeks of classroom instruction and then months of mentored on-the-job training to acquire the skills necessary to create and administer a database. It’s safe to say that most Access databases have one user and they live out their lives on one system. The user generally creates the database in his or her spare time. The casual user with no professional database or development skills can get data into an Access database and then manipulate that data without blowing up the building.

A good database grows and a bad one dies — regardless of the data engine that’s driving it or the skill set of the person who created it.

#3: Development costs less

Many developers make a good living creating custom database applications in Access. (Call me, let’s talk.) However, in general, they charge less than SQL Server and Oracle developers. Moreover, the development costs are just the beginning if you go with SQL Server or some other client-server software (see #1). If you really want to use Access and you’re smart, you’ll see that an enthusiastic and eager employee gets the right training. Then, pass out all that money you save in employee bonuses.

On the other hand, it doesn’t matter how much money you save initially, if you use the wrong database. Don’t let money be your only consideration or you’ll surely regret it. For instance, the security model is minimal (and doesn’t exist at all in Access 2007). Recovery isn’t as easy, either. Don’t use Access for mission-critical applications unless you really know what you’re doing — and even then, it might be a good idea to keep your resume updated.

#4: Prototyping is a snap

Access is a great way to show fast results for the impatient client or boss. You can collect a little data and in just a few hours (or days) wow them with a few neat forms and reports — I can hear them ooing and ahhing already. You don’t have to use Access to build the production database, but you can ease client concerns by showing that you understand their needs. Access lets you get results fast and often with little to no code.

#5: It’s easy to upsize once it outgrows Jet

People who control the purse strings aren’t usually willing to dedicate resources to developing a noncritical database. Most of the time, you’re on your own. However, that doesn’t mean that a good design won’t grow and evolve into a truly useful tool. If that happens, you can upsize an Access database to SQL Server. You don’t have to start from scratch.

Still, Access is limited to 2GB. Even if the database’s purpose isn’t critical, the amount of data alone might force you into the arms of a more robust engine. Realistically, you probably won’t run into that limitation too often. If you do, you can eliminate Jet from the picture and use an Access front end to link to SQL Server data.

#6: It’s a one-time fling

Not every custom database has a long shelf life, but that’s not because it’s bad and dies an agonizing death. Sometimes its purpose is timed. For instance, generating, collecting, and analyzing questionnaire data can be a big job, even for Access, but a single questionnaire has a limited lifespan. If you’re going to use a database once, or for only a short time, use Access if possible.

#7: It can provide a quick fix

The best solution for your needs might be a powerful client-server database such as SQL Server. However, while you’re waiting — and you will wait — how’s the work being done? You can use Access as a quick fix until the more robust version is ready. You’ll have to compromise, because if you really need SQL Server, you’re not going to get the same work done in Access. But you might get portions of the work done. Analyze the overall tasks and see what components you can automate in Access, at least for the time being.

#8: You want to change what?

Access is flexible, and that’s one of its best attributes. Even if you can put a custom database together in a matter of weeks, needs are likely to change. Almost immediately, the user or client will think of something they want to add or change. If you designed the database well in the first place, Access will handle enhancements and changes without complaint.

#9: It talks to Office

Access is part of the Microsoft Office suite, so it plays well with the other applications. Users can quickly and easily export data from or import data into Excel or publish reports to Word. In addition, it shares a similar interface with other Office apps, which helps new users feel more at home and diminishes the learning curve.

#10: There’s less code!

All things being equal, Access can get the job done with less code than SQL Server (or some other client-server database). In addition, VBA is an easy language to master.

#11: It offers connectability

Access offers an affordable solution for individual users and smaller teams. Despite protests from some member of the IT club, you can even use it across a network if you know what you’re doing (file server solutions on a local network).

On the other hand, Access isn’t optimized for the Web. Although a skillful developer can use Access on the Web, in general, it just isn’t a good idea. Jet can’t handle large numbers of simultaneous users, unless of course you really know what you’re doing — and that level of expertise is really closer to magic than development. It can be done, just not by many.

propecia missed dose

From choosing the right physical media and conduit size to pulling cable to making long-term infrastructure decisions, networking two buildings is a challenging undertaking. These pointers will help you effectively plan and execute this type of project.

---

Connecting the networking components of two buildings can be a pretty daunting task. Here’s a little practical advice to help make the process go more smoothly.

Note: This information is also available as a PDF download.

#1: Wireless may not be the best solution

Too often, when a team is contemplating how to connect two buildings, someone will offer a wireless solution. Yes, there are wireless solutions that will connect two buildings, and antenna boosting equipment for better service. However, a hard line connection is more reliable if installed in conduit correctly. Here’s a general rule of thumb: “Use a hard line connection unless you can’t.”

Site-to-site connections using wireless connections are frequently disrupted by an obstruction, weather (in some technologies and applications), or interference. Also, wireless technologies have a shorter lifespan, as replacement technologies are rapidly developing for this market space.

#2: When dealing with conduit, think big

Most building connections today will be a fiber connection in hard plastic conduit. This conduit is usually buried about two feet below the ground. When sizing out what type of conduit to use (even if you’re working with a heavy equipment or installation professional), always think larger than you need.

Consider this example: You can fit the bare cable of fiber optic networking in just about any size conduit. However, if this project is a “one of a kind” type, you may have some price pressure to deliver the best solution for the technology need. When you size up the equipment and supplies, you may require a set of fiber cutting tools to end the line at each point. But the most cost-efficient solution may be simply ordering a to-length fiber optic cable that’s pre-terminated. In this case, you may save a great deal on fiber tools, but you should go up to the next size (and test the entire fit) for pushing a termination through conduit. For a recent project I did, we pulled two SC connectors through 1-inch conduit.

---

Best practice

When pulling fiber through a conduit, be careful with the line. Take the following steps to make it easier on the pull:

---

#3: Go absolute cutting edge for physical media

Thinking for all future connections, select the best physical connection (usually fiber or multiple fiber lines) for what will be buried. You don’t want to have to dig it up or remove this connection once it’s in place. It makes no sense to run CAT-5 over copper when in a few years, you may remove this medium for the backend of most networks.

#4: Call propecia mg before you dig!

Each state has a “call before you dig” service. A simple Google search of Call before you dig Ohio (or any other state) will take you to the site that can give you procedural information, underground line requirements for your state, and other important facts. When networking two buildings, you will want to use orange markings to identify the connection as a communications system. Most locations use orange for all communications media, but check your local requirements before starting any work and arranging your support staff for the project.

---

Important safety note

Digging can be very dangerous, as there are many underground utilities, including gas and electric, that can be deadly. It goes without saying to follow all relevant precautions and enlist the services of heavy equipment and facilities or installation professionals for projects of this nature.

Best practice: When digging, it’s advisable to have a team that’s familiar with operating the necessary equipment to help you lay the conduit. A ditch digger may seem like a fun tool, but enlist your facilities maintenance staff or others more suited to operate this equipment.

---

#5: Run extra media through the conduit

While you’re there, you may want to tag on an extra line or two. For example, if you plan to connect two buildings with a fiber connection, run an extra fiber and maybe a few CAT-5 lines as well. These extra lines may come in handy later. You can group relevant categories of connections in the conduit freely. You can’t, however, run power through these lines–no mixing communications and power types. PoE (power over Ethernet) may be considered a power conduit instead of a communications conduit if you seek to pair it with another type.

#6: Leave a pull string in the conduit

In case you decide to pull another type in the conduit in the future, leave a pull string (even high test fishing line does well) in the conduit. Simply tape it to the header of the piece you’re pulling through and when you feed your fiber or other type in, also feed the pull string.

#7: Avoid the telco whenever possible

If your buildings aren’t very close together, you may not be able to avoid a telco for the connection. But in short-distance situations, you might be able to work out arrangements with local authorities and property neighbors to coordinate the installations of private conduit. If the two buildings are fairly close, it may be worth the effort and higher initial cost to get a private conduit instead of the ongoing cost of an ISP or carrier service.

#8: Think below protocol layers

When designing the basic objectives of your connectivity project, don’t think in terms of VLANs and IP addresses at first. You want to establish your connectivity in a way that extends your manageability to the highest level, so focus on Layer 1 and Layer 2 of the OSI model. Who knows, we may dump TCP/IP in a few years anyway for something better, if IPv6 is not well received. You may also consider using WAN protocols for efficiency or segregation on this connection instead of simple TCP/IP configurations.

#9: Share Internet connection points

The last thing any IT department wants is an additional monthly payment, so be sure to keep your Internet connection points centralized where possible. Ensure that your networking configuration allows you to manage the access by the different geographical locations (buildings), by user, or by some other manageable mechanism. Also, having two connection points (one in each building and a LAN connection between the buildings) poses a security threat of multiple entry points. However, a case can be made from a disaster recovery or business continuity perspective to have a backup carrier connection in another building, yet accessible.

---

Best practice

Be sure that the Internet traffic, or any other traffic, is throttled, cached, or otherwise managed from a QoS perspective if there’s a large number of clients or a lot of traffic in the other connection point.

---

#10: Make long-term infrastructure decisions now

For the network clients in the second building, make decisions about the local name resolution, file server storage resources, e-mail servers, and authentication/directory servers that may be local to the first building. Should the second building involve a small number of clients and less traffic, you may not want to have a true data room there. You can simply extend the back-end services from the primary building. But if the second building will double traffic to your server room–and possibly over a limited-speed connection–you may need to make some of those resources central to the destination.