June 04, 2008 | Comments: (0)
Hone Active Directory for efficiency before deploying Exchange 2007
An efficient Active Directory topology is a must if you're planning to deploy Exchange 2007. Unlike its predecessors, the latest version of Exchange doesn't use Routing Groups to handle messaging traffic; rather, it works directly off of the existing AD infrastructure. Fortunately, achieving the level of AD efficiency you need has become far easier, thanks to the much-improved Knowledge Consistency Checker (KCC).
KCC first saw the light of day in February 2000, when Microsoft released Windows 2000 and offered admins the ability to connect remote sites together under one structure: Active Directory. To assist in that task, Microsoft added a behind-the-scenes algorithm to the structure: the Knowledge Consistency Checker.
KCC was promoted as an automatic site topology builder for monitoring physical connections between sites and subnets. Moreover, it was celebrated for forming logical connection links that included a replication schedule and site link costs -- that is, the costs to connect two sites based on connection speeds and bandwidth utilization.
This automatic manager of site replication for AD seemed too good to be true -- and it was, in fact. KCC was criticized for being a poor algorithm, and hence administrators ended up creating their own manual links and costs.
Some time later, according to administrative legend, a mathematical wiz took the algorithm apart, enhanced its capabilities, and gave it back to Microsoft. In fact, in 2004 InfoWorld's previous Enterprise Windows author Oliver Rist wrote, "For enterprises with an increasing number of branch offices or other remote locations, check out 2003's KCC (Knowledge Consistency Checker). Under Windows 2000, you were asking for trouble by attempting to connect more than 100 sites to a central server farm. KCC, however, has been reworked to handle well above 200 sites with no complaints whatsoever."
And so KCC now really is a valuable facet to your AD replication. If you haven't already done so, consider eliminating the aforementioned manual links and allowing the new and improved KCC to resume its responsibility over the AD site topology. Greg Shields, author of the book "Windows Server 2008: What's New, What's Changed" explains that "the KCC automatically applies link costs as part of what it does naturally. In all but the very largest of environments, you should never need to modify anything having to do with the KCC at all."
Using KCC to make your AD topology more efficient is a good start toward deploying Exchange 2007. However, prior to deploying even the first Exchange server, you should officially document your physical sites and subnets and note the current physical and logical links between these sites. Document the site link costs as well. Once you have things documented you want to look for ways to improve your overall infrastructure for superior AD replication topology.
One other enhancement you want to consider before deploying Exchange 2007 is the addition of Global Catalog servers in every site. These are Domain Controllers that retain a copy of every AD object. From an AD perspective, they assist in the logon process and in the search procedures for objects. From an Exchange perspective, they assist in the sending and receiving of mail. So, access to a GC is essential in your Exchange 2007 environment, and one per site is a best practice.
Jumping slightly to the future: You've enhanced your AD infrastructure and deployed your Exchange 2007 servers. Now you wish to make some changes to your messaging environment and perhaps even change those site link costs that KCC calculated.
Why would you want to change those costs? Well, suppose a message has to travel from Site A to Site D. There's no direct connection physically (or logically) but the message can go through Site B or Site C. The route choice is made by adding up the site link costs from A to B to D and the costs from A to C to D. The servers will choose whichever costs less.
There are times, however, when you may feel that you should manually intervene and select a more expensive route; for example, you may not be pleased overall by the speed of messaging based upon costs that are set on the AD side (and perhaps those costs are not functional because they were manually created, rather than making use of the KCC).
In some cases you may be an Exchange admin who doesn't have control over your AD environment. However, you still have the ability to alter the site link costs for your Exchange messaging. There are two ways to change these costs. If you change them within the Active Directory Sites and Services tool, it will be altered for both AD replication and Exchange replication traffic. If, however, you wish to make the change only for the Exchange side, you can open PowerShell and use the set-adsitelink cmdlet to create a new cost link for Exchange messaging only. You can read a full article on this here.
Now, even if you don't use Exchange (in any form, 5.5, 2000, 2003 or 2007) but you have an AD infrastructure in place, it behooves you to ensure greater efficiency, which still leads us back to the KCC, a free piece of Active Directory that may not be utilized in your environment.
Posted by J. Peter Bruzzese on June 4, 2008 03:00 AM
May 11, 2008 | Comments: (0)
Microsoft Response Point: A phone system for the small business
Sometimes, small business seems to be neglected in many offerings that Microsoft provides. True, the Small Business Server is an attempt to fill those needs, and you may want to take note of the two 2008 items set for a release later this year. But at times, there is needless complexity in these solutions, and they show a lack of insight into the small-business world, in which companies need to focus on their core competencies, not the nitty-gritty of technology.
So it was interesting to take note of a product that has some of the high-end features of Microsoft Unified Communications Server (UCS), but without the price tag and the complexity.
Response Point, an alternative to traditional PBX solutions, is an in-house phone system that includes a base station and "traditional looking" phones with Windows XP Embedded (XPe) technology. You can add up to 50 phones, and easily bring on or remove users. InfoWorld recently reviewed the product.
One point made in our review is that certain features are missing, such as presence. Personally, I don't see this as such a negative. True, the concept of "presence" seems to have been in every communication tool since IM or ICQ -- but so has the concept of presence evasion. I usually set my Skype to invisible to avoid unnecessary calls. However, the lack of this feature is a minus for those in a small business who rely on it heavily.
From a technical perspective, the base station (which can currently come from one of three different vendors: Quanta, D-Link, and Aastra) acts as a router between your external phone line and internal network. One quite intuitive application can be installed for managing the addition and configuration of new users, and the phones can be easily plugged into an Ethernet connection. Truly, anyone in your office who can set up a home network has the skills to establish a Response Point system. The system is VoIP based and uses the SIP protocol, which is becoming increasingly more utilized in Microsoft offerings (case in point: Communications Server).
On the Response Point site, you'll find one demonstration that shows an impressive feature for small businesses: the automated assistant, which can handle speech recognition and voice navigation to allow for call forwarding and voice mail. It even has the ability to offer simple information, such as your company's fax number. In addition, there's a Response Point directory, which can also work directly with Outlook contacts.
Pricing from the vendors mentioned above depends on the number of phone units you need, but a starter package with the base kit and five phones goes for roughly $2,500, with additional phones running about $150 each. What you won't have to purchase are the heavy Microsoft servers that allow for Active Directory, Exchange, and so forth.
Apparently this model is working for the Response Point team; it's gotten such positive feedback that the group is hiring and looking for others interested in "small business telephony."
Caution: Response Point is an interesting product and one worth investigating, but small businesses need to do just that: investigate. There are other solutions on the market, many that have a greater level of maturity (being around for longer than a year or version 1.0), such as TalkSwitch. In fact, Kevin Selkowitz, a small-business consultant and blogger from Seattle, paired up Response Point and TalkSwitch and gave his confidence over to -- well, read the comparison to find out.
Posted by J. Peter Bruzzese on May 11, 2008 10:31 PM
February 14, 2008 | Comments: (0)
VPN Concentrators: IPSec vs SSL
I remember the days when you could set up dial-up modems and have users connect to your NT 4.0 Server using Remote Access Service (RAS). Combining multiple modems in a multilink to increase bandwidth … it seems so long ago, but it was only about a decade or so.
With the Internet, we had the ability to create a VPN, providing a secure connection for users dialing in to their ISP from wherever. As time has passed, the need for greater security over these VPNs has increased. Unfortunately, small businesses usually have a limited amount of funds and/or IT expertise. But that doesn't mean they should ignore the need to secure their VPNs properly. A VPN concentrator -- ideal when you require a single device to handle a large number of incoming VPN tunnels -- may be just what they need.
VPN concentrators typically arrive in one of two architectures: SSL VPNs and IPSec VPNs. Some concentrators only offer support of one protocol or the other, whereas Cisco and other vendors advertise the ability to utilize either with their concentrators.
The traditional tunnel for VPNs relies on IPSec, which resides at the network layer of the OSI model. At this level, a client is considered a virtual member of the connected network and can pretty much access the network as if locally connected. Therein lies a positive aspect of IPSec: Apps run without any awareness that the client is coming from outside the network. The drawback is that additional security controls have to be configured to reduce risks.
For a client to access the IPSec VPN, it must have the client-side software configured. While this adds security, it provides additional cost to implement and leads to additional time and energy spent by tech support. This is what leads many toward an SSL solution.
SSL is already built in to the capabilities of pretty much all computers through Web browsers. Thus, there is no additional work to install and configure the client side. In addition, rather than residing at the network layer, allowing access to all aspects of a network, SSL lets admins allow access a bit more precisely toward applications that are Web-enabled. In addition, admins can establish a finer level of control over uses with SSL VPN connections.
On the negative angle, however, being that you can only utilize SSL VPNs through a Web browser, only Web-based applications will work. With a little bit of work, you can Web-enable additional applications, but this adds to the configuration time and may make SSL an unattractive solution for some.
In addition, SSL applications will not have centralized storage, shared access to resources (like printers), or files and other options that you can achieve through an IPSec connection. Some worry about Web caching with private information being left behind. Thus, you might want to choose a VPN concentrator that lists within its feature sets "automatic cache cleanup after session termination to ensure privacy of data," as the NetGear SSL device does.
So, what do you use and why did you decide to go with that solution?
Posted by J. Peter Bruzzese on February 14, 2008 06:43 PM
October 31, 2007 | Comments: (0)
I got a call from the fine folks at Maxell the other day. It seems that they're promoting their second annual "Fall Backup" day on Nov. 2 -- an attempt to encourage people to practice good backup hygiene, and of course to encourage them to buy lots of Maxell backup media.
"We're just trying to create general awareness of the need to back up," Al Dripchak, the manager of technical support at Maxell, told me. Considering how many small and medium enterprises just flat-out ignore backup best practices, he'd seem to have his work cut out for them.
It's not like there's any lack of cautionary tales out there about what happens if you don't check your backups and your media. The State of Alaska's Department of Revenue had a memorable episode reported in March, when a failed backup -- and an inadvertent wiping of not one but two disk drives -- left the agency with a massive data re-entry task that cost it over $200,000 in extra labor. While that Windows server will probably never miss a tape change again, there's still a vast untapped reservoir of exposed data out there waiting to be zapped by nature, software failure, a happy little malware infection or user error.
Most of what Dripchak is preaching is pretty much common wisdom in the sysadmin world -- daily incremental backups and weekly full backups on servers, at least bimonthly backups of desktop systems, depending on whose desktops they are. It's just a matter of getting the data on the media. The problem is that while that sort of thing is largely automated in most large enterprises (at least as far as critical servers go), it seems like the last thing many smaller and mid-sized enterprises want to deal with.
Of course, when someone says "backup," Microsoft is probably not the first word that comes to mind -- unless you're thinking about the things you have to worry about backing up. Microsoft's main claim to the mindshare of those blessed with responsibility for storage management and disaster recovery comes from all the Exchange, SQL Server data, SharePoint and Office application data that needs to be backed up, archived, policy-processed and restored. Microsoft has long been in the demand-creation business for data protection, but it's not exactly a household name in data protection itself.
Now, it's true that Microsoft Vista has an archival system built in, called Volume Shadow Copy Service, built right in, which Randall Kennedy recently raved about. But as far as business continuity goes, Microsoft's offerings have made life easy ... for third-party developers of backup software to make a living.
But Microsoft is starting to change that a bit. The company announced its latest version of its entry into that market earlier this month: Data Protection Manager 2007 R2. While it had some basic saving graces -- such as self-service for users who lost files -- the previous version of DPS 2007 didn't support the aforementioned Microsoft applications that create all the backup angst in the first place. DPS 2007 R2 is due out before the end of the year ... just in time for the end-of-year archiving.
Posted by Sean Gallagher on October 31, 2007 03:00 AM
October 23, 2007 | Comments: (0)
While on one hand Microsoft has been rattling legal sabres about Linux's infringements on its intellectual property, it seems like the company is finding ways to find a middle ground--and they usually involve money. Novell's agreement with Microsoft, which allowed for a technology exchange and protected SuSE and its users from claims by Microsoft, infuriated many in the open-source community. Now Microsoft has reached a similar agreement with Japan-based Turbolinux.
That, coupled with Microsoft's settlement with the EU over antitrust violations, has created an opportunity for Microsoft and for Windows in the enterprise. First of all, Microsoft can assure some level of compatibility with Linux servers running in its corporate customers' infrastucture, making their lives easier. At the same time, the EU agreement could still put money in Microsoft's pocket from royalties on the sale of Linux distributions and other licensing payments.
Strangely, it's a win-win, because Linux has never really cut that deeply into Microsoft's Windows installed base. Rather, it's taken away market share from Unix, making Windows number one on the server. And Linux has also driven more adoption of Intel-compatible commodity hardware in corporate infrastructure. By making it easier for customers to make Linux work with Windows clients and servers, and by embracing certain elements of what Linux has achieved, Microsoft still ends up ahead in the long term. Why? Because if Microsoft makes money off of Linux, and invests in making Windows a better alternative to Linux, Linux becomes the Windows gateway drug.
There are plenty of applications that Linux makes more sense for than Windows, and vice versa. And just as Sun and Microsoft were forced to sit down and talk by their major customers--Steve Ballmer and Scott McNealy all but admitted customers like General Motors browbeat them into coming to the table over directory services issues--Microsoft is now going to find that it's in the best interest of Windows to have a more compatible Linux in the enterprise.
Posted by Sean Gallagher on October 23, 2007 11:35 AM
October 13, 2007 | Comments: (0)
The Windows URI exploit: Whose Bug Is It, Anyway?
Microsoft is fixing a well-known bug in Window XP and Windows Server 2003 that has been at the root of vulnerabilities. The bug relates to the Uniform Resource Indicator (URI) handler in Windows that allows you to launch other programs to support a clicked link.
Previously, Microsoft had blamed bugs related to the URI call on sloppy coding in the programs that use the call. The argument had been that the software using the call should actually check to see if the thing being clicked is a valid URI, and not some attempt to execute arbitrary code.
It seems like a perfectly rational position, on the surface. Windows is just the messenger, so why kill the messenger? But with so much of the functionality in much of the software we use every day now based on Windows system calls of one sort or another--either in the name of developer productivity or for better integration into Microsoft's millieu---software developers on Windows have become extremely dependent on the underlying platform to handle basic tasks.
That kind of dependency is why we end up having to test patches so thoroughly before we deploy them. And that, in truth, may be why Microsoft's team has been so reluctant to patch this one -- the interdependencies on the URI handler across all of the software someone in a networked office uses is unknowable. It's not uncommon for developers to take advantage of a certain slushiness in a function call like the ShellExecute() function that's at issue here to finesse application functionality in ways unexpected by Microsoft (or anyone else), because developers are clever (and often half too clever for their own good).
Microsoft relented on Thursday, and announced that they'd fix the thing. But I'm betting the patch will need some serious review by IT staffs before it gets pushed out to system.
Posted by Sean Gallagher on October 13, 2007 06:34 AM
October 03, 2007 | Comments: (0)
Microsoft has been edging its partners and third-party developers toward the software-as-a-service (SaaS) model for some time. But now, what amounts to a simple rebranding of the company's existing on-demand software offerings may end up pulling the rug out from under some of those partners, or at least irritating them. And it's up in the air whether large customers will line up for Online.
The SaaS model has been pretty well proven by the likes of Salesforce.com. And over the past two years, Redmond has been pushing and prodding partners to provide SaaS and managed infrastructure services on its platform. And the company has been successful at providing the ammunition for online services like MySpace.
At the same time, Microsoft has been testing the waters with its Live services, targeted at small businesses and individuals -- essentially a re-wrapping of Hotmail and some other collaborative and web hosting services, which has been mostly below the radar of Microsoft's enterprise ISVs, and practically everyone else. They were also offering Exchange, SharePoint, and Office Communications as hosted services
Now, Microsoft is reorganizing its services offerings under a new brand for bigger businesses. Microsoft has a slight advantage over some other competitors in the world of "on-demand" applications like Google Apps- in that it could theoretically more easily migrate existing Exchange customers to a hosted (or hosted-on-site) Exchange service. And the flexibility of on-demand licensing in Microsoft's Server Provider Licensing Agreement would allow customers to drop and add users on a monthly basis--not a minor consideration if you're looking to expand Exchange or SharePoint or Office Communications usage for a project and don't want to permanently buy more seats.
Sure, e-mail and collaboration are not considered core differentiators for most companies--which makes them ideal targets for SaaS. But the real question is whether Microsoft can manage to provide the level of service that enterprises expect without passing off the grunt work to the customers' IT staff?
So far, Microsoft's Live services have been a bomb in the consumer and small business sector. Just ask former Microsoft blogger Robert Scoble: Microsoft's services so far, er, stink. A reshuffling of deck chairs around two new brands doesn't change the fact that the company has really not executed its Internet-based services well, and the bad smell emanating from its consumer offerings may waft over toward anyone considering the Online services.
Posted by Sean Gallagher on October 3, 2007 10:28 AM
TOP STORIES
ADDITIONAL RESOURCES
- Remote Access: Maintain Security and Decrease the Burden on IT
- Beyond AntiVirus: Symantec Endpoint Protection
- What Every Enterprise Needs to Know About VDI
- Disaster Recovery in Minutes
- Protecting Microsoft(R) Applications
- Reduce Recovery Times and Tape Costs
