@scottalanmiller said in Hyper-V 2019 on a domain:

@PhlipElder said in Hyper-V 2019 on a domain:

@scottalanmiller said in Hyper-V 2019 on a domain:

@PhlipElder said in Hyper-V 2019 on a domain:

Moot point for us as all of our clients run either Software Assurance or we are supplying the licenses via SPLA as we manage their infrastructure.

If you can truly control that, we find that clients tend to like to drop SA or avoid it over time. They might start with it, but it only takes dropping it once to cause an issue. And if Hyper-V is the "one reason" why they would need it, they then see Hyper-V as a problem. It's just easier and more consistent to avoid the problem and not have to have the more complex decision structure.

Our longest standing client is spanning two decades. We have not had any issue with software licensing with our clients. None. Nadda. Zippo.

You are in a miraculous situation. For most everyone, clients don't have 100% software assurance. It is not in any way normal to have 100% always current licensed customers. Literally have never heard of any MSP claim that level of saturation before, it is that rare.

We have a very simple policy: Not licensed correctly? Either get there with a commitment and we will help them get there or we walk. Period.

@scottalanmiller said in Hyper-V 2019 on a domain:

@PhlipElder said in Hyper-V 2019 on a domain:

Moot point for us as all of our clients run either Software Assurance or we are supplying the licenses via SPLA as we manage their infrastructure.

If you can truly control that, we find that clients tend to like to drop SA or avoid it over time. They might start with it, but it only takes dropping it once to cause an issue. And if Hyper-V is the "one reason" why they would need it, they then see Hyper-V as a problem. It's just easier and more consistent to avoid the problem and not have to have the more complex decision structure.

Our longest standing client is spanning two decades. We have not had any issue with software licensing with our clients. None. Nadda. Zippo.

@scottalanmiller said in Hyper-V 2019 on a domain:

@PhlipElder By far the biggest reason that most of us avoid that installation method is the one that you are avoiding mentioning - licensing. What the licensing is for Hyper-V and Windows today isn't relevant to the concern, it is how it will be licensed indefinitely into the future. This is what customers often don't understand and overlook thinking that because they already paid for Windows that they should "just use it", and then routinely get burned down the road by being unable to upgrade Hyper-V without paying for it, because they encumbered it out of habit and no one warned them that this risk would almost certainly catch them when they didn't want to spend more money to upgrade something that is otherwise free.

By deploying Hyper-V in the lighter mode, we simply protect the customer from an unnecessary encumbrance, once that we've found to be the most significant factor affecting Hyper-V decision making in the real world.

Moot point for us as all of our clients run either Software Assurance or we are supplying the licenses via SPLA as we manage their infrastructure.

I don't know what a "control VM" is?

@scottalanmiller said in Hyper-V 2019 on a domain:

@PhlipElder said in Hyper-V 2019 on a domain:

In my mind, Hyper-V Server is aimed at hosting *NIX/*BSD and virtual desktop infrastructure on Windows Desktop where a server license would be a waste of money.

No, it's definitely not the purpose for it. It's widely considered the "good" way to run pure Windows VMs on Hyper-V, too. It's lighter, faster, more stable, etc. Are there reasons and benefits to the less streamlined approach? Yes. But are they commonly considered to outweigh the benefits of not doing that? Not generally, no.

I have plenty of pure Windows environments, and we never deploy that way because it carries risks, mostly around long term licensing, that we don't want while providing essentially no value. We see customers get screwed with that all the time, but almost never see a benefit. The one benefit generally associated is that it is "easy" in a stand alone (non-MSP, or small MSP) environment with only one server and no management desktops to remotely manage a machine.

When we're licensed for Windows Server we install Windows Server whether Standard or Datacenter on the host. That has been our methodology since the Longhorn days. We have no plans to change that.

Since the inclusion of .NET and other more desktop oriented "technologies" on Server Core, and thus Hyper-V Server 2019 (HVS), the reboot requirement for patching has basically saddled up to the Desktop Experience (Full GUI).

The surface area for vulnerabilities is about the same for Server Core and HVS. So, no real benefit there.

As far as stability goes, we have had both Server Core and Desktop Experience servers run for an exceedingly long period of time without the need to reboot with an edge to Server Core.

@Dashrender said in Hyper-V 2019 on a domain:

@PhlipElder said in Hyper-V 2019 on a domain:

@Dashrender said in Hyper-V 2019 on a domain:

@PhlipElder said in Hyper-V 2019 on a domain:

All of the above and more but done in PowerShell on our KB site.

You appear to be doing a role based install

Install the Hyper-V Role

Install-WindowsFeature Hyper-V,Hyper-V-Tools,Hyper-V-PowerShell -IncludeAllSubFeature -IncludeManagementTools -Restart

Why not pure Hyper-V?

Not sure I understand the question?

Hyper-V Server is set up relatively the same though with some restrictions.

We always deploy using PowerShell whether the Desktop Experience in standalone servers is installed or not.

Get-WindowsFeature *hyper*
^^^ There should be no difference between the two sans GUI for Hyper-V Server of course. It is a role.

The question is - why are you installing a full Windows server (which requires a license) and then adding the Hyper-V role? Why not do the license free setup, pure Hyper-V?

Ah, because Windows Server is licensed via the host not the guests.

In my mind, Hyper-V Server is aimed at hosting *NIX/*BSD and virtual desktop infrastructure on Windows Desktop where a server license would be a waste of money.

Most of our hosts are set up with Windows Server guests and therefore require the license.

@Dashrender said in Hyper-V 2019 on a domain:

@PhlipElder said in Hyper-V 2019 on a domain:

All of the above and more but done in PowerShell on our KB site.

You appear to be doing a role based install

Install the Hyper-V Role

Install-WindowsFeature Hyper-V,Hyper-V-Tools,Hyper-V-PowerShell -IncludeAllSubFeature -IncludeManagementTools -Restart

Why not pure Hyper-V?

Not sure I understand the question?

Hyper-V Server is set up relatively the same though with some restrictions.

We always deploy using PowerShell whether the Desktop Experience in standalone servers is installed or not.

Get-WindowsFeature *hyper*
^^^ There should be no difference between the two sans GUI for Hyper-V Server of course. It is a role.

All of the above and more but done in PowerShell on our KB site.

@Dashrender said in Remote Hyper-V Manager Woes:

@PhlipElder said in Remote Hyper-V Manager Woes:

Hyper-V Server 2019 is still not available. There's more to this than meets the eye me thinks.

eh? I downloaded it using the link @JasGot posted yesterday.

The link is to the GA bits. There's quite a few problems with the GA bits.

Dell boot loops for one, the RDP for another, and a bunch of other issues that one need only look at the Cumulative Updates to see.

I did use the link to download the bits. I'll see if our slipstream method works for it before actually using the bits to install with.

EDIT: Since the RDP problem hit this version there may be something else hidden in there that we don't know about as of yet. Thus my reservation on deploying.

Hyper-V Server 2019 is still not available. There's more to this than meets the eye me thinks.

@scottalanmiller said in Remote Hyper-V Manager Woes:

@PhlipElder said in Remote Hyper-V Manager Woes:

For a standalone Hyper-V server though that's a 12lb sledge for a 3" spike. Just a tad.

Much like RDS.

Yup. That's why PowerShell Remoting is da bomb!

@scottalanmiller said in Windows 10 Defender Won't Start After Malware or Ransomware:

@PhlipElder said in Windows 10 Defender Won't Start After Malware or Ransomware:

@scottalanmiller said in Windows 10 Defender Won't Start After Malware or Ransomware:

On its own, where Sophos was the AV that was supposed to be running, it failed to stop the virus. That's not a huge thing, it's not the only AV that failed on that. No AV is perfect and they depend on the OS to be well configured to do their job. But it wasn't successful at protecting even where it was fully installed and running.

Traditional A/V is dead. It's a legal placebo.

This is why I like Defender. A placebo should be free and not get in the way.

We were working with a contractor that uses AVG's RMM setup (I think it's been sold now).

WDAV flagged the executable as a virus and clamped it down a few days later. That freaked me right out so we went through a process with AVG to figure out what was happening.

WDAV started flagging all of our RMM .EXE files. That's when it became clear that they were false positives. But, that does not make up for the stress that happened initially.

@scottalanmiller said in Remote Hyper-V Manager Woes:

Always an option to make a dedicated domain for Hyper-V, too. Not sure if I'd ever want that. But it works.

We've been deploying two for a while now in high exposure settings or high risk settings.

For a standalone Hyper-V server though that's a 12lb sledge for a 3" spike. Just a tad.

If running in a standard user session then right click Hyper-V manager and Run As Admin and use the Hyper-V's local administrator for credentials. That may work though I can't remember if it does since we manage everything via local console (RDP) or PowerShell Remote.

@JasGot said in Remote Hyper-V Manager Woes:

@DustinB3403 said in Remote Hyper-V Manager Woes:

I assume you don't want the Hyper-V server connected to the domain for some reason.

There is a guide here by Timothy Gruber which appears to do what you want.

It's just a test box, and honestly, I like to get servers built as far as I can before we deliver them. So joining the domain is something I would prefer to do at a later time; once the server has been delivered on site.

We don't join standalone Hyper-V hosts to any guest domain. That's just asking for trouble on so many fronts.

It can be done but requires anonymous access to be enabled on the Hyper-V server (HVRemote is the step-by-step).

We don't do that for obvious reasons.

PowerShell is the best way to manage the server.
Enter-PSSession -ComputerName R510-HyperV -Credential R510-HyperV\Administrator

@NerdyDad said in Random Thread - Anything Goes:

@PhlipElder said in Random Thread - Anything Goes:

@scottalanmiller Link please?

https://xkcd.com/936/

Thank you.

I concur. We're not putting much effort into our on-premises solution sets as the user there is the low hanging fruit and primary attack vector anyway.

For our hosting solutions though, what a PITA.

We coach our hosting contractors on locking down RDS to help mitigate any PEBKAC issues (ID10T types). And for the most part, they've been very successful as we have many examples of the "steel toed boots" preventing the bullet to the foot so to speak.

@scottalanmiller Link please?

@dafyre said in Random Thread - Anything Goes:

@tonyshowoff said in Random Thread - Anything Goes:

@nadnerB said in Random Thread - Anything Goes:

Win what? Both are terrible approaches to passwords.

Free network pwnage with every Posty Boi.

Heh ... I remember seeing a well dressed fellow with stickies on his laptop while waiting for a flight at the airport in Edmonton. Curiosity got the best of me so I took a boo while I took a gander by and sure enough it wasn't hard to see that it was his username and passwords.

SMH

Nice suit not so smart.

https://www.zdnet.com/article/all-intel-chips-open-to-new-spoiler-non-spectre-attack-dont-expect-a-quick-fix/

sigh

@scottalanmiller said in Windows 10 Defender Won't Start After Malware or Ransomware:

On its own, where Sophos was the AV that was supposed to be running, it failed to stop the virus. That's not a huge thing, it's not the only AV that failed on that. No AV is perfect and they depend on the OS to be well configured to do their job. But it wasn't successful at protecting even where it was fully installed and running.

Traditional A/V is dead. It's a legal placebo.

What it's replacement is beyond user training and termination for doing something they shouldn't is beyond me at this point.