My thoughts on server shares

Over the years I’ve installed, configured and setup hundreds of servers. I don’t get stuck naming them and I don’t get stuck securing them. I don’t really get stuck setting up file shares but that is where a lot of my time explaining my decision goes into.

Some administrators and managers are of the opinion that they should setup a single file share (\\share), give everyone in the company access to it and let them go to town. This is quite possibly the worst thing you can do to your network. Over time (and a short time at that) your single file share will devolve in to the wild-wild west. Your backups will include twenty to thirty empty new folders, several hundred or thousand tilde temp files and a file structure resembling the plotline to the movie Primer.

You should always split your file sharing structure into whatever works best for your users. Notice I said your users, not your network administrators. Either by department, division, operations or teams, whatever makes sense.

Security management of a file sharing scheme with one share can become a nightmare. You will, over time, find yourself removing inheritance and applying folder specific shares with individual users instead of maintaining security through the use of AD groups. Segmented sharing will give you a finer grain of control over the users who need access to that data. A single share gives you nothing but a headache.

Part of the security control on multiple shares is the ability to designate access via GPO mapping to shared resources. If you are using “logon.bat” in 2017 it’s time to open your browser and search for “GPO disk shares” and dig in to some reading with a nice cup of tea.

Segmenting will also help mitigate malware outbreaks if a ransomware application gets lose in your network. With a network segmented by department (and security locked), any outbreak will be limited to the areas of business the user has access to.

On the subject of segmentation, I have some clients who absolutely insist on being able to “see” the root level of all system shares on their network. I will always take time to explain why this is a terrible idea and if I am unable to dissuade, will demand my clients sign a separate addendum to our agreement absolving me of damage should malware hit, network wide, due to the actions of the managers or owners who insist on this level of access.
With that in mind, never give any one account direct access to all network shared data. Operationally, you don’t even need the administrator account to update or manage shares. You can create domain accounts whose sole purpose is the management of network shares.

Segment your shares, secure them with groups, share them with GPO mapping and enable VSS for instant recovery of files. Spend the time now to set your shares up and you will thank me (and many others) later.

I really don’t get Verizon FIOS sometimes…

So here I am, once again, looking to upgrade FIOS service for my client and the one thing holding me back is Verizon itself. After a series of calls where I was simultaneously told static IP addresses would not change, would change and would not change, a technician who actually understands these things confirmed that yes, all 13 IP addresses would in fact change with the upgrade from the BPON ONT to the GPON ONT.

So once again, I’m on hold scratching my head as to why Verizon a) can’t change the name on an account without first deleting it (losing all IP assignments) and b) can’t seem to upgrade an ONT without throwing away the IP addresses associated with it and providing new ones.

One would think with the technology at our fingertips today, Verizon would have figured this one out.

To the developers of Visual Studio, common sense time…

While I don’t usually rant (yeah right) about developers on my blog I feel I have to on this occasion. Since yesterday, Visual Studio locked up while trying to load a project in that had, until then, loaded just fine. It was stalling at project 10/12 and initially drove me a little nuts thinking I had a corrupted extension, GhostDoc had gone nuts or node.js/Git had gone off the deep end.

Now, I know what your saying right now (let’s face it nobody reads this thing so I can say that) why didn’t you just look at the .SUO file and see what project 10 was and why it was failing to load. Well, I did. Turns out project 10/12 was a node.js link to a server that had been shutdown on my vmware server by flying spider monkeys.

All good right? Wrong. My rant is that Visual Studio in all of its glory simply stalled on 10/12, eventually faded to white and crashed. No error, no warning, nothing like “Hey, your project is pointing to ap4njs.uclnj.com and that server can’t be detected anymore..” which is what these days we should expect our software to be able to do.

I removed the entry from the .SUO file and now the project loads just fine.

Me: 1 – Visual Studio: 0

Testing Backups…

When the call comes in that there was an explosion in the building is not the time to ask “is all of our data backed up?” This just happened and reinforces my methodology of testing backups on a routine basis.

If you are backing up your data but not testing the backups by restoring data, volumes or virtual machines, then no, you cannot say you have a working backup. It’s the same as having batteries in the flashlight only to find a pool of acid in the handle when you open it after the lights have gone out from the batteries leaking.

Depending on your volume, at a minimum of once a month, you should restore from multiple points to test your backups. If your backup system supports multiple delta-points, pick the oldest you can find and restore those.

  • Restore entire virtual machines into your lab and fire them up to make sure they work.
  • Restore Exchange databases to your lab and make sure Exchange Server can mount them.
  • Restore SQL databases to make sure the account credentials were also stored so you don’t have to reassign logins.

In short, backup, backup, backup and then restore or don’t be surprised if you get a pool of acid in the flashlight handle when the lights go out.