I'm frequently amazed by the sheer number of people who don't bother to update their systems when a new server operating system version arrives. Amazingly, there are many systems administrators and part-time network people who seem to think that merely having a strong opinion about what Microsoft has done or looks like doing in future somehow qualifies them for a seat at the software-design table.
This being the case, here's my top-five list of tips to help those of you who aspire to stay on top of all things network to continue to pull it off.
1. Forget the GUI
Things such as creating a folder; sharing and other basics may be okay using the mouse, but all the heavy lifting is done inside PowerShell nowadays.
This is one of those Windows add-ons that had a distinctly rough initial reception, and it has retained a bad reputation among those who looked at v1, found a reason to hate it and never returned (think of these folk as early rejecters rather than early adopters).
Irrespective of the opinion of this marketplace of curmudgeons, Microsoft has now developed PowerShell into an extensible, if somewhat prolix, management tool. For almost everything you actually end up needing to do — and I make a distinction from the baby-step things the graphical user interface (GUI) is designed to facilitate — you'll want to use PowerShell.
2. Learn to love the ISE
This is the simple, straightforward graphical editor for PowerShell. It may look as though it's designed specifically for the editing of batch files and complicated things, but consider this: every Microsoft presenter on my last Redmond visit would show me their demo by grabbing a chunk of PowerShell code, dropping it into the integrated scripting environment (ISE) and then selecting each line or sub-unit of code by swiping with the mouse and running it with a swift stab of the FS key (yes, I know F.5 used to mean Refresh, but you have to adapt to survive).
The Integrated Scripting Environment (ISE) is undoubtedly more than merely an editor; it's similar to an interactive execution console such as interpreted BASIC or Lisp. There are plenty of useful guides to using the ISE start at "Using the Windows PowerShell ISE" (date: 2013), which is definitely much better than starting at "Using Windows PowerShell ISE" (date: 2009).
3. Keep Bing open
The ISE, and even the humble help file, will carry you a reasonably long way, but when it comes to Microsoft-specific search results, Bing gives you a shorter and better-targeted list than the other search engines.
Besides, it's an enormous advantage to be using a command-line environment linked to a 21st-century search engine when you need to narrow down the possible cause of a problem or find the fix for it. Indeed, it's significantly easier than trying to figure out what a particular graphical element within a specific mouse-friendly utility may have been called by its designer, the supporter, the presenter of a fault or the owner of its fix.
I'm aware there are a number of free Windows Store apps that purport to help with this task, but I'm not yet sufficiently avant-garde to start mixing Store apps with a number of open command windows on the same screen.
4. Don't get too macho
Note that in my previous recommendations I've discussed using PowerShell as a way to function on top of a fully graphics-driven operating system, with all its GUI-based tools functioning. Just because Microsoft has offered a command-line-only version of Windows Server doesn't mean you have to try to squeeze yourself into such a puritan, fragile and dangerous straitjacket simply because using the command line is good for your soul.
Of course, if typing in 64-character, hexadecimal, numerical, globally unique identifiers from memory turns you on, don't let me stand in your way — but I've witnessed far more problems arise from poorly chosen Server Core deployments than I have from the kind of poor decision-making that's supposedly encouraged by GUI-based server installations.
5. Keep your eye on System Center
Microsoft's primary motivation for developing this enormous chunk of system software was the observation that, at the far distant end of getting comfortable with script-based systems management, there are people who have written tens of thousands of lines of code and now find themselves stuck in a rat's nest of ad hoc solutions, entrenched methods, weird fixes and painful emergent behaviours. The scale - expressed both as the number of servers managed and the complexity of each server — at which this becomes a problem is absolutely huge, and it's very likely that most administrators will never hit these buffers in everyday business.
But when you sit down and think, "Why am I trying to pull all these bits together with 20 lines of code?", the answer is that the prebuilt, beautified version of the handy administrative overview you used to use is no longer a standalone application; instead, it appears as a tiny dialog or pop-up inside the enormity that is System Center.
It isn't that common to see smaller businesses go after a System Center licence, but it's a good idea to look around to see how System Center does things — not least because a lot of the dispatched instructions for far-flung servers, generated by a System Center wizard, either are PowerShell scripts or can be exported as PowerShell scripts. These can be employed as a handy source of information for your own processes.
arp -d *
Yes, that cryptic little string is both a snappy headline and something you can type into the command line. In fact, it's a bit of a fix-all, and it relates to a most unexpected collection of problems that I've run into myself or to which I've been alerted by readers. In particular, Rob Anderson has been in touch about a protracted and rather stop-start debugging of his internet connection that he was attempting to perform by making use of Netgear's helpline. In the same month, I encountered a couple of Swiss residents (one current client, one former) with the same issue, both doing battle with Swisscom.
In all three cases, the people involved woke up one day to find that their internet connections were suddenly misbehaving. For his part, Rob ran some tests and concluded that some of the settings on his Netgear weren't achieving the effects he was expecting from their description, so he got in touch with the company.
At the same time, I was sitting in the semi-darkness of a closed-for-the-summer ski chalet in Switzerland, watching the status display of an old, but ultimately reliable, Motorola Netopia DSL router. I'd intended to move a lot of data around that evening and make a stab at an inter-shop VPN configuration, but after my first try failed — the connection's external DNS server address seemed to change every few minutes — I called up the router's diagnostic page and watched, in a quasi-hypnotic state, as the link rotated through about five permutations of speed, DNS server, gateway and IP configuration.
During one of the short time windows when this rotating config would actually permit internet traffic, I received an email into my mailbox (not the client's) from a former client, now resident in Lausanne. He was at his wit's end, because his Swisscom connection was going up and down, fast and slow. He had no idea how to keep his document sync systems running, and he wasn't getting help from his router maker.
Switzerland is a strange mixture of similarities to the UK (there's a healthy market in third-party router hardware) and differences (Swisscom won't talk to you, and the tiny population means there's an even tinier technical skill pool to call upon). Nevertheless, the problems faced in the UK by Rob and overseas by me and Distraught of Lausanne were exactly the same — if you go to a helpline with a problem that you assume lies with the piece of equipment in front of you, you'll get into conversations with people who have very simple-minded remits and lack specific information to work from. When it comes to debugging internet connections, this unfortunate confluence of deficiencies will sink any chance you had of resolving the problem.
DSL lines aren't just a pair of wires that come out of the wall: these wires are merely the tail-end of a huge collection of varied equipment types and configuration choices. And ISPs and phone companies feel entitled to fiddle with the internal setup of the kit to which you connect.
This may take years to become noticeable to you. But when it does finally become noticeable, its effects can be drastic. This is often for reasons that are remarkably dull and untechnical, including the new kit at the far end of the line being incompatible with yours and the installation engineers not having the right configuration information to correctly match your wires to your internet service contract details. But the most obvious and unpleasant reason is that there's no communication between the people who do this work and the people who are using the connections they're fiddling with. In fact, if you think about the number of users connected to a typical telephone and internet exchange, there's never going to be a good time to perform an upgrade — someone, somewhere will always have a drop-dead reason why it should happen next week, or tomorrow or yesterday — any time but today.
For that reason, infrastructure maintenance teams all over the world adopt a working philosophy of "just pile in", thus leaving the debugging process to the hapless customers. In the UK, where your ISP may well have sold you the router as an extra-cost item, there's no liability upon that ISP to guarantee perpetual compatibility, either. You might buy their recommended device six weeks before some infrastructure-driven connection update to the exchange blows you off the net, never to return, at least not with the equipment you were using.
I expect that almost everyone who hasn't worked inside some part of the ISP or telco business will be boggling at this point. Surely broadband is a standard thing, right? It's practically just an algorithm, a method of packaging data and sending it down those long, thin wires very quickly, no?
If this were true, then whenever you encountered a problem it would have to be with your local equipment, and therefore your recourse would be with the manufacturer of said equipment. Unfortunately, this is far from being the only possible option.
Another less far-flung incident during the past few weeks involved a remarkably unhelpful UK ISP who had just been through an exchange-side equipment upgrade to a customer connection that was limited -- contractually - to a very low connection speed. In fact, the speed was so slow that it fell below the range of speeds permitted by the updated exchange equipment. I sat in throughout the support-call process on this one (with the ISP, not the router maker), which became stuck in an endless loop: the support guys didn't want to consider that the business hung onto the end of their line might be perfectly prepared to renegotiate their contract if only the support desk could arrive at some way of helping them prove the line was still usable. I seldom find it necessary to play the pompous, "Don't you know who I am?" card with people whom I consider to be my peers, fellow IT professionals, but this was one of those rare moments when I slapped it down.
So, for the benefit of Mr Anderson, my Swiss friend, and that client, here's the low-down. Yes, your exchange-side internet connection can be subjected to "improvements" without anyone contacting you, and there'll be no hand-holding, nor web resources, nor handy workarounds that you can type into little-visited pages of your router's firmware-management interface. All you can really do is pick a very modern replacement router, try not to waste too much time on the phone to support and put the incident as far behind you as possible.
Actually, there's one last tiny bit of escalation I've had to advise a couple of clients to follow in this situation: order up a new phone line and another connection and pretend that the old, bad one that gave you so much stress simply never existed. If you're called by the phone company, deny any history or any knowledge of it. Generally these businesses are set up to smoothly deliver new business, and then to utterly ignore the regular paying customers thereafter. That's why their support lines deliver such a low-satisfaction experience.
Celestial arp
And that arp -d * thing? Ah, yes. Many small businesses run their entire networks unchanged for years at a time, and I mean years. The reliability and consistency of operation lead them to consider their network as permanent as the roof over their heads. Or, at least, that's the way it feels when someone like me arrives who's intent on taking everything to bits and tidying it up. Tempers can become short, and patience with disconnection from the internet severely limited. This means you'll need a bit of a workaround to put in place on the day you turn up with their replacement, go-faster router device that will cure all their woes.
The problem I'm trying to fix here concerns the way devices in a LAN figure out how to find one another. Most people think about machines as having names, while a smaller group are able to think about their IP addresses, the numbers beneath those names. However, very few people think about MAC addresses, those hardware addresses that may have one, or many, IP addresses to share with the rest of the network.
That's mostly because it's quite unusual to need to think about these relationships at the very bottom of the seven-layer OSI networking model: software and settings conspire to keep this level well out of sight.
Until you want to swap out your internet router, that is, when all of a sudden those machines left running for months or years can no longer connect to the replacement device, no matter what you do to it. That's because the IP address you've used for your router - the IP address that's typed in all over your LAN on your printers, Wi-Fi access points, servers, PCs and tablets - is still held in their network stack as belonging to a different MAC hardware address. It's as though your old router has kidnapped its own IP address and dragged it with it into the dustbin
You could fix this problem by rebooting everything, or by setting up the new router with a new address and then changing the configurations of just about everything in your building to point to it. Alternatively, you could work a little bit of command-line magic by typing in "arp -d *".
The address resolution protocol utility (ARP) manages the cache of numeric IPs and MAC addresses held by your machine. If you've managed to fool it by substituting one router for another then you can flush it out by using the -d switch - this deletes all the cached records and makes the ARP reach back out to the LAN to re-enquire from scratch.
After this month's fun and games, I can say with some assurance that knowing this simple trick can confer on any humble network troubleshooter an almost god-like aura of omnipotence.
