Jump to content

kavag

Administrators
 View Profile  See their activity

  • Posts

    222

  • Joined

  • Last visited

  • Days Won

    49

 Content Type 

Blog Entries posted by kavag

  1. kavag
    Lately, I have been under the rock of work and that is why i didn’t write about this sooner. On October 1st I received an email saying:
    http://vaggeliskappas.com/wp-content/uploads/2015/10/MVP2015.png
    As you can imagine i was eagerly awaiting for this email and the excitement i got was really great.
    I would like to thank all community members of autoexec.gr and friends, many of whom are or were fellow MVPs, for their help, support and guidance throughout this last year.
    Last but not least, I would like to thank my friends working at Microsoft Hellas for continuously supporting the community and for the confidence they showed me, ‘’pushing’’ me forward.
    I look forward to continuing my contribution to IT Pros community with the same passion for the years to come.
    The post 2015 Microsoft MVP Award on Hyper-V appeared first on Vaggelis Kappas.
  2. kavag
    What is Nano Server ?
    Nano Server is a new installation option that became available with the arrival of Windows Server 2016 Technical Preview. It is a purpose-built, stripped down operating system designed to run services and to be managed remotely.
    Windows Server 2016 will offer the following installation options:
    http://vaggeliskappas.com/wp-content/uploads/2015/11/NanoServer01-1024x638.png
    Nano Server has been designed according to Zero-Footprint model and its size on disk is around 500MB. It has no GUI, binaries or metadata in the OS image, it sets up significantly faster and requires far fewer updates and restarts than Windows Server.

    As an installation option cannot be selected during Windows Server Setup and in order to prepare and customize a VHD image with Nano Server, PowerShell should be used. Nano Server can run either as a Virtual or Physical Machine supporting the following Roles and Features:
    Role / Feature Physical / Virtual Description Compute Physical Hyper-V Role Storage Both Storage role Clustering Both Failover Clustering role Reverse Forwarders Both Helps in testing legacy tools Defender Both Anti-Malware Defender package OEM drivers Physical Selection of drivers that ship in-box with Server Core Guest drivers Virtual Drivers needed to run Nano Server as a VM In order to deploy Nano Server as a Virtual Machine into a Hyper-V host running Windows Server 2016, the following procedure could be used:
    Step 1 – Mount the ISO
    Mount the Windows Server 2016 Technical Preview ISO and copy the contents of \NanoServer folder. If the drive letter for the mounted image is G:\ run the following commands:
    md C:\NanoServer xcopy G:\NanoServer C:\NanoServer /s
    Step 2 – Dot-Source the Scripts
    The PowerShell Scripts that are included into the Installation folder need to be dot-sourced, in order to be used for the Nano Server VHD creation. Alternatively, it is possible to use another PowerShell Script that you will find at TechNet Library or GitHub, for that matter.
    cd C:\NanoServer . .\Convert-WindowsImage.ps1 . .\New-NanoServerImage.ps1
    Step 3 – Create a VHD
    Run the following command to prepare a Nano Server VHD:
    New-NanoServerImage -MediaPath G:\ -BasePath .\Base ` -TargetPath .\NSVM01 -ComputerName NSVM01 ` –GuestDrivers –language en-us -Storage -Clustering ` -EnableIPDisplayOnBoot -DomainName "MGMT.local" ` -EnableRemoteManagementPort New-NanoServerImage CmdLet allows us to specify Media and Target Path, set the Computer Name, add right set of drivers for Physical or Virtual Machine, select if the Nano Server will join an Active Directory Domain etc. Most important, it allows us to select which Roles or Features are going to be installed.
    Step 4 – Create a Virtual Machine
    As soon as the New-NanoServerImage.ps1 has been successfully completed, a new VHD with Nano Server will be available and can be attached as a boot device to a Generation 1 Virtual Machine.
    VM creation can be done with the following script:
    $VMName = "NSVM01" $VMPath = "F:\Hyper-V\"+$VMName $VirtualSwitchName = "vSwitch-INT" New-VM -Name $VMName -MemoryStartupBytes 1GB -SwitchName $VirtualSwitchName ` -VHDPath "$($VMPath)\NSVM01.vhd" -Generation 1 ` | Set-VM -ProcessorCount 2 Start-VM $VMName A couple of seconds after hitting the Start-VM Command, Nano Server will boot and the following screen will appear:
    http://vaggeliskappas.com/wp-content/uploads/2015/11/NanoServer02-1024x950.png
    Next, Login using Domain credentials and the Emergency Management Console will appear:
    http://vaggeliskappas.com/wp-content/uploads/2015/11/NanoServer03-1024x953.pngNavigate using TAB, choose Networking and get Network Adapter’s Settings as shown below:
    http://vaggeliskappas.com/wp-content/uploads/2015/11/NanoServer04-1024x950.pngHow-to Manage the Nano Server
    Nano Server has no GUI or any other console, except of Emergency Management Console that right now is very restricted and can be used only to display Network Adapter’s Properties. So, how can we manage Nano Server?
    Can be managed Remotely using the following tools:
    Remote Graphical Tools (Server Manager, Hyper-V Manager, Disk Manager etc.) PowerShell Remoting PowerShell Direct Third Party Tools & Frameworks (Chef, ASP.NET 5 etc.) Enter a PowerShell remote Session, using the following command:
    Enter-PSSession -ComputerName NSVM01 -Credential MGMT\administrator Then run Get-Process Cmdlet and get the processes that are running to the Nano Server
    http://vaggeliskappas.com/wp-content/uploads/2015/11/NanoServer05-1024x699.png
    Resources
    More information about Nano Server and its deployment Scripts you can find at the following URLs:
    http://aka.ms/NanoServer PowerShell Script to build your Nano Server Image The post Getting Started with Nano Server appeared first on Vaggelis Kappas.
  3. kavag
    The way that Network Virtualization is implemented in Hyper-V and subsequently in Microsoft Azure IaaS, enables explicitly the Routing between Virtual Subnets. This is the reason why the traffic between Virtual Subnets, that are part of the same Virtual Network, is unrestricted unless we have applied Network Security Groups.
    Network Security Groups Is a way to control traffic between Virtual Subnets of an Azure Virtual Network as well as the Internet. Moreover, Network Security Groups provide segmentation within Azure Virtual Network, by applying rules according to our needs and design.

    Until Network Security Groups became Generally Available, the only way to control traffic was endpoint based Access Control Lists. By applying ACLs to a Virtual Machine’s public endpoint, we have a way to control the ingress traffic to this port of this particular Virtual Machine. Network Security Groups takes this capability a step ahead and enables us to control all inbound as well as outbound traffic of a Virtual Machine or a Virtual Subnet.
    How does a Network Security Group (NSG) work ?
    A Network Security Group has a name and a descriptive label and is associated to an Azure Region. It contains Inbound and Outbound traffic rules and can be applied to a Virtual Machine, a Virtual Subnet or both.
    http://vaggeliskappas.com/wp-content/uploads/2015/06/NSG-01-300x265.png
    Associating an NSG to a VM – When an NSG is directly associated to a VM, the Network access rules in the NSG are directly applied to all traffic that is destined to the VM.
    Associating an NSG to a Subnet – When an NSG is associated to a subnet, the Network access rules in the NSG are applied to all the VMs in the subnet.
    Associating an NSG to a Subnet and a VM – It is possible that you can associate an NSG to a VM and a different NSG to the subnet where the VM resides. This is supported and in this case the VM gets two layers of protection. On the Inbound traffic the packet goes through the access rules specified in the subnet followed by rules in the VM and in the Outbound case it goes through the rules specified in the VM first before going through the rules specified in the subnet.
    Priorities and Default Rules
    As we mentioned above, an NSG contains Inbound and Outbound traffic Rules that we create according to our needs. These Rules are processed in the order of priority. Rules with lower priority number are processed before those with higher priority number and so on. Default rules are also there for a Network Security Group. These rules cannot be deleted but they have the lowest priority and, normally, they will be overridden.
    Azure Virtual Network
    Let’s assume that we want to deploy a three-tier application in Microsoft Azure IaaS offering. In this case, we create a Virtual Network as illustrated in the following figure:
    http://vaggeliskappas.com/wp-content/uploads/2015/06/NSG-02-1024x800.png
    http://vaggeliskappas.com/wp-content/uploads/2015/06/NSG-04-e1433178124170.png
    By default, Virtual Machines that are deployed to the Virtual Subnets (Front, App, DB) can communicate to each other and can have access to the Internet. This default behavior in some cases is not enough and Security and Access Control needs to be applied. By using Network Security Groups, the Virtual Network’s security is strengthened and Access Control Rules to inbound and outbound traffic are enforced.
    Create and use Network Security Groups – Step-By-Step
    As a demonstration, we are going to use the Virtual Network that we’ve created in the previous example. Let’s assume that we want to implement a more restrictive scenario, like the one shown in the following figure:
    http://vaggeliskappas.com/wp-content/uploads/2015/06/NSG-03-1024x740.pngIn order to achieve the designed security and access control we should create traffic rules, that they can be summarized in the following table:

      Front End
    Subnet Application
    Subnet Database
    Subnet Internet Front End
    Subnet - Allow - TCP/80 Deny - All Allow - All Application
    Subnet Allow - TCP/80 - Allow - TCP/1433 Allow - TCP/3389 Database
    Subnet Deny - All Allow - TCP/1433 - Allow - TCP/3389 Internet Allow - All Allow - TCP/3389 Allow - TCP/3389 - Network Security Groups can be created and applied using PowerShell and REST API. In this example we are going to use PowerShell. As always, we will use the latest PowerShell Azure Module which can be downloaded from Azure Portal.
    Using the following script we can create and apply Access Control Rules and Network Security Groups
    # Setting the variables $AzureRegion = 'West Europe' $AzureVNET = 'Three-Tier-VNET' # ---------------------Database Subnet Rules ------------------------- # Create a Network Security Group for Database Subnet New-AzureNetworkSecurityGroup -Name "DB-NSG" -Location $AzureRegion -Label "NSG for Database Subnet of $AzureVNET" # Adding a Rule to deny Inbound TCP traffic from Front End Subnet Get-AzureNetworkSecurityGroup -Name "DB-NSG" | Set-AzureNetworkSecurityRule -Name FEDeny -Type Inbound -Priority 100 ` -Action Deny -SourceAddressPrefix '172.16.1.0/24' -SourcePortRange '*' -DestinationAddressPrefix '172.16.3.0/24' ` -DestinationPortRange '*' -Protocol TCP # Adding a Rule to allow Inbound SQL (TCP/1433) traffic from Application Subnet Get-AzureNetworkSecurityGroup -Name "DB-NSG" | Set-AzureNetworkSecurityRule -Name SQL -Type Inbound -Priority 110 ` -Action Allow -SourceAddressPrefix '172.16.2.0/24' -SourcePortRange '*' -DestinationAddressPrefix '172.16.3.0/24' ` -DestinationPortRange '1433' -Protocol TCP # Adding a Rule to allow Inbound RDP (TCP/3389) traffic from Internet, for management Get-AzureNetworkSecurityGroup -Name "DB-NSG" | Set-AzureNetworkSecurityRule -Name RDP -Type Inbound -Priority 120 ` -Action Allow -SourceAddressPrefix 'INTERNET' -SourcePortRange '*' -DestinationAddressPrefix '172.16.3.0/24' ` -DestinationPortRange '3389' -Protocol TCP # Assign the Network Security Group to Database Subnet Get-AzureNetworkSecurityGroup -Name "DB-NSG" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName $AzureVNET -SubnetName "Database" # Network Security Group Rules and details Get-AzureNetworkSecurityGroup -Name "DB-NSG" -Detailed # ---------------------Application Subnet Rules ------------------------- #Create a Network Security Group for Application Subnet New-AzureNetworkSecurityGroup -Name "APP-NSG" -Location $AzureRegion -Label "NSG for Application Subnet of $AzureVNET" # Adding a Rule to deny Inbound TCP traffic from Database Subnet Get-AzureNetworkSecurityGroup -Name "APP-NSG" | Set-AzureNetworkSecurityRule -Name DBDeny -Type Inbound -Priority 100 ` -Action Deny -SourceAddressPrefix '172.16.3.0/24' -SourcePortRange '*' -DestinationAddressPrefix '172.16.2.0/24' ` -DestinationPortRange '*' -Protocol TCP # Adding a Rule to allow Inbound WEB (TCP/80) traffic from Front End Subnet Get-AzureNetworkSecurityGroup -Name "APP-NSG" | Set-AzureNetworkSecurityRule -Name WEB -Type Inbound -Priority 110 ` -Action Allow -SourceAddressPrefix '172.16.1.0/24' -SourcePortRange '*' -DestinationAddressPrefix '172.16.2.0/24' ` -DestinationPortRange '80' -Protocol TCP # Adding a Rule to allow Inbound RDP (TCP/3389) traffic from Internet, for management Get-AzureNetworkSecurityGroup -Name "APP-NSG" | Set-AzureNetworkSecurityRule -Name RDP -Type Inbound -Priority 120 ` -Action Allow -SourceAddressPrefix 'INTERNET' -SourcePortRange '*' -DestinationAddressPrefix '172.16.2.0/24' ` -DestinationPortRange '3389' -Protocol TCP # Assign the Network Security Group to Database Subnet Get-AzureNetworkSecurityGroup -Name "APP-NSG" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName $AzureVNET -SubnetName "Application" # Network Security Group Rules and details Get-AzureNetworkSecurityGroup -Name "APP-NSG" -Detailed We can get all the details about applied Network Security Groups using the command:
    Get-AzureNetworkSecurityGroup -Name "DB-NSG" -Detailed http://vaggeliskappas.com/wp-content/uploads/2015/06/NSG-05-e1433179942554.png
    Get-AzureNetworkSecurityGroup -Name "APP-NSG" -Detailed http://vaggeliskappas.com/wp-content/uploads/2015/06/NSG-06-e1433180072727.png References
    About Network Security Groups Network Security Groups  
    The post Secure Azure Virtual Network using Network Security Groups appeared first on Vaggelis Kappas.
  4. kavag
    In the unlikely event that you have not heard, Windows Server 2016 Technical Preview 3 (TP3) is now available for download.
    You can get it from TechNet Evaluation Center
    http://vaggeliskappas.com/wp-content/uploads/2015/08/WS2016TP3-Eval.png
    You can find it in Azure’s Image Gallery

    http://vaggeliskappas.com/wp-content/uploads/2015/08/WS2016TP3-Azure.png
    You can find it on your MSDN Subscription
    http://vaggeliskappas.com/wp-content/uploads/2015/08/WS2016TP3-MSDN.png
    For more information about TP3 you can visit the following Microsoft blogs:
    What’s new in Windows Server 2016 and System Center 2016 Technical Preview 3
    New Windows Server Preview Fuels Application Innovation with Containers, Software-Defined Datacenter Updates
    Announcing Windows Server 2016 Containers Preview
    Enjoy !
    The post Windows Server 2016 Technical Preview 3 (TP3) is now available appeared first on Vaggelis Kappas.
  5. kavag
    Every time I present a session about Microsoft Azure IaaS, the most common question is about Virtual Machines’ capability of getting more than one Virtual Network Interface (vNIC). At TechEd Europe 2014, Microsoft announced support for multiple Network Interfaces (vNICs) in Azure VMs, as well as other additions to Azure Virtual Networks like Network Security Groups.
    Moreover, the capability of adding more than one vNIC to a Virtual Machine will enable Virtual Appliances scenarios like Firewalls, Load Balancers etc.
    In this blogpost we are going to explore all the necessary steps for creating a Virtual Machine with multiple vNICs in Azure IaaS. So, let’s get started.

    How to create a Virtual Machine with multiple NICs
    According to our requirements we need to design our Virtual Network with all the required Subnets. The design phase should always precede every implementation. As an example, we can use the following diagram
    http://vkappas.cloudapp.net/wp-content/uploads/2015/01/Multi-NIC-01.png
    In this diagram, a Virtual Network for supporting a common three-tier application is displayed. This Virtual Network has three subnets, Front-End Subnet with network number 172.16.1.0/24, Mid-Tier Subnet with network number 172.16.2.0/24 and Back-End Subnet with network number 172.16.3.0/24. The scope of this blogpost is to create a Virtual Machine with three Network Interfaces, one in each subnet.
    Prerequisites and Constraints
    Multiple NICs can be added to any Azure Virtual Machine, except Basic Tier SKUs. However, the number of NICs, that can be created for a Virtual Machine, depends on its size and is shown in the following table:
     VM Size (Standard SKUs) NICs (max allowed per VM) Large (A3) and A6 2 Extra Large (A4) and A7 4 A9 2 D4 4 D13 4 – Multiple NICs can be added only to Virtual Machines belonging to a Virtual Network (VNET). Non-VNET VMs are not supported.
    – Every Azure Virtual Machine with Multiple NICs has a “default” NIC and additional ones. Internet traffic and its corresponding VIP is only supported on the “default” NIC. There is only one VIP to the IP of the default NIC.
    – A Virtual Machine with Multiple NICs cannot be used as an IP router. The IP packets must be destined to or sourced from one of its IP addresses.
    – The order of the NICs from inside the VM will be random, and could also change across Azure infrastructure updates. However, the IP addresses, and the corresponding Ethernet MAC addresses will remain the same. For example, assume Eth1 has IP address 10.1.0.100 and MAC address 00-0D-3A-B0-39-0D; after an Azure infrastructure update and reboot, it could be changed to Eth2, but the IP and MAC pairing will remain the same. When a restart is customer-initiated, the NIC order will remain the same.
    Create the required Virtual Network
    With the prerequisites and constraints being mentioned, let’s proceed to create the required Virtual Network. As written above, our VNET, with a name of DMZ-VNET, has three subnets: Front-End Subnet (172.16.1.0/24), Mid-Tier Subnet (172.16.2.0/24) and Back-End Subnet (172.16.3.0/24). We can use PowerShell or the management portal to create this VNET and once completed, it will look like this:
    http://vkappas.cloudapp.net/wp-content/uploads/2015/01/Multi-NIC-02.pngCreate the Multi-NIC VM
    The only way, for the time being, to create a Virtual Machine and add Multiple NICs to it, is via PowerShell. That is why we need the latest version of Azure PowerShell Module, which we can be found at http://azure.microsoft.com.
    http://vkappas.cloudapp.net/wp-content/uploads/2015/01/Multi-NIC-03.png
    Once the module is installed, we can use the following commands to create a new Virtual Machine (DMZ-GW) with three Network Interface Cards, each one connected to desired subnet. For better understanding, we have split the script in sections:
    # Create a Storage Account New-AzureStorageAccount -StorageAccountName dmzsa -Location "West Europe" New-AzureService -ServiceName "DMZCS" -Location "West Europe" # Select the Subscription we are going to work with Set-AzureSubscription -SubscriptionName "MSDN-Kappas" -CurrentStorageAccountName "dmzsa" Select-AzureSubscription -SubscriptionName "MSDN-Kappas" -Current # Setting some variables $location = "West Europe" $serviceName = "DMZCS" $vnet = "DMZ-VNET" $subscriptionName = 'MSDN-Kappas' $storageAccount = 'dmzsa' # Select an OS Image $imageFamily = "Windows Server 2012 R2 Datacenter" $imageName = Get-AzureVMImage | where { $_.ImageFamily -eq $imageFamily } | sort PublishedDate -Descending | select -ExpandProperty ImageName -First 1 # Enter required admin credentials $cred = Get-Credential -Message "Enter admin credentials for the VM(s)" $adminUser = $cred.UserName $pwd = $cred.GetNetworkCredential().Password # Define Virtual Machine's configuration $vm1 = New-AzureVMConfig -ImageName $ImageName -Name "DMZ-GW" -InstanceSize ExtraLarge | Add-AzureProvisioningConfig -Windows -AdminUsername $adminUser -Password $pwd | # Configure the "Default NIC" Set-AzureSubnet -SubnetNames "Front-End" | Set-AzureStaticVNetIP -IPAddress "172.16.1.10" | # Configure additional NICs Add-AzureNetworkInterfaceConfig -Name "MidTier NIC" -SubnetName "Mid-Tier" -StaticVNetIPAddress "172.16.2.10"| Add-AzureNetworkInterfaceConfig -Name "BackEnd NIC" -SubnetName "Back-End" -StaticVNetIPAddress "172.16.3.10" # Create the Virtual Machine New-AzureVM -ServiceName $serviceName ` -Location $location ` -VNetName $vnet ` -VMs $vm1 Multiple NICs Validation
    Once the Virtual Machine is created, we can connect via RDP in order to verify its Multiple NICs existence.
    http://vkappas.cloudapp.net/wp-content/uploads/2015/01/Multi-NIC-041.png
    http://vkappas.cloudapp.net/wp-content/uploads/2015/01/Multi-NIC-05.png
    As you can see, we have successfully created an Azure Virtual Machine with three NICs, as shown in the following diagram:
    http://vkappas.cloudapp.net/wp-content/uploads/2015/01/Multi-NIC-06.png

    The post Create a Virtual Machine with Multiple NICs in Azure IaaS appeared first on Vaggelis Kappas.
  6. kavag
    One question that is coming up too often, at least at TecEd Europe 2014, is if it’s possible to integrate an Azure AD that you got when you signed up to Office 365 with the one you have got when you subscribed to Microsoft Azure. The short answer is yes, it is possible and if you want to learn how this integration happens, then keep reading!
    This scenario means that there are two separate directories. The first one was created when you setup your Office 365 Subscription, while the second one came with Microsoft Azure Subscription.
    If you want to integrate these two directories, Office 365 Tenant into the Microsoft Azure Subscription then you should follow these few easy and quick steps.
    Prerequisites
    Office 365 Subscription Global Administrator account. Microsoft Azure Subscription created by a Microsoft account. Steps:
    Logon to Microsoft Azure Management Portal
    https://manage.windowsazure.com Go to Active Directory | New | Directory | Custom Create
    http://vkappas.cloudapp.net/wp-content/uploads/2014/10/AAD-Integration01.png3. Change the Directory dropdown from the default Create new directory to Use existing directory and click the Check box.
    http://vkappas.cloudapp.net/wp-content/uploads/2014/10/AAD-Integration02.png
    What happens next is that you are logged out of the Microsoft Azure administrative account and you are redirected to the Office 365 portal logon.
    Next Steps:
    Logon with a Global Administrator account from the Office 365 tenant that you would like to integrate with. After sign-in you are prompted to add the Microsoft Azure administrator account as a global administrator for the Office 365 Tenant directory, click on Continue. Finally, logout of the Office 365 global administrator account and then logon to https://manage.windowsazure.com with your global administrator account. Now you have your directories integrated. Enjoy !  
     
    The post Integrate Microsoft Azure Active Directory tenant with Office 365 appeared first on Vaggelis Kappas.
  7. kavag
    What an exciting day October 1st was!
    I received an email saying:http://vkappas.cloudapp.net/wp-content/uploads/2014/10/MVP01.png
    I’ m very proud and honored for this award as it shows that my work and effort have been recognized and this fact gives me the strength and the inspiration to continue my contribution to the IT Pros community.

    I would like to thank all community members, autoexec.gr and friends, many of whom are or were fellow MVPs, for their help, support and guidance throughout this last year.
    Last but not least I would like to thank my friends working at Microsoft Hellas for continuously supporting the community and for the confidence they showed me, ‘’pushing’’ me forward.
    I look forward to continuing my contribution to the IT Pros community with the same passion for the years to come.
    The post Microsoft Hyper-V MVP Award 2014 (EN) appeared first on Vaggelis Kappas.
  8. kavag
    Αυτό που ήταν γνωστό μέχρι τώρα και τονιζόταν ιδιαιτέρως, ήταν να μην αποδίδεται για οποιοδήποτε λόγο Static IP address στα Virtual Machines του Microsoft Azure IaaS. Ακόμη και εάν τα VMs προορίζονταν για Domain Controllers ή για DNS Servers.
    Όσοι μάλιστα το είχαν προσπαθήσει είδαν τα VMs που είχαν δημιουργήσει να εξαφανίζονται, ξαφνικά, από την κονσόλα διαχείρισης.
    Με τις τελευταίες όμως βελτιώσεις που έγιναν στις υπηρεσίες του Azure IaaS (Μάιος 2014), στην περίπτωση που το VM συνδέεται σε κάποιο Virtual Network, έχουμε την δυνατότητα πλέον να επιλέξουμε την επιθυμητή IP διεύθυνση που θα πάρει όταν θα ξεκινήσει ή μετά την επανεκκίνηση.

    Εάν έχουμε λοιπόν ένα Virtual Network που περιλαμβάνει υποδίκτυα (Subnets) όπως το παρακάτω
    http://vkappas.cloudapp.net/wp-content/uploads/2014/09/Static-DIP-01.png
     και δημιουργήσουμε ένα VM που θα το συνδέσουμε π.χ. στο υποδίκτυο ADDS
    http://vkappas.cloudapp.net/wp-content/uploads/2014/09/Static-DIP-02.png
    αυτό θα πάρει την πρώτη διαθέσιμη διεύθυνση από το Subnet, δηλαδή την 10.10.4.4. Tο δεύτερο VM που θα συνδεθεί στο δίκτυο αυτό θα πάρει την 10.10.4.5 κ.ο.κ.
    Πρέπει να σημειώσουμε ότι οι τρείς πρώτες διευθύνσεις κάθε δικτύου και υποδικτύου, από .1 έως .3, είναι κατειλημμένες από το Azure και δεν είναι διαθέσιμες.
    http://vkappas.cloudapp.net/wp-content/uploads/2014/09/Static-DIP-03.png
    Όσο τα Virtual Machines είναι εν λειτουργία θα διατηρήσουν τις IP διευθύνσεις που τους έχει δώσει το Azure, ακόμη και στην περίπτωση του reboot ή του Shutdown μέσα από το λειτουργικό.
    Εάν όμως σταματήσουν (Stop) από το Management Portal ή μέσω του PowerShell τότε γίνονται de-provisioned. Αυτό σημαίνει ότι την επόμενη φορά που θα ξεκινήσουν θα αναζητήσουν την πρώτη διαθέσιμη IP διεύθυνση.
    Έτσι εάν κάνουμε Stop τα Virtual Machines, μέσω PowerShell και ξεκινήσουμε πρώτα το DC01 και μετά το DNS01 τότε οι IP διευθύνσεις που θα έχουν θα είναι οι εξής
    http://vkappas.cloudapp.net/wp-content/uploads/2014/09/Static-DIP-04.png
    Βλέπουμε λοιπόν ότι τώρα που ξεκίνησε πρώτο το DC01 πήρε την πρώτη διαθέσιμη διεύθυνση IP δηλαδή την 10.10.4.4.
    Όπως είπαμε και παραπάνω, μέχρι τις πρόσφατες αλλαγές και βελτιώσεις, για να είμαστε σίγουροι για την διεύθυνση IP που θα πάρει ένα VM θα έπρεπε να ελέγχουμε την σειρά εκκίνησης (Startup Sequence).
    Αλλαγές Μαΐου 2014, Static Internal IP Address (DIP)
    Για ορισμένα Virtual Machines, όπως για παράδειγμα οι DNS Servers ή οι Domain Controllers το να αλλάζουν διευθύνσεις IP είναι κάτι που δεν είναι επιθυμητό.
    Τώρα λοιπόν μπορούμε εάν θέλουμε, μέσω του PowerShell, να εξασφαλίσουμε διευθύνσεις IP από το Virtual Network που έχουμε αναπτύξει στο Azure γι’ αυτά τα VMs.
    Ας δούμε πως
    Έλεγχος διαθεσιμότητας διεύθυνσης IP
    Για να δώσουμε μία διεύθυνση IP, θα πρέπει πρώτα να είμαστε σίγουροι ότι αυτή είναι διαθέσιμη. Ο έλεγχος της διαθεσιμότητας μιας διεύθυνσης IP γίνεται με την εντολή Test-AzureStaticVNetIP.
    Test-AzureStaticVNetIP -VNetName Labs-VNET -IPAddress 10.10.4.11 IsAvailable : True AvailableAddresses : {} OperationDescription : Test-AzureStaticVNetIP OperationId : f8c1df87-56ed-0adb-8c74-24bd82eeebe6 OperationStatus : Succeeded Απαραίτητο είναι το όνομα του Virtual Network στα Subnets του οποίου είναι η IP διεύθυνση για την οποία γίνεται ο έλεγχος.
    Ορισμός static internal IP (DIP) σε υπάρχον VM
    Αφού κάναμε έλεγχο για την διαθεσιμότητα της επιθυμητής διεύθυνσης IP και συγκεκριμένα της 10.10.4.11, μπορούμε να την δώσουμε σε ένα από τα Virtual Machines που έχουμε ήδη δημιουργήσει, π.χ. στο DNS01
    Get-AzureVM -ServiceName Labs-CS -Name DNS01 | Set-AzureStaticVNetIP -IPAddress 10.10.4.11 | Update-AzureVM Η εντολή Update-AzureVM θα κάνει την απαραίτητη επανεκκίνηση στο VM για να πάρει την επιθυμητή διεύθυνση IP
    http://vkappas.cloudapp.net/wp-content/uploads/2014/09/Static-DIP-05.png
    Ορισμός static internal IP (DIP) σε νέο VM
    Εάν δημιουργούμε Virtual Machines μέσω PowerShell, έχουμε την δυνατότητα να δώσουμε την επιθυμητή διεύθυνση IP στην φάση της υλοποίησης
    $ImageName = "a699494373c04fc0bc8f2bb1389d6106__Windows-Server-2012-R2-201408.01-en.us-127GB.vhd" $admin="vkappas" $passwd="Admin@2014" New-AzureVMConfig -Name "DNS02" -InstanceSize "Small" -ImageName $ImageName | Add-AzureProvisioningConfig -Windows -AdminUsername $admin -Password $passwd | Set-AzureSubnet -SubnetNames "ADDS" | Set-AzureStaticVNetIP -IPAddress "10.10.4.12" | New-AzureVM -ServiceName "Labs-CS" -AffinityGroup "Labs-AG" http://vkappas.cloudapp.net/wp-content/uploads/2014/09/Static-DIP-06.png
    Αφαίρεση static internal IP (DIP)
    Όπως δώσαμε την επιθυμητή διεύθυνση IP σε ένα VM, μπορούμε και να την αφαιρέσουμε ώστε αυτό να λάβει την πρώτη ελεύθερη κατά τα γνωστά.
    Η εντολή που θα χρησιμοποιήσουμε είναι η Remove-AzureStaticVNetIP ως εξής
    Get-AzureVM -ServiceName labs-CS -Name DNS01 | Remove-AzureStaticVNetIP | Update-AzureVM  
    The post Configuring a Static Internal IP Address (DIP) for a VM in Azure VNET appeared first on Vaggelis Kappas.
  9. kavag
    Με μεγάλη χαρά την πρώτη Οκτωβρίου έλαβα ένα email που έλεγε τα παρακάτωhttp://vkappas.cloudapp.net/wp-content/uploads/2014/10/MVP01.png
    Είμαι πολύ χαρούμενος και υπερήφανος για τη διάκριση αυτή, η οποία μου δίνει τη δύναμη όσο και την έμπνευση, να συνεχίσω με αμείωτο ζήλο την προσπάθεια και την συνεισφορά στην κοινότητα των IT Pros.

    Θα ήθελα να ευχαριστήσω όλα τα μέλη της κοινότητας των IT Pros, το autoexec.gr και τους φίλους, πολλοί από τους οποίους είναι ή ήταν συν-MVPs, για όλη τη βοήθεια, την υποστήριξη και την καθοδήγηση τους όλο αυτό το χρονικό διάστημα.
    Τέλος θα ήθελα, ιδιαίτερα, να ευχαριστήσω τους φίλους στη Microsoft τόσο για τη διαρκή υποστήριξή τους στην κοινότητα όσο και για την εμπιστοσύνη που μου έδειξαν.
    Σας ευχαριστώ και πάλι και υπόσχομαι να συνεχίσω με αμείωτο ενδιαφέρον και πάθος όλη την προσπάθεια και την συνεισφορά στην κοινότητα των IT Pros.
    The post Microsoft Hyper-V MVP Award 2014 appeared first on Vaggelis Kappas.
×
×
  • Create New...