Skip to content

Windows Server Technical Preview on Gen 8 Microservers

Consider this a retweet or something similar, but it came up in my Old Reader RSS feed list, and I thought it quite pertinent to my general content.

It’s actually another issue where the network card driver is really important, a colleague and I found an issue a while back where a server properly refused to talk properly to the network due to the driver applied to the network card on a new build. It wasn’t of our doing originally, we first got hold of the issue long after chins had been scratched and brows furrowed, but it was a strange one to undo, we didn’t for a moment think a new build could go out without correct and current firmware and drivers and it never crossed our minds to check until we’d exhausted most avenues….

I do tend to drive others mad with my obsession with drivers and firmware, but I find it an important part of really solid and proper server build. I can’t even run test VM’s on my Win8.1 clientΒ Hyper-V without having them patched up-to-date. Hardware and software manufacturers don’t release these things for fun, and granted, in a production environment, testing is key, if you’re lucky enough to have resources to do that, but these things should be kept up to date in a structured and managed manner πŸ™‚


HP Service Pack for ProLiant 2014.02.0 and Broadcom NIC’s

Just thought I’d post this again, it’s worth noting, and I can imagine anyone affected will have a painful day 😦

If you’re running HP servers and actually have a regular schedule to patch hardware (firmware and drivers), beware :

“On certain HP ProLiant servers, certain HP Broadcom-Based Network adapters listed in the scope may become non-functional when they are updated with the Comprehensive Configuration Management firmware Version 7.8.21 using firmware smart component, HP Smart Update Manager or the HP Service Pack for ProLiant 2014.2.0,” the firm stated.

Take care and stay classy πŸ™‚

Configuring iLO2 on an HP Server

Was passed a query the other day where the login details for an iLO2 (HP DL360 G5, iLO FW – 1.61, 31/8/08) had been forgotten (……..). This sort of thing beefs me and it shouldn’t be difficult to keep a track of these things, but politics aside, the issue was there. The server had become unresponsive some days earlier and further confusion and disorganization led to a right old faff overnight.

So, how to reset? Well, coming to the server now, it’s up. Downtime is generally undesirable in a production environment, whether planned or planned, five 9’s and all that. I could simply bounce the server and F8 into the iLO configuration at boot, but this is downtime. It’s to be expected this method should be used at initial build and implementation time, but this was quite obviously a server that had been whirring away for years. HP do provide a GUI utility to provide this exact required functionality (, and while on site the other night, I ran the installer which ran through without issue. You need to look in the ‘Installation Instructions’ to see that it does have a GUI part to it, it doesn’t seem to be mentioned elsewhere. I wasn’t aware the utility had previously been installed and was presented with a dialogue box asking whether I wanted to update to the latest version. Yes. It’s worth noting the majority of the utilities add a Start menu entry on installation, but this one hadn’t. It installs to <system drive>:\Program Files\HP\hponcfg, hponcfg.exe being the command-line part and hponcfg_gui.exe being the GUI-based version. Fantastic, let’s do it and get home. Apart from the fact that although the utility itself does not require a reboot, it does need ‘one of the following versions of the .NET Framework : v2.0.50727’. Ah, more downtime. As this was a LOB server, I stopped at this point. Always a good tip, work as far as you have agreed to and if thrown a curve ball like this, stop, go home, and rearrange stuff the next day.

I’m now left with the command line version of the utility… A quick Google reveals it works from importing .xml files, not my strong point. No-one seems to give much of an explanation as to the step through key-presses to sort this, so I spend around an hour going over the pdf that explains it all :, the iLO 2 Scripting and Command-Line Guide. A quality read for the beach, I can assure you. But it’s still not made clear enough for a dunce like me. I did then find this : My appreciation to the writer, it made it straight-forward enough to do. Everything else points to changing the user login details once you’re logged in with something, but I couldn’t. I could get local access to the server’s console though so could run the utility. I did take away from the write-up that it’s a safer option, certainly in my situation, to create a new dummy user with adequate rights, log in with that and then do any required admin. This leaves you with some flexibility in case of problems. I created a temp user with admin rights, logged in, created the correct user, logged out, tested access with the correct user, and then with that login, deleted the temp user.

Something I didn’t find at all until this article is the HP Lights-Out XML Scripting Sample for Windows (Google and download it). This .zip file contains 72 files, most of which are .xml templates to perform various functions. This makes it infinitely easier for a non-coder like me to get things done. When the HPONCFG tool runs, it applies either an entire .xml file to the iLO, or a portion of a complete config. So I used ‘Add_User.xml’, opened it in Notepad, amended the various required fields, and wrote it with the utility. It’s funny, looking at the list of files now will make a Powershell ninja chuckle, most of these files are pre-fixed with GET, SET or MOD, it’s the verb-noun syntax πŸ™‚ The GET_ files, for example, should be good for programmatically pulling back server hardware details, very interesting.

And there we have it, a little extra effort and a server reboot avoided. Takeaways?

Build servers properly in the first place (grrrr). Yes, use the PSP or Intelligent Provisioning as it is now. But check the driver and download page for the product in question, and check that these useful little utilities are installed and readily available. The major bonus of expensive enterprise-class server equipment is the supportability and hopefully up-time of the device. This can become limited when you realize you need a certain tool, and it hasn’t been installed, or won’t run without a reboot-requiring patch or whatever. I’ve heard of the scenario where, although unlikely and unrealistic, customers refuse to allow a server to be downed for trouble-shooting, and in this extreme, it’s too late.

Keep tools and firmware (and drivers) up to date. Create a schedule for planned maintenance and regularly check for updates to these things. Even if you’re a shop that doesn’t do these updates on the basis that if it ain’t broke, don’t fix it, at least document updates available so that if you see this or that problem, you have a fix to hand. A test environment certainly helps here, but good backups go a long way to reducing risk. It’s not uncommon to see considerable performance and stability increases from a simple driver update.

Test tools and diagnostic pages regularly to make sure they work. It’s usually when something’s on fire that you need a tool that worked two years ago but is not now. Regular OS patching, and absolutely critical and unavoidable process, might result in a tool ceasing to work, a later version will normally accommodate such changes.

The final note has to be documentation. The ultimate from this perspective would be a pro-active team who ensure everything is kept up-to-date as a scheduled and pro-active action. Regularly testing iLO logins etc. Ensuring that documentation is kept current is a huge battle, and can depend on how quickly your environment runs and changes. But it’s SO worth while trying, even if it’s a lever-arch file in a locked cupboard. You never know when you might need that obscure password. In a hurry. πŸ™‚

Adding a machine to a domain, ‘network path not found’….

Been a while since I posted onto here, and again for that I apologise, I’ve been spending a lot of time in datacentres doing some good old physical work. Gets me out of the office anyway… πŸ™‚

Had an issue last week with a server that had it’s OS fail catastrophically and needed rebuilding. Nothing had changed in network config, no cabling changes, server was physically exactly as it was, just a new copy of Windows Server 2k3 R2 installed onto it. Attempting to add it to the domain as a member server was continually failing with the message ‘Network Path Not Found’.

The usual checks were performed by another engineer before I picked it up for an afternoon. I then left it to another engineer while I was on annual leave. Long and the short of it is, it was an unexpected fix that finally sorted it. Googling around the problem pointed mostly to DNS as expected. Every thought possible was given to checking everything around DNS, and nothing appeared out of the ordinary. Some of the more obscure suggestions were worked through, adding and removing static routes, the whole she-bang. Another server in same DC had been rebuilt in the same way a few months previous using the same creds to add it to the domain, and it went without issue. So much info, but very little of it made sense.

Late on Friday, my colleagues messaged me. Network card driver. Really? Yep. He’d compared the drivers to another of the customers servers that was in the same cabinet, same make and model of physical box, and working without issue. The two drivers were a year apart, and several major and minor revisions apart (HP). Updating the driver to the same version (not necessarily the latest) as the other working server fixed the issue, and the server could be added to the domain without issue.

You may be thinking I’d missed a blooper here. However, it wasn’t myself who built the box, drivers and firmware are something I have real OCD about, it was actually built by a colleague whose job it is to build boxes all day long. It’s for this reason that it didn’t occur to me to check this aspect. I also hadn’t seen anything pointing to this on the net, not even close. I suppose the closest clue was that someone fixed their issue by utilizing the ‘other’, second port on their NIC and the problem went away. Possibly some sort of installation issue in that case, or a fundamentally bad NIC.

So, hope this gives maybe one of you a pointer that fixes this, it doesn’t seem unusual, and it seems this error is quite generic and pin-pointing the issue just a case of ticking off the checkboxes until it resolves. Point in case – This error can be caused by a bad username and/or password used to authenticate the machine add. It’s also been known that restarting the DNS Client and Workstation services on the local DC can bump DNS and again resolve the problem.

As a WWII General once supposedly famously said – ‘Assumption is the Mother of all Fuck-Ups’. If you didn’t build the damn server yourself, assume nothing, question everything πŸ™‚

Windows Server 2012 R2 book…released!!!!


Looking forward to this dropping through the door, this will be a really great read.

DFSR in Windows Server 2012 R2

Bit of a benign update today, but having never needed to get my feet wet with DFSR (or indeed FRS), I thought I’d make an effort to get a handle on it, useful for updating to the very latest info too. The only time I’ve come across it previous is the rather niche detail of upgrading FRS to DFS for SYSVOL replication after a 2003 to 2008 migration (I think). Ran through a load of posts by the very funny Ned Pyle on Technet, and it seems in hand. I’ve probably learned it several times as part of previous qualifications, but back to the old saying of ‘use it or lose it’. When you’re constantly trying to cram your head chock full of anything and everything in the hope something sticks, something has to fall out. Anyway, spent some time last night building some simple templates in VMWare Workstation (9) for 2012 R2 and Windows 8.1, which consisted of installing, patching up to date, a few very minor tweaks so minor I forget (one was to run Disk Cleanup having installed the Desktop Experience, another was to ‘Optimise’ C:). I then sysprep’d and marked the install as a template. I then took a snapshot and gave it an adequate description as this is what you clone from. The name/description make it clear what you’re cloning from when you go through that. Suffice to say, a couple of hours and I had three 2012 installs up and running, 1 DC and 2 file servers. Domain created (so easy now), FS’s added to the domain, DFSR installed on both and DFSR set up and replicating happily. The look on colleagues faces when they pick up a 2003/2003 R2 DFSR/FRS issue says a lot in how far this has come. It’s easy, and Powershell sweetens it. I’m still no Powershell ninja, not in the slightest, but I’m warming to it. Check out Ned’s series of posts and it’s obvious why the PS method is easily the best.

The ‘deeper’ articles near the top are where to go for the nuts and bolts, but start on that page and follow as many links off it as you can bear, it’s worth it. Stuff like the DB cloning seems pretty obvious, why wasn’t it there before, but I guess that’s how things are πŸ™‚

So a change, less revision, more sweeping up under-carpet topics that I’ve never bothered to get nailed. Who knows tomorrow might be certs and PKI’s (or maybe not, let’s not rush… πŸ˜‰ )

Getting started in the New Year

Morning All, hope everyone has had a Merry Christmas and a Happy New Year πŸ™‚ Mine’s been busy, loads of driving, good to get back to the IT side for a break…

Spent some time over the weekend starting to get some boxes sorted. Installed Server 2012 R2 on 3 servers, a DL380 containing a bunch of local SAS drives for a iSCSI storage backend, and two DL360’s for SOFS nodes. It’s definitely overkill and you’d be very unlikely to introduce such complexity in production, but it should serve as a learning tool for me. If you were going to run a SOFS cluster, you’d back it with a JBOD array and connect to it by SAS connections, but not having this and having servers to spare, I thought I might as well. I’ll share the storage off the DL380 by iSCSI to the two nodes and have them share it off from there. I put one of the NC364 4 port 1Gb cards in the 380, giving 6 ports in total, and I’ll use the two onboard NIC’s for management/backup and the 4 on the card for a storage network team. One thing I did notice is that none of the 2008 R2 drivers for the G5’s install off the bat for 2012 R2, reporting an unsupported OS. (I seem to remember there was less complaining with 2012 ‘R1’). This isn’t surprising but is something I’ll watch for while labbing. My OCD means I would definitely prefer to be fully supported, but this is OK for now. I think G7’s are the earliest to have full HP support for R2, so I might be tempted to start swapping out. On another note, it’s an odd thing but at work, these things don’t seem to take all that much time, but when you have the odd 2-3 hours at a time at home to do something, it seems to take an age to build these things up. Building a good platform with all the bells and whistles is not a quick job, hence my fear of the end of Technet, where it seems I’m expected to be happy rebuilding these things every 180 days. I did check when my subscription expires, and after the extension granted as an existing customer at the end of last year, I’m done at the end of January. Hmmm.

I thought I’d give a couple of others a mention in here, as both items are relevant to the cause. First, Paul Winstanley has posted a quite thorough guide on the install of SCCM, which some newcomers will find useful. One of the problems with several SC components is that to actually to actually get something stood up in the first place can be a challenge with plenty of pre-req’s and other hoops to jump through. If you’re hitting it blind, it can take a long time to get going. Guides like this that step us through this first time are invaluable, and while I’m aware that there are lots of these around, it isn’t any less appreciated by the people who use them πŸ™‚ So many thanks Paul.

The other one I wanted to highlight was regarding use of the new Microserver Gen8’s. These are a popular choice for labbing and demo’s, due to the low power consumption and the lack of a need to rack them, a nice small footprint. This talks about the ability to upgrade the CPU to something a bit beefier, and makes them all the more relevant for testing.

I’m still doing a whole lot of reading on various things, there’s plenty I don’t use everyday but I really should have in the arsenal, so I try to keep fresh. A couple worthy of mention, first being ‘Group Policy’ by Jeremy Moskowitz. I get involved with GP every now and again, but it should be a staple knowledge of anyone who punts AD about, and this is a great book, taking the reader from the absolute start (never a bad thing) to the smallest details. I lent it to one of my colleagues who I’m trying to mentor up through the ranks, and he loved it purely because it started from absolute grass roots and made no assumptions of previous knowledge. It’s on his list to buy. Well worth a look for an up-to-date refresher, or for anyone a touch baffled by the subject.

The other one is the old favourite, and a book any self-respecting AD admin should have on the shelf. Needs no introduction, I consider this the ‘bible’ on the subject. It’s a fortunate IT chap who gets to use every angle of AD all the time, so reviewing the odd chapter every now and again is good value for that odd time someone throws something leftfield at you, and you can just roll it off πŸ™‚