Save
Saving
  • A
    Adam Tyler

    So I just discovered that a superscope can be used to group multiple DHCP scopes to assign IP addresses on the same network segment. WHAT? This has always been a no no in my experience. Can someone explain to me how the heck a client on the same physical broadcast domain (network segment) knows what scope to receive an IP address from in this scenario?

    Found this description online
    "Superscopes are also used to support DHCP clients on a single physical network segment (such as a single Ethernet LAN segment) on which multiple logical IP networks are used. When more than one logical IP network is used on each physical subnet or network, such configurations are called multinets"

    Regards,
    Adam Tyler

    posted in Microsoft read more
  • A
    Adam Tyler

    Thanks Ronnie. Just read through that article. It covers three points... The first to configure a VLAN tag on the external virtual switch. My understanding of this setting is that it only exists to allow the "host" operating system to drop into a particular VLAN for management purposes only. In my lab, the VLAN setting on the virtual switch is titled "Enable virtual LAN identification for management operating system".

    The second point discusses setting a VLAN tag on the VMs vNIC. This would allow the VM to send tagged packets using the VLAN specified. Which would only work between physical hosts if the physical switchport was configured as a trunk. Correct?

    The third point discusses a couple of options if the VM needs to use more than one VLAN. option 1 is to add more than one vNIC with a different VLAN specified. Again, this would only work between physical hosts if the physical switchport was configured as a trunk.. Correct?

    Option 2 is configure the VMs vNIC as a trunk using the special super secret hidden command: Set-VMNetworkAdapterVlan... However this would also require that the physical switchport be configured as a trunk for VMs between hosts to communicate. It would also require that the guest VM OS tag the traffic prior to entering the vSwitch.

    Am I close?

    Regards,
    Adam Tyler

    posted in Microsoft read more
  • A
    Adam Tyler

    Thanks Adam and Cherokee... So the exam objectives are here? I am looking at taking the 70-743 upgrade exam tomorrow morning.
    https://www.microsoft.com/en-us/learning/exam-70-743.aspx

    The only thing I found was a November 2018 update that appears the Nano feature is redacted from the exam.. Not sure I understand why, but....
    https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE2IoQP

    Regards,
    Adam Tyler

    posted in Microsoft read more
  • A
    Adam Tyler

    @Ronnie-Wong Way to confuse the heck out of me Ronnie!!! ;)

    On your first point... You said that adding another vNIC to each VM and assigning a new VLAN tag would allow for communication between physical Hyper-V servers? If so, I have to disagree. VMs on the same server using the same VLAN tag would be able to communicate as is the case in the original screenshot between VM1 and VM2. However, VMs hosted on different Hyper-V servers or different virtual switches would not be able to communicate depending on the physical switchport configuration and cabling of the physical network. In the case of this practice question, the switchports are configured as access ports and should just drop tagged packets all together. Or did I misunderstand your comment on point one?

    On your second point, you actually made me aware of a feature I didn't know existed in Hyper-V. I have created port groups in VMware ESXi on distributed virtual switches which support trunking, but didn't realize that Hyper-V supported this too. For some reason Microsoft didn't feel it was important to expose this feature to the GUI, but sure enough, you can create a trunk port passed directly to the VMs vNIC using a command like the following..

    Set-VMNetworkAdapterVlan -VMName Demo -Trunk AllowedVlanIdList 100-150 -NativeVlanId 2

    Assuming the physical network switchport was still set in "Access Mode", the untagged traffic coming from the "NativeVlanId" might be passed between physical hosts over physical network switching? Am I following that correctly? Even if the access port VLAN setting on the physical switch didn't match the VMs Native VLAN Id? In any case, this feels like a one off that probably won't show on the exam.

    Regards,
    Adam Tyler

    posted in Microsoft read more
  • A
    Adam Tyler

    Riddle me this batman, if you were taking a Microsoft exam for Server 2016 and ran across a question that asked about ReFS and deduplication support, how would you answer? Looks like after svr 16 build 1709, this is actually supported. Whereas it used to only be supported on NTFS.

    Regards,
    Adam Tyler

    posted in Microsoft read more
  • A
    Adam Tyler

    Thanks Adam, going back to my posted get-cluster output... Does the domain output of contoso.com indicate the cluster nodes are domain joined or can that field be populated if they are workgroup only servers using clustering with a domain suffix only? Trying to figure out if the output is enough information to indicate if the cluster could support remote-updating only, self-updating only, or both... Again it throws me all over the place because of the admin access point being DNS. Initially I thought workgroup cluster, which would rule out remote-updating as an option. I assume all clusters support self-updating regardless of the deployment method.

    Regards,
    Adam Tyler

    posted in Microsoft read more
  • A
    Adam Tyler

    Ya, this one is weird. All over Nano documentation is says that to install the Hyper-V role you simply use the -compute option when creating the image. It doesn't even look like "Microsoft-NanoServer-Compute-Package" is a valid "Package" at this point.. But the link you forwarded shows it quite clearly. Weird. A moving target to be sure.

    Regards,
    Adam Tyler

    posted in Microsoft read more
  • A
    Adam Tyler

    Can someone help me make sense of this test question?

    WSUS deployment contains one upstream server that is located on the company's perimeter network and several downstream servers located on the internal network. A firewall separates the upstream server from the downstream servers. You need to meet the following requirements..

    Encrypt all communication between the internal network and the perimeter network, including all WSUS communications.

    0_1549494412464_14f4fd08-a66f-4ff9-b9d4-5a96f095dfc3-image.png

    Reference: https://docs.microsoft.com/en-us/windows-server/administration/windows-server-update-services/deploy/2-configure-wsus

    posted in Microsoft read more