Another great video. Ya know, if Japan is just plain gone. Or if the eastern US is just plain gone, I'm not sure if I'm gonna be going in to work that day. Even if my charred remains aren't in one of those smoking craters, maybe there's more pressing issues at hand than work...
Hi Dean, your video packed with so much useful info, I had to watch it multiple times to fully get it, good work! One quick question though, @14:30, how did you get session hosts from two different regions showing up as different icon in the same Workspace? As the App Groups give you icons, I assume they are from two different App Groups. The only way I can think of is that, you need to create one workspace with two separate App Groups within the same region, (in fact, I believe workspace and App Group has to be in the same region), then in one of the App Group you'd have host pool in regionA and another App Group you'd have host pool in regionB, right? Thanks Shengsheng
THANKS! Once you link the App group of a host pool to a workspace all other app groups must be joined to that same work space...so to have a different workspace for DR...you need another pool. So it is 2 different pools...1 in primary region and 1 in DR region. Each pool has its own app groups and Session Hosts and you have 2 workspaces. 1 in primary region for the primary pool and the DR region has a DR work space for the DR pool make sense?
@@AzureAcademy , thanks for your prompt response. However, @14:30, you showed the two icons, (one for DR VMs, one for Primary VMs), they are in the SAME workspace "AZ-140", so my question was how you created VMs from two different regions surfaced up as different icons in ONE workspace. sorry for the confusion...
No worries! There are three host pools that you are seeing represented in those app groups in those two work spaces. And the first workspace contains two host pools app groups and the DR workspace is from a third host pools app groups This is to show that you could have multiple host pools represented in a single workspace or each pool represented in their own workspace
I like the idea of building out additional hosts in the paired Azure Region (I tend to use UK South, so DR would be UK West) and joining them to the same host pool as the production hosts. It seems simple to administer (no need to duplicate desktop/app groups) and for users to understand (i.e. no difference to them regardless of the region the hosts are in). I'm sure I'm missing something here, but I don't see what additional protection you're giving yourself by running your DR hosts in a separate host pool. The metadata is (according to the portal) stored in the "geography associated with" the primary region, not the primary region itself, so that would still be available. The Workspace is built in a particular region, but I assume that's the metadata storage location as you mentioned you could use the same Workspace for your DR desktop/app groups anyway. Thanks for the videos! Really clear, engaging and informative. I'm taking AZ-140 next week and feeling pretty confident!
Thanks for the question Dave. It comes down to blast radius that you need to prepare for. You are not wrong in your approach, however… If AVD ARM in uk south WAS NOT WORKING Then you could not manage or administer your pool in UK south So having a different pool in uk west would allow you to do that. But if you do not have a requirement to make sure you can add users to the uk south pool or force a hung user out of the pool during a disaster with ARM (azure resource manager) Then you don’t need to plan for that level of protection…make sense? By the way…in the 8+ years I have worked in Azure, ARM has only has an issue like that 1 time, in 1 region And since DR is all about mitigating risk…in general I would say your approach is fine I bring all these things up because people have different requirements Let me know how the AZ-140 goes! Happy Learning!
I'm not sure if you'd find this interesting in this context, but I had deployed fslogix using a file server. But this was via 2019 RDS collection on a local 2019 file server via share. Open go answer any questions I can.
Hi Dean, thank you for another fantastic episode !! I have a question, we are only use Personal host pool, and using ASR to replicate them to a secondary region, @11:30, you mentioned Real disaster, where your entire primary region is wiped out, in that case, the replicated personal host pool session host cannot be joined to the original host pool, how do we protect from this kind of DR scenario? Should we create a standby personal host pool in the secondary region, and manually join the replicated session host to that pool, would the old Registration key work with the new standby pool? Thanks Desheng
Thanks Desheng! As I said in the video it all depends on how big a blast you are protecting against. In the case of personal DR cross region so you don’t have ANY dependency on the original region…YES creates second host pool in the DR Region. During DR you will generate a NEW registration token in the DR host pool then have your DR personal hosts Join the DR pool
Once the DR activities are done, I would like to delete all my pooled VM's in DR region. We have planned to perform the quarterly patching ( instead of monthly) activity for that Golden image which anyway replicates to DR region as well. But the doubt is what is the max number of times that I could keep doing the sysprep on the Golden image?
There is a limit of 1001 times you can sysprep a single windows image…but if you are using AIB to start from a fresh source image every time That is not an issue.
Hello Dean, love the series. I'm using file servers instead of azure files, more so because the environments I'm managing are smaller and the cost break down of azure files is confusing. Seems to be about double than using file server attached storage ?
Are you saying that the cost of running a VM, with hard drives 24x7 looks cheaper then Azure Files??? I don’t think so. What are the prices you are getting…and where did you get them? How many users are you supporting? Have you considered Azure Files Standard?
@@AzureAcademy I manage a few clients with an average of 50-100 users and most of them have hosted LOBs so I already have an existing file server running. However, thank you for bringing up the pricing, last time I looked at azure file pricing was around August-September last year, now that I went to look at it again, it appears pricing has changed for the premium tier since then and was reduced by 33% in October.
Also, how can I ensure that app groups and it's assignments for the host pools in my primary region are always in sync with app groups and it's assignments for it's respective host pools in my DR region?
However…if you are thinking about personal host pools and people being assigned to VMs…then yes deleting VMs from the pool will not only break the user assignments to that VM…and this is not the approach I would recommend. Personal VMs are like someone’s personal laptop You’re can’t just wipe and reload it every week All their personalization would be gone. If you are treating them this way you would be better off and spend less $$$ with pooled hosts
@@AzureAcademy That was not my question. Consider I have 2 host pools. 1 for PROD in East US and another for DR in West US region. Is there a way to sync the app groups and assignments from hostpool in East US to hostpool in West US?
Cloud cache does the replication to all your file shares for you…nothing to manage. Just setup multiple shares in cloud cache settings and you are done!
@@AzureAcademy but if dr happens in región A and you are log in with profile in region B the next day when all things are recovered the profiles are different.
Cloud Cache works from both sides. which means that the settings on the host in region A with use storage 1 as primary and storage 2 as secondary. In DR the host would be configured for storage 2 as primary and storage 1 as secondary. Then all the writes will go to both the one thing to consider is that it all depends on when, how and why storage 1 was down. If it was just a DR test, then you will just need to wait for the Cloud Cache replication to complete. Same thing if Storage 1 was unavailable. All the changes need to be replicated by the cloud cache agent on the DR host to storage 1 Hope that helps!
Thanks Dean. It all made a lot of sense. Will get back to it with any doubts once I apply these practices.
Sounds good!
I like your DR approach for pooled VMs :
- Cloud Cache with secondary File share
- Shared Image Galery
Thanks!
Another great video.
Ya know, if Japan is just plain gone. Or if the eastern US is just plain gone, I'm not sure if I'm gonna be going in to work that day. Even if my charred remains aren't in one of those smoking craters, maybe there's more pressing issues at hand than work...
Ha ha…yeah you would think so…but as the old saying goes…the show must go on
😳☺️
Excellent work Dean.
Thank you!
Hi Dean, your video packed with so much useful info, I had to watch it multiple times to fully get it, good work! One quick question though, @14:30, how did you get session hosts from two different regions showing up as different icon in the same Workspace? As the App Groups give you icons, I assume they are from two different App Groups. The only way I can think of is that, you need to create one workspace with two separate App Groups within the same region, (in fact, I believe workspace and App Group has to be in the same region), then in one of the App Group you'd have host pool in regionA and another App Group you'd have host pool in regionB, right? Thanks Shengsheng
THANKS!
Once you link the App group of a host pool to a workspace all other app groups must be joined to that same work space...so to have a different workspace for DR...you need another pool.
So it is 2 different pools...1 in primary region and 1 in DR region.
Each pool has its own app groups and Session Hosts
and you have 2 workspaces. 1 in primary region for the primary pool
and the DR region has a DR work space for the DR pool
make sense?
@@AzureAcademy , thanks for your prompt response. However, @14:30, you showed the two icons, (one for DR VMs, one for Primary VMs), they are in the SAME workspace "AZ-140", so my question was how you created VMs from two different regions surfaced up as different icons in ONE workspace. sorry for the confusion...
No worries! There are three host pools that you are seeing represented in those app groups in those two work spaces. And the first workspace contains two host pools app groups and the DR workspace is from a third host pools app groups
This is to show that you could have multiple host pools represented in a single workspace or each pool represented in their own workspace
@@AzureAcademy, As always, thank you for your explanation and help
Anytime!
I like the idea of building out additional hosts in the paired Azure Region (I tend to use UK South, so DR would be UK West) and joining them to the same host pool as the production hosts. It seems simple to administer (no need to duplicate desktop/app groups) and for users to understand (i.e. no difference to them regardless of the region the hosts are in).
I'm sure I'm missing something here, but I don't see what additional protection you're giving yourself by running your DR hosts in a separate host pool. The metadata is (according to the portal) stored in the "geography associated with" the primary region, not the primary region itself, so that would still be available. The Workspace is built in a particular region, but I assume that's the metadata storage location as you mentioned you could use the same Workspace for your DR desktop/app groups anyway.
Thanks for the videos! Really clear, engaging and informative. I'm taking AZ-140 next week and feeling pretty confident!
Thanks for the question Dave. It comes down to blast radius that you need to prepare for.
You are not wrong in your approach, however…
If AVD ARM in uk south WAS NOT WORKING
Then you could not manage or administer your pool in UK south
So having a different pool in uk west would allow you to do that.
But if you do not have a requirement to make sure you can add users to the uk south pool or force a hung user out of the pool during a disaster with ARM (azure resource manager)
Then you don’t need to plan for that level of protection…make sense?
By the way…in the 8+ years I have worked in Azure, ARM has only has an issue like that 1 time, in 1 region
And since DR is all about mitigating risk…in general I would say your approach is fine
I bring all these things up because people have different requirements
Let me know how the AZ-140 goes!
Happy Learning!
I'm not sure if you'd find this interesting in this context, but I had deployed fslogix using a file server. But this was via 2019 RDS collection on a local 2019 file server via share. Open go answer any questions I can.
Ok…thanks for sharing.
Hi Dean, thank you for another fantastic episode !! I have a question, we are only use Personal host pool, and using ASR to replicate them to a secondary region, @11:30, you mentioned Real disaster, where your entire primary region is wiped out, in that case, the replicated personal host pool session host cannot be joined to the original host pool, how do we protect from this kind of DR scenario? Should we create a standby personal host pool in the secondary region, and manually join the replicated session host to that pool, would the old Registration key work with the new standby pool? Thanks Desheng
Thanks Desheng! As I said in the video it all depends on how big a blast you are protecting against. In the case of personal DR cross region so you don’t have ANY dependency on the original region…YES creates second host pool in the DR Region. During DR you will generate a NEW registration token in the DR host pool then have your DR personal hosts Join the DR pool
Once the DR activities are done, I would like to delete all my pooled VM's in DR region.
We have planned to perform the quarterly patching ( instead of monthly) activity for that Golden image which anyway replicates to DR region as well.
But the doubt is what is the max number of times that I could keep doing the sysprep on the Golden image?
There is a limit of 1001 times you can sysprep a single windows image…but if you are using AIB to start from a fresh source image every time
That is not an issue.
Can you restore VHD profiles to a new pool in a different region, using azure backup?
Azure backup won’t restore a file share to another region, but you can do the restore them copy the profile disk to the other region
Hello Dean, love the series. I'm using file servers instead of azure files, more so because the environments I'm managing are smaller and the cost break down of azure files is confusing. Seems to be about double than using file server attached storage ?
Are you saying that the cost of running a VM, with hard drives 24x7 looks cheaper then Azure Files???
I don’t think so. What are the prices you are getting…and where did you get them?
How many users are you supporting? Have you considered Azure Files Standard?
@@AzureAcademy I manage a few clients with an average of 50-100 users and most of them have hosted LOBs so I already have an existing file server running.
However, thank you for bringing up the pricing, last time I looked at azure file pricing was around August-September last year, now that I went to look at it again, it appears pricing has changed for the premium tier since then and was reduced by 33% in October.
Yup! Always good to check back ☺️
Also, how can I ensure that app groups and it's assignments for the host pools in my primary region are always in sync with app groups and it's assignments for it's respective host pools in my DR region?
Those assignments are part of the host pool and group, adding or removing hosts from the pool does not change any of the assignments.
However…if you are thinking about personal host pools and people being assigned to VMs…then yes deleting VMs from the pool will not only break the user assignments to that VM…and this is not the approach I would recommend.
Personal VMs are like someone’s personal laptop
You’re can’t just wipe and reload it every week
All their personalization would be gone.
If you are treating them this way you would be better off and spend less $$$ with pooled hosts
@@AzureAcademy That was not my question. Consider I have 2 host pools. 1 for PROD in East US and another for DR in West US region. Is there a way to sync the app groups and assignments from hostpool in East US to hostpool in West US?
Sync them…no, they are independent.
However
You can quarry one and then add those results to the other with PowerShell
How works cloud cache synchronization between shared files?
Cloud cache does the replication to all your file shares for you…nothing to manage.
Just setup multiple shares in cloud cache settings and you are done!
@@AzureAcademy but if dr happens in región A and you are log in with profile in region B the next day when all things are recovered the profiles are different.
Cloud Cache works from both sides. which means that the settings on the host in region A with use storage 1 as primary and storage 2 as secondary.
In DR the host would be configured for storage 2 as primary and storage 1 as secondary.
Then all the writes will go to both
the one thing to consider is that it all depends on when, how and why storage 1 was down.
If it was just a DR test, then you will just need to wait for the Cloud Cache replication to complete.
Same thing if Storage 1 was unavailable.
All the changes need to be replicated by the cloud cache agent on the DR host to storage 1
Hope that helps!