Microsoft Azure Training - [9] Azure Virtual Networks - Part 3 (Exam 70-533)

This is the Part 3 of the Azure Virtual Networks session. In this session I talk about what Affinity Groups are and why they were a good idea in the past and how they are being currently deprecated by Microsoft. There is a demonstration of creating Affinity Groups and also where Affinity Groups can be associated when creating specific resources. In the second part of this session I discuss about Azure DNS for internal VM name resolution and where they are applicable and their limitations. As usual a detailed demonstration is provided to see all the concepts discussed about internal name resolution and its limitations.

Please subscribe to the channel to stay updated about the training series. Also please comment on the training videos. Thank you!
Other sessions of this training series (2018 Edition):

Twitter : @shawnismail

[PradeepSingh-lyoq]

Thanks Shawn..I am a developer with good hands-on on MS technologies. I have been going through various Azure online material for quite a few months, but it was really not easy to understand Azure until I found your training videos. These videos are amazing and made my learning so easy and quickly..Thank you again.

[VinaySingh-gwyi]

Excellent Videos Shawn...Before going through your videos I had seen series from Pluralsight, CBTnuggets, Linux Academy but none of them match to your series..Though some of the content has become obsolete but I will go through all your videos for my prep...Thanks a lot again!!

[kashifaliuk]

Thanks Shawn...amazing videos....the way you are teaching even my 10 years old son can learn....thx again.

[rkottees]

You are doing an excellent job! Thank you very much!

[AyanMullick]

"Ping -a" is getting the netbios name, I think not the FQDN. One can put the same in the hosts file and then it should ping with name as well.

[sammesel]

Hi Shawn, great sessions so far.
Anywhere we can download the slide decks and scripts from ?appreciated

[VeniVV]

Wouldn't the resolution working with the IP be because of RARP vs ARP. ARP broadcasts the Hostname to get the IP where as RARP has the IP and gets the Hostname. They are two separate protocols

[TTTtttFREE]

I appreciate your training course. Thank you very much.
Could you talk a little more about implement Website, Storage, and Azure Active. These chapters  are in the exam objective of Ref Exam 70-533 (according to Michael Washam and Rick Rainey 's book. Again thank you.

[infosatheesh]

The reason that VMs from different cloud service doesn't identify each
other is that we are not giving FQDN, and the FQDN can be found from
ifconfig of VM. this format is like
But the drawback is that the number 'c9' in that FQDN will change at
any time, so it is not reliable. But using this FQDN, we will be able to
reach VM across different cloud services.

The reason is that the DNS search domain for a VM is So, from VM1 to VM2 in same cloudservice1 has same search domain, so with just VM name, it will append search domain as and so it works. But for VMs in different cloud service, if we try to use just hostname, it appends to which is wrong. (it should be Thats why we just VM name doesn't work and correct FQDN works.

Note: here the term "c9" is just for explanatory purposes, we will get this different for each cloud services, and also this will change over time.

[sayanchakraborty]

Is the cloud service has been no longer a mandatory field now while creating a vm in azure portal?

[leiyang]

Does it the convention that the default DNS name provided by Azure the same name as the cloud service name ? where is the location of that default DNS server ?

[sumanbikram]

Amazing videos by you shawn.
I just have some queries..
(a) What I need to do if I want multiple nics on server?
(b) Is there a way to avoid public IPs (VIP) for certain server categories like AD/SQL/APP server? I want them not to have any public IPs.

[hansungpil]

Ping -a is ping. It doesn't do PTR resolution for operation, just gets hostname from DNS server or local cache. Name resolution is FQDN(hostname) to IP.
But it's interesting, inter Cloud Service PTR resolution is allowed but not Name resolution using default DNS server provided by Azure.
I think Azure does this on purpose to prevent something bad.

[justfun]

Hi Shawn, Great Video Sessions So far. I m trying to create affinity group. but i not able to create because there is no option "Add An Affinity Group." What to do .Can u pls suggest me

[rahul]

The reason you cannot ping with hostname when the VMs are in different cloud services:

1) When you try to ping a hostname, the DNS suffix will be attached and it will try to resolve the name.
2)In the first scenario, since the cloud services are different, when you try to ping crangervM100 from crangervm200, it tries to append dns suffix and then tries to resolve
So name resolution will fail since no such FQDN exists.
Test this, i am sure you will be able to ping crangervm100 if you ping by

3) When you do a Ping -a IP, all it does is gives back the Hostname of crangerVM100 and not the FQDN
Hence the confusion


It is like, i am trying to call Shawn but the phone does not connect. Because i did not specify i want to call Shawn Ismail.
On the other hand, if i directly call your phone number, i can reach you and i ask who is this you say its Shawn. But you dont specifically say Shawn Ismail

[debopambasu]

the name is resolving as they are in same subnet...

[markbulmer]

Great Video! I found the following interesting on the reverse lookup:

When you ping rangervm200 from rangervm100 it queries the DNS-server with the following hostname: rangervm200.rangervm100.cloudapp.net, like Rahul said.

However, when doing reverse look-up, it looks it up in a special name-space (in-addr.arpa) reserved for reverse-lookups, that removes the domain name.