Random Thread - Anything Goes

*Should add I'm going to (when I have time over the next few days) review what we bought and type of license qty. Then look at how many devices/users we have. Then look at our RDS environment and again look at what we have and what we need.

DustinB3403

@hobbit666 said in Random Thread - Anything Goes:

@DustinB3403 said in Random Thread - Anything Goes:

It's not really, license every user, every device or some combination based on the workload.

But what if you some device Cal's and are getting a new server that has 2019 data centre license.
Do I need to relicense everyone?

*Should add I'm going to (when I have time over the next few days) review what we bought and type of license qty. Then look at how many devices/users we have. Then look at our RDS environment and again look at what we have and what we need.

If you are installing or upgrading between Server OS versions, yes you need to license for that version, unless of course your licensing is valid for that version and you for some reason used an old version of the server software.

DustinB3403

The Data Center licensing does nothing for your device/user cals. That licensing is for the server itself. Without updated cals, you're "out of compliance"

scottalanmiller

@hobbit666 said in Random Thread - Anything Goes:

But what if you some device Cal's and are getting a new server that has 2019 data centre license.

The simple answer has always been "avoid device licensing", it's super simplistic, but very hard because you have to identify every single networking device that ever touches your network. It's crazy. It's SO hard, it's intended to never be used. Stick to user CALs, trust me, no one you've ever met is a viable candidate for device licensing.

scottalanmiller

@hobbit666 said in Random Thread - Anything Goes:

Do I need to relicense everyone?

Device CALs are relicense every device not person. User CALs is licensing people. And yes, when you add new servers, you update the CALs. It's super simple, if anything seems in any way complex, something big is being missed.

Basically it works like this unless you are deciding to add crazy complexity of tracking to save some money somewhere....

License all VMs, either VM by VM with Standard, or host by host with Datacenter.
License every user with a User CAL.
CALs are for the highest level Windows that appears in an environment.
Server licenses need to be the highest level that appears within their pool.

It's actually all but impossible to come up with a simpler method for licensing commercial software. Only open source is really easier.

hobbit666

OK so take this as an example.
Server A license 2012 Datacentre
300 2012 User Cals
2012 DC VM & 2012 App/FileServer

We are migrating to new hardware
Server B 2019 Datacentre
Migrate the two VM's (So staying with 2012)
Do I need to purchase new CAL's? Or will the others transfer because the VM's are the same?

Or is it a case the CAL's only need replacing when we upgrade or install a VM to 2019?

DustinB3403

@hobbit666 said in Random Thread - Anything Goes:

OK so take this as an example.
Server A license 2012 Datacentre
300 2012 User Cals
2012 DC VM & 2012 App/FileServer

We are migrating to new hardware
Server B 2019 Datacentre
Migrate the two VM's (So staying with 2012)
Do I need to purchase new CAL's? Or will the others transfer because the VM's are the same?

Or is it a case the CAL's only need replacing when we upgrade or install a VM to 2019?

The CALs only need to be updated to match whatever you have deployed. So if you were upgrading from 2012 to 2019, you would need to purchase 2019 CALs.

If you ever deploy 2019 on these hosts, you need to upgrade.

DustinB3403

Because you are migrating to 2019 on Server B, as the host, but your VM's are unchanged, and your users are hitting 2012, and not 2019 you shouldn't need to purchase 2019 CALs.

JaredBusch

@DustinB3403 said in Random Thread - Anything Goes:

Because you are migrating to 2019 on Server B, as the host, but your VM's are unchanged, and your users are hitting 2012, and not 2019 you shouldn't need to purchase 2019 CALs.

Correct, you can have domain members of any level.

hobbit666

@DustinB3403 @JaredBusch
That's what I wanted to hear, means we may be able to defer (if that's the term) buying new CAL's until we are migrating the VM's to 2019. Would it matter how the CAL's were purchased (I'm trying to track how/when/what at the moment)

DustinB3403

@hobbit666 said in Random Thread - Anything Goes:

@DustinB3403 @JaredBusch
That's what I wanted to hear, means we may be able to defer (if that's the term) buying new CAL's until we are migrating the VM's to 2019. Would it matter how the CAL's were purchased (I'm trying to track how/when/what at the moment)

Using the Microsoft licensing center has been the "easier" approach I've used, as it stores your purchases right there.

Of course @scottalanmiller would disagree here as he's had a hell of a time using that licensing center.

hobbit666

@DustinB3403 Think that's where ours are, just checking once I find our login

scottalanmiller

@hobbit666 said in Random Thread - Anything Goes:

OK so take this as an example.
Server A license 2012 Datacentre
300 2012 User Cals
2012 DC VM & 2012 App/FileServer

We are migrating to new hardware
Server B 2019 Datacentre
Migrate the two VM's (So staying with 2012)
Do I need to purchase new CAL's? Or will the others transfer because the VM's are the same?

Or is it a case the CAL's only need replacing when we upgrade or install a VM to 2019?

How can Server B be "2019" if there is no 2019 VM? Doesn't make sense. Servers don't have levels, only VMs have levels. Once you install 2019 anywhere, then you need CALs everywhere.

scottalanmiller

@DustinB3403 said in Random Thread - Anything Goes:

Because you are migrating to 2019 on Server B, as the host, but your VM's are unchanged, and your users are hitting 2012, and not 2019 you shouldn't need to purchase 2019 CALs.

This is incorrect. 2019 is "used to support the resources" so if 2019 gets installed, CALs need to be upgraded at that time. No way to keep the users in the real world from benefiting from it. Any VMs that run on top of it will be using it, for example.