March, 2008

Mac vs. PC - Round 1

It’s about time that I got around to this one, and if any of you have been wondering which side of the argument I might come down on, you might be disappointed to find out that I sit firmly on the fence on this issue. I’m a firm believer that both platforms deliver on their particular strengths, and both are outstanding tools which are helping us all to become more productive. If I didn’t believe that, why on earth would I have spent the past 15 years purchasing and supporting both platforms?

However, don’t mistake my middle of the road stance for a lack of conviction, because I do have some very strong feelings about the issue itself - in fact, I have a huge problem with the argument itself. I’ve never seen a real definitive study of our industry, but I would suspect that somewhere around 75% of advertising firms operate the same way that we do, supporting both platforms. Of the remaining 25%, I would venture to guess that the majority are Mac-only shops, with a small handful of PC-only shops.

I’ve heard all the arguments. “The Mac is a toy.” “PC’s crash all the time.” Take your pick, because you can find plenty of people out there willing to scream that their favorite system is the best, and the other system is garbage.

The latest round of Mac ads certainly don’t help, and I cringe every time I see them. Yes, they’re clever. Yes, they sell computers. But are they accurate? In my opinion they’re not even close to the truth. Apple, as well as most of the Mac evangelists, are still making arguments against Windows 98. Sure, they talk about Vista in the ads, but if you want to discuss stability and security, it’s difficult to deny that Windows has improved considerably.

I’ve been running Windows servers for over 10 years, going all the way back to Windows NT. The platform has been remarkably stable. Have I seen blue screens - certainly I have, but they have been few and far between. I have Windows servers which have run for years without anything other than a reboot for updates. At the same time, I’ve also seen plenty of my Macs crash - perhaps even more frequently than our PCs. I’ve heard the argument that the reason our Macs crash is because they’re working harder than our PCs. It’s not easy pushing around all those graphics files. No, it’s not, but by the same token it’s not easy doing what an Exchange server does - and they don’t crash. Earlier versions of Windows have been full of security holes, but here’s an interesting article on Mac security which appeared today - http://www.crn.com/hardware/207000418.

Even in writing this, and attempting to defend one platform, I find myself falling into the trap of bashing the other. That’s not my intent, but it’s nearly impossible to avoid the trap. The Mac has proven to be a superior machine for working in a graphics intensive environment. I’ve seen the benchmarks, and these machines truly are tuned for doing what they do best. I would not even begin to entertain the thought of switching.

I buy Macs. I buy PCs. I take the attacks from both sides personally. If the Mac side is correct, then I must be foolish for purchasing PCs. If the PC side is correct, then I must be foolish for purchasing Macs. The fact of the matter is, both sides are wrong. Both platforms serve their purpose, and they serve it well. I woudn’t even compare this argument to Ford vs. Chevy. It’s more like arguing that sports cars are better than pickup trucks. They serve different purposes, and they both do their job well.

I’m sure I’ll return to this topic again and again, and I welcome your opinions no matter where you sit on the issue. I’m going to try to take the high road and avoid bashing one platform in defense of the other, but I also plan to speak openly about the shortfalls of both systems. We’ll see how it goes.

Our EqualLogic Experience So Far

We’re currently in the process of configuring our very first EqualLogic storage unit. It’s a model from their PS Series, and it gives us a total of 6.5 terabytes of storage in a RAID 50 configuration. We’ve only had it live for about a week now, but we love what we’ve seen so far.

The ease of setup and configuration are light years ahead of what we had on our old fiber channel SAN. While our old SAN provided plenty of storage, configuration and management always seemed to involve a call to our vendor, and even then things never seemed to go smoothly. Based on a few days with the EqualLogic unit, I’m reasonably certain that the calls to the vendor for hand-holding are going to be few and far between.

Besides the ease of use, some of the things we love include the ability to utilize what EqualLogic calls thin provisioning. This enables us to create a 500 GB volume while only using 50 GB of actual drive space. The host OS sees a 500 GB volume, but we’re only using 50 GB on the SAN. As the space begins to fill up, the space used on the SAN also begins to approach the 500 GB allocation, but it gives you a way to actually allocate more space than you have initially. Obviously, this is a feature that you want to be careful with, because overuse could result in the SAN actually filling up on you if several of these thin provisioned volumes filled up at the same time. The unit provides plenty of warnings to alert you as these volumes approach a level of your choosing.

The snapshot feature is another feature which we are learning to love. When you provision a new volume, you can simply choose to save snapshots of the volume at whatever interval you choose. Want a daily snapshot for backup purposes? No problem. Want to snapshot a volume prior to an update? No problem. The snapshots are differential copies, so they take up very little space. Any one of these snapshots can be mounted as a physical volume used to quickly restore individual files or an entire volume if necessary. Here’s a real life example- currently we have a thin provisioned volume which is taking up 96 GB of actual disk space (the host OS sees it as a 500 GB volume), and we have taken 10 daily differential snapshots of this volume which are currently utilizing 1.36 GB of space.

Obviously, the unit also provides all kinds of built-in redundancy, with dual controllers, power supplies, fans, and 14 total disks. Short of lengthy power outages or losing the entire server room, not much is going to take this product down. We’re just scratching the surface of what the box will do, and we have plans to do a lot more with it. In the coming months we’ll migrate our VMWare and Exchange storage to this unit, and we also plan on utilizing the snapshots and replication features into our evolving disaster recovery strategy.

What to Write

I guess I’m beginning to get the hang of this blogging thing, and I appreciate the feedback I’ve received so far. There are times when it’s a bit of struggle to decide what to write about, and there are other days when the topics tend to write themselves. As I wrote in my first post, there are several things which make IT in the Advertising business unique, but I sometimes find it difficult to keep my posts strictly to those topics/issues. (As a reminder, those issues are our people and the nature of our work, the platforms, and the storage needs.)

Here are some of the other items which I think are worthy of blog topics in the coming weeks, in no particular order:

• Supporting the CEO
• Web 2.0 - what it means to our Industry in general, and IT in particular
• Virtualization
• Living on the “Bleeding” Edge
• Collaboration
• Microsoft OneNote
• Consumer-oriented Devices - PDAs/MP3 players/Wireless
• Why “Looks” Matter - issues with Intranet adoption and user acceptance

In the meantime, I’d love to hear from those of you out there who are paying attention, and ask you if there are other topics of interest, whether or not you are in this particular line of business. I’m also curious as to whether or not the issues we face in advertising truly are unique. For example, I know there are others out there who also struggle with storage.

With regard to my original premise of the three unique issues, I do plan on discussing storage in my next post. We’re in the process of installing and configuring our first EqualLogic PS Series storage unit, and so far we are very impressed. Stay tuned.

Instant Messaging vs E-Mail

How many of you are currently utilizing Instant Messaging as a legitimate business tool in your organizations? We’re currently planning an implementation of Microsoft’s Unified Communications system, and their IM product – Office Communicator forms the center piece of this offering, providing information about user’s presence. I’m finding that selling Instant Messaging into our organization is not going to be an easy sell, and trying to sell the Microsoft version of it makes it even tougher.

As it turns out, our latest acquisition is an office which was already utilizing Microsoft’s Windows Live Messenger in their day-to-day business. They are thrilled over the fact that we are considering the adoption of a tool they are already using, and they would protest long and hard if we attempted to remove it from their systems. When I asked them why they chose the Microsoft client instead of a more popular product such as AIM, they told me that they actually preferred the fact that the Microsoft client was less widely accepted – and it actually made it easier to sell as a legitimate business tool. This new group of users is actually turning out to be my biggest ally in terms of selling it to my own company. Beyond that argument, it’s fairly easy to make the case in terms of Communicator’s enterprise level capabilities, including integration with Microsoft’s other products and the ability to control and manage it via Group Policy, but those arguments tend to get lost on either users or management.

One of the things I’ve been asked is how is IM different from e-mail, and I actually think that particular question is a very telling one. My users have a great deal of difficulty understanding why they would ever use an Instant Messaging tool for the simple reason that we’re already using e-mail in that fashion. The point they are missing is that we have been misusing e-mail over the past several years, and that e-mail has already become an IM tool in our business. The expectations surrounding e-mail have become so unreasonable that many of our users can and do use it as a chat tool. E-mail conversations routinely happen in real-time, and people actually get upset when an e-mailed question isn’t answered immediately.

I suspect that one of the first steps I need to take in selling the idea of IM to my users is to break them of their bad e-mail habits. If we don’t do that, then they are correct in that they don’t need a separate IM product. The question is how exactly do you break these current e-mail habits? It’s obviously going to take a concerted effort in terms of re-educating our users, and I fully expect that to be a real battle.

Streaming and the NCAA Tournament Coverage

What better day to discuss the issue of streaming audio/video than today? With the NCAA Tournament upon us, and CBS offering up every game at no cost, there will undoubtedly be more than a few of our users who decide to spend the afternoon keeping track of their bracket selections.

We’ve tried blocking this type of traffic in the past, but any such efforts on our part have not lasted long. The reality of our business is such that we need to ability to view or listen to streaming video/audio in order to do our jobs. We have Public Relations and Public Affairs people whose jobs require them to monitor local and national media for breaking stories. We have Creative and Account Service people who routinely use YouTube for viewing the latest commercials created for both our own clients and our competitors. As a result, any efforts to block this traffic have been short-lived.

We’ve tried monitoring tools, using both software and/or hardware to attempt to keep tabs on streaming in order to cut down on the non-productive uses (today’s basketball games would be a great example). The problem with monitoring is that it can get expensive. We’ve got 5 different external pipes we’d have to monitor, so any appliance-based solution would require 5 pieces of hardware to monitor all the access points. Furthermore, it requires somebody to watch things, and none of us really have the time to sit at our desks and monitor real-time streaming. When we have done this sort of thing, generally the only time we check is when we’re hearing complaints about things being slow. Today might be an exception, but at the moment we’ve basically given up.

I’ve always resisted the urge to have IT personnel act as “cops” when it comes to these types of productivity issues. We do have a policy against non-business use which covers this type of thing, but as far as actively monitoring, I’d much rather have my guys spending their time fixing things and finding ways to increase productivity than acting as a high-priced police force. If we can find some ways to monitor things without breaking the bank, great but otherwise we’ve got better things to do. Personally, I feel very strongly that it’s the job of management to keep tabs on their own personnel, and I think it’s a bit of a cop out for folks to expect IT to do that job for them. If an Account Executive is wasting their time watching basketball games or viewing non-work related videos on YouTube, I would expect that to be reflected in their job performance. IT might be called in to verify that type of activity is occurring, and I’m perfectly ok with that. I just don’t believe that we should be the ones bringing productivity issues to the attention of managers. It should work the other way around.

How does your company handle these types of issues? Do you monitor? Are you doing anything special with regards to blocking the NCAA tournament coverage?

Unifying Communications

One of the things our company prides ourselves on is our collaborative nature, so the concept of unified communications is especially attractive to us. It’s one of those buzz words you can’t escape lately, and it’s coinciding with our own need to integrate another office into our infrastructure, and it’s driving us to take a fresh look at how we communicate internally.

We took our first run at Unified Communications when we installed our current phone system. Unfortunately, we had barely gotten the effort off the ground when we encountered issues with new versions of Outlook and Internet Explorer. The unified messaging and unified communications apps were breaking down on us before we could even get users trained, and our vendor was telling us the solution was to delay upgrading our Microsoft apps. Since the drive to Internet Explorer 7 was largely driven by desire for increased security, we decided to give up on our initial attempt at unified communications. Furthermore, the unified messaging and unified communications apps themselves added another layer on top of what we were already using, and learning yet another app was not high on anyone’s list.

When I first heard about Microsoft’s entry into unified communications, the idea of using our existing apps and e-mail server for delivering these services had a great deal of appeal to me. We’ve been exploring this option for the past 6 months, and so far we like what we’ve heard. When we added a new office location recently, the final piece of the puzzle may have fallen into place. In the past, integrating a new office into our infrastructure meant that we pulled their phone system out and installed a new system which was compatible with our own. It was expensive and disruptive. The promise of being able to integrate different phone systems into a common telecommunications software back-end offers some huge advantages to an expanding company. Whether the reality lives up to the promise remains to be seen, but it certainly seems to be worth a look.

Stay tuned because we’re just getting started on this path, and I’m sure it will make for some interesting stories in the coming months.

The iPhone – an Enterprise device?

Now that Apple has announced the long-awaited SDK for the iPhone, I thought it would be a good time to discuss mobile devices. We’ve had a policy restricting employees from purchasing their PDAs/Phones and tying them into our network, but over the past 5 years we’ve still managed to reach the point where we’re currently supporting 3 different platforms/devices (Palm, Blackberry, and Windows) .

We certainly didn’t wake up one day and decide that it would be a good idea to support three different mobile platforms. In fact, from what I’ve seen and heard, we arrived at this point like many others have done. A senior manager or CEO shows up on our doorstep with a new device and says “make this work” I envy those of you who are able to successfully fend off all of these requests, and I would note that we do manage to deny more requests than we approve.

I’ll actually take responsibility for introducing the 3^rd platform, which was Windows Mobile. I was never particularly fond of adding Blackberry or Goodlink servers to my environment, so when Microsoft added push capability to the Exchange servers I already owned, I jumped in with both feet. Don’t get me wrong, the Blackberry and Goodlink servers are both good products, but given the opportunity I’m more than willing to eliminate the middleman. I also find the provisioning process to be much simpler on the Windows platform. We’re currently in the process of phasing out a Goodlink server which supports the Palm devices, so soon we’ll only be supporting two platforms.

Which brings me to the iPhone, and I’m certain that our phasing out of the Palm platform and Goodlink will coincide with our phasing in of the iPhone as an Enterprise platform. In my mind, the recent announcement of ActiveSync support for the iPhone seals the deal in terms of our supporting this platform. We’ve already got several senior managers using the iPhone, and they’re actually content to access e-mail via Outlook Web Access. Once we can deliver push e-mail directly from Exchange, I can’t see any reason not to use this device as an option for mobile e-mail, particularly in our business. I’m thrilled that it’s going to work directly with Exchange. We’re signed up for the beta, and I look forward to testing this as a mobile option for our organization.

Office (and File) Moves – Part 2

Perhaps the single biggest issue we encountered during our office move last weekend had more to do with moving files than it did with bringing a new office onto our network. Furthermore, this particular issue was one which we’ve encountered before, and it was also one for which we didn’t have a readily available solution. In a nutshell, we ran into major problems attempting to move or copy Mac files from a UNIX server onto our new network and a Windows server.

I’ve run into this problem in the past, and it’s never fun. The problem lies with the ability of Macs to use characters not allowed by Windows, characters such as the slashes, bullets, and parentheses. When you run into hundreds or perhaps thousands of filenames extending deep into many levels of subfolders, it’s not an easy thing to clean up. Attempting to move or copy the files from one platform to the other results in either failure or truncation of the original filenames, neither of which is an acceptable outcome.

In our company, I’ve been lucky enough to have a Studio Department which has recognized this issue and taken steps to correct it. When IT has attempted to police this problem in the past, we’ve met with limited success. When the policing effort comes from within, as is the case with our Studio Department which is made up of hardcore Mac users, the other users tend to listen. As a result, we’ve pretty much eradicated the odd characters internally, and this hasn’t been a huge issue for us – which may also be the reason I didn’t think of it prior to this move.

What I wish I had done was send our Studio folks in ahead of our move to explain our internal processes, especially regarding the file naming conventions, and to encourage a general cleanup of files prior to our move. If we had done this, we would have had about 30 days to prepare, and we could have at least had the current jobs named correctly and ready to move onto our new systems. The solution we ultimately came up with involved maintaining the old network, connecting their old server to a Mac and a PC in a common area. We asked the users to do the cleanup of the filenames, and then utilized USB flash sticks to move the files onto the new network.

In any case, it was a valuable lesson re-learned, and just another one of those issues we can sometimes take for granted when we live in a cross-platform environment.

Office Moves – Part 1

In hindsight, perhaps this wasn’t the best time for me to be launching a blog. Then again, in this line of work there’s never a good time for anything. My company acquired a new office about a month ago, and we just spent the past weekend bringing them onto our network. As these maneuvers go, this one seemed to give us more trouble than usual.

Our first order of business was connecting the new office to our WAN. We knew we were in trouble fairly early Friday evening when we ran into trouble bringing a new router online. It turned out that our telecomm vendor provided our router supplier with an incorrect config. If that wasn’t bad enough, when we attempted logging in ourselves to fix the config, the password we were given didn’t work. At that point of the evening, all of our usual contacts at both the provider and our hardware vendor had disappeared. The folks we were able to reach were all telling us that we’d have to wait until Monday.

Thanks to the persistence of my staff, a little help from Cisco tech support, and an assist from a sympathetic tech on our provider’s help desk - we managed to bring the connection to life a little after midnight. We were now 6 hours behind schedule, but at least we were connected. We quit for the evening figuring that the next step, creating a new Windows child domain was going to be easy.

Wrong again. The next day found us once again struggling as we attempted to run DCPromo on the local file server. After 5 or 6 more hours of struggle and a few hours on the phone to Microsoft, we finally found the culprit. Our new server was running Windows Server 2003 R2, and we had never run ADPrep for R2 back at the root of our forest. Ultimately it was a relatively simple fix, but now we were well over 10 hours behind schedule, and all our dreams of taking a Sunday off in sunny Florida had evaporated. We still had plenty left to do, but we worked through the day on Sunday and managed to finish up sometime after 1:00 am on Monday morning.

When Monday morning rolled around, people were connected and things were working fairly smoothly. At some point, somebody asked my why we didn’t document these things. Actually, we do, but the problem with documenting issues on something like this is that no two of these moves are the same. It’s still worth doing, but rarely do the same issues arise twice. We do occasionally add new offices or move existing offices, but it’s just not something we do with any great frequency. One issue which has bitten us more than once is file moves, especially where the Macs use strange characters in file and folder names. That one got us again this time, but I’ll leave the details of that, along with our other lessons learned for my next post.