Knowing that the business was not taking their systems seriously might be the most important thing that he gleaned from this.
While I see what you're saying... I just don't buy it. the chances that a person would read your post and turn around and return to management and instead of being in a panic over patching say - hey, this is your bloody fault.. now what are you going to do about making sure this doesn't happen again? the answer is only SAM would do that, not another person I know personally.
You base the value on what you see as people likely doing, and there is rational to that. I'm basing it off what they are empowered to do. I like to give more options, faster. How they choose to leverage that is then up to them, but the info that they need is in their hands.
I know there is a best practice that discourages an environment with only one domain controller.
Why? Do you really need two domain controllers? How many authentications are you doing? How much downtime can you afford? Would it be better to have a single domain controller on a VM that you can backup and restore in a few minutes versus having two running at all times?
Why = because a document from Microsoft said so and at the time when I made our domain I didn't know any better :).
What you're asking me is what I'm asking myself, which moves me to the conclusion that when it's time to make the VM for the accounting software, the old box should just go away. Especially since my tiny number of users would be able to log into their workstations with cached credentials until I can get the domain controller VM functioning again.
Who cares what some paper from the company selling you the licensing says.
What does your company need?
I have never used two domain controllers in the SMB space. Even before virtualization at my clients.
It is simply not something needed.
You don't think the downtime justified the cost for a SMB I'm assuming and load balancing isn't a concern
Rarely is downtime worth the cost of mitigating it in an SMB environment. They often don't actually understand what the true cost of downtime is and exaggerate it more often then not. If you're getting enough requests that you're hitting a performance threshold on the domain controller then you may be out of the SMB space.
And authentication often has a near zero impact for short durations. A DC down could easily go 30 minutes and literally have no one notice.
Too many people become enthralled in learning the technology they want to work with and seem to forget the purpose for the technology in the first place. Active Directory is great, and knowing how to setup, troubleshoot, and administer it is fantastic. But what's the reason for it? Centralized management, which allows for greater control and efficiency in the business. It's a problem of being taught facts without understanding the context behind those facts, and that's a problem that affects the job industry as a whole, not just IT, although IT is usually the field where it's most dramatically seen. People going for finance or business management understand that their tasks are to suit the business needs, and the skills they bring to the table are to serve that purpose. But IT seems to go down this rabbit hole that the technology is king above all else, forgetting what the purpose of the technology is in the first place.
You will often hear or see the term RDBMS or Relational Database Management System. This term refers to a subset of DBMS, not an alternative, and is specific to those DBMS that handle relational database formats. The term SQL is often incorrectly applied to these, but SQL is a language and relational databases are a mathematical model. While the two have a relationship (no pun intended) they are different things completely and are not directly tied together. Today, what is and is not an RDBMS is increasingly unclear as nearly all DBMS have some relational element and even the most traditional RDBMS stalwarts have begun to add non-relational engines or options.
For tech people I think college is a waste of time.
Depends on the kind of tech. There's stuff you should definitely learn in a classroom before you have any business being on a job site. I generally agree that fundamentally how higher education is taught could be improved greatly.
Doesn't mean college, though. Those are normally safety things. And classrooms teach very little. If it's risky, they should be certified. It's the testing that matters, not the classroom.
In some cases, understanding when you are or are not may only be important for understanding your own scope and responsibility. Knowing that you are not responsible for data loss when someone in management above you refuses recommended backups is important for sleeping at night or telling a future employer about a previous role.
Knowing that you do (or do not) actually run IT could be potentially important for explaining in a court case who is responsible for decisions leading to breaches, data losses or violations. Titles do not matter in court, roles do.
But in a more day to day, practical sense, explaining to management "above you" at your job that they have decided to take over as the head of IT and that that impacts how you and they need to think about your job. Maybe this can make your job better, maybe this can help management understand business failings. But if we can't put these things into words, we cannot begin to address them.
The moral of the story here is you get what you pay for. Every once in awhile you can get a rockstar IT person at $40K a year, but it doesn't really happen very often. Sure, many IT people go start out a $20k and work their way up ( I did), but they are going to view that $40K a year salary as a stepping stone with limited growth. Give them limited support (money and verbal) and the chances of having a dank network get even lower.
$10 an hour to hire IT?!? You can make more waiting tables, or at a gas station. 40K isn't much better (Bartenders make more than this).
Haven't been in SW much I take it. Tons of people complaining about earning less than gas station cashiers and fast food workers.
It's become rather common. Most of my jobs I have been severely underpaid. Not all, mind you, but most.
If the article is accurate it would have to be a hypervisor. With a dom0 running an anorexic windows 8.
Sounds like they use the term RTOS as a code for hypervisor. They say it is an RTOS but then point out that it is not an OS (in that it doesn't run apps) and that it is a hypervisor (in that it hosts Windows 8.) So either their name is wrong, or their description is.
Ok, I didnt read the article, I commented based on things i heard from Paul Thurrott.
So I'll admit my understanding might have been wrong.
As a side note, Xbox one has been upgraded to Windows 10 now....
It's weird that the article claims it's a partition not a VM....
Partition and VM are not competing concepts. Lots of VMs are partitions. One thing (VM vs physical) is about how it runs. Partition vs. something else is just where it is stored. Nothing in saying it is a partition suggests that it is not a VM.
Now we only have the article to go on, but the article seems pretty clear that it is a VM. But what it really is, no idea.
Of course, there is always the option to keep the old infrastructure indefinitely. This can be an excellent choice if the old infrastructure is purpose designed for a specific workload, such as perhaps VDI, and the HC cluster is designed for more general purpose needs (or vice versa, of course.) Using each tuned for specific use cases is absolutely viable, but does require knowledge of and support of two different clusters each of a unique type which creates IT overhead, but remains a very realistic option.
I'd argue dropping the skill sets to maintain legacy clusters is one of the main appeals to HCI. (I Personally want to FORGET about HBA Queue depth management, and FC Zoning). The problem of running old gear indefinably is the hardware support costs, environmental costs, and lack of support for new hypervisor versions and other things eventually catch up with you before you realize it.
Yes, it's technical debt for sure and in most cases, you want to head towards phasing it out. But whatever skill set you had for it, you will still have at the time that you begin replacing it and can slowly reduce the dependency and the skills related to it together.
They work very differently too. MySQL's features vary significantly based on which engine is in use. They perform differently, have different relational abilities, store differently on disk (MyISAM is one file per table, InnoDB is one file for everything) and use different tools.
Literally just got off of the phone with someone who had a FreeNAS bug cause a system to become useless, just like the one case that happened today. But instead of it being the JPE encouraging a mistake, the same problem happened through a GUI bug. One of the big risks that the JPE introduces is that the GUI is all "extra" points of failure and has nowhere near the testing of the standard OS tools. So a little big can cause a lot of damage, as it did. The entire SAN had to be replaced due to a small bug in the FreeNAS interface.