Search the Community

A client of mine has asked me if it would be possible to run pfSense as a Microsoft Azure IaaS Virtual Machine. pfSense® software is a free, open source customized distribution of FreeBSD, specifically tailored for use as a firewall and router that is entirely managed via web interface. At that time, I had in mind that running FreeBSD 10 under Hyper-V and in Microsoft Azure, is something that can be done. So, I decided to build a deployment as a Proof of Concept and to write a blog post about this deployment. This post will provide instructions and all the necessary steps to prepare, upload and run pfSense-2.2.3 in Microsoft Azure. Please note, that FreeBSD is not currently an endorsed distribution in Microsoft Azure and therefore is not supported. Resources Latest Stable Version of pfSense Running FreeBSD in Azure User Defined Routes and other Azure Virtual Network enhancements that announced at Microsoft Ignite 2015 Design Let’s put, what we want to achieve, into context. The deployment’s design is as follows: http://vaggeliskappas.com/wp-content/uploads/2015/07/pfSense01.png Procedure In order to prepare a pfSense image for Microsoft Azure, we should download the latest x64 image and install it locally, on a server with Windows Server 2012 R2, as a Hyper-V Virtual Machine: Download the latest x64 pfSense image from Latest Stable Version of pfSense (As of July 2015 the latest version is 2.2.3) Decompress the image file to extract the Installation ISO pfSense-LiveCD-2.2.3-RELEASE-amd64-20150623-1637.iso Attach the ISO file as a DVD Drive to newly created Hyper-V Virtual Machine http://vaggeliskappas.com/wp-content/uploads/2015/07/pfSense02.png Start the installation of pfSense http://vaggeliskappas.com/wp-content/uploads/2015/07/pfSense03.png After successful installation of pfSense, enable SSH http://vaggeliskappas.com/wp-content/uploads/2015/07/pfSense04.png Install Python 2.7 and required modules [2.2.3-RELEASE][[email protected]]/: pkg install python27 py27-asn1 Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Checking integrity... done (0 conflicting) The following 3 package(s) will be affected (of 0 checked): New packages to be INSTALLED: python27: 2.7.10 py27-asn1: 0.1.7,1 py27-setuptools27: 17.0 The process will require 67 MiB more space. Proceed with this action? [y/N]: y [1/3] Installing python27-2.7.10... [1/3] Extracting python27-2.7.10: 100% [2/3] Installing py27-setuptools27-17.0... [2/3] Extracting py27-setuptools27-17.0: 100% [3/3] Installing py27-asn1-0.1.7,1... [3/3] Extracting py27-asn1-0.1.7,1: 100% Message for python27-2.7.10: ===================================================================== Note that some standard Python modules are provided as separate ports as they require additional dependencies. They are available as: bsddb databases/py-bsddb gdbm databases/py-gdbm sqlite3 databases/py-sqlite3 tkinter x11-toolkits/py-tkinter ===================================================================== [2.2.3-RELEASE][[email protected]]/: You should symlink the new python 2.7 binary [2.2.3-RELEASE][[email protected]]/: ln -s /usr/local/bin/python2.7 /usr/bin/python Install sudo Typically on Azure, root account is disabled and we using uprovileged user to login. An unprivileged user should utilize sudo to run commands with elevated privileges. [2.2.3-RELEASE][[email protected]]/: pkg install sudo Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. The following 1 package(s) will be affected (of 0 checked): New packages to be INSTALLED: sudo: 1.8.14 The process will require 3 MiB more space. 796 KiB to be downloaded. Proceed with this action? [y/N]: y Fetching sudo-1.8.14.txz: 100% 796 KiB 815.0kB/s 00:01 Checking integrity... done (0 conflicting) [1/1] Installing sudo-1.8.14... [1/1] Extracting sudo-1.8.14: 100% [2.2.3-RELEASE][[email protected]]/: Install the Azure Linux Agent GitHub is the repository where you can find the latest version of Azure Linux Agent https://github.com/Azure/WALinuxAgent Version 2.0.10 or later is required for FreeBSD. Branch 2.0 is typically very stable and as of July 2015 the latest version is 2.0.14. [2.2.3-RELEASE][[email protected]]/: wget https://raw.githubusercontent.com/Azure/WALinuxAgent/2.0/waagent --2015-07-23 13:25:16-- https://raw.githubusercontent.com/Azure/WALinuxAgent/2.0/waagent Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.31.17.133 Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.31.17.133|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 245087 (239K) [text/plain] Saving to: 'waagent' waagent 100%[======================================================>] 239.34K 624KB/s in 0.4s 2015-07-23 13:25:17 (624 KB/s) - 'waagent' saved [245087/245087] [2.2.3-RELEASE][[email protected]]/: mv ./waagent /usr/sbin/ [2.2.3-RELEASE][[email protected]]/: chmod 755 /usr/sbin/waagent [2.2.3-RELEASE][[email protected]]/: /usr/sbin/wa [2.2.3-RELEASE][[email protected]]/: /usr/sbin/waagent -install [2.2.3-RELEASE][[email protected]]/: Set IP Addresses Configure WAN (hn0) Interface as DHCP client. Assign Static IP Address, 172.16.2.10, to LAN (hn1) Interface http://vaggeliskappas.com/wp-content/uploads/2015/07/pfSense05.png Shutdown The pfSense Virtual Machine Now the pfSense Virtual Machine is ready for running in Microsoft Azure. Upload the pfSense-2.3.3 VHD to Azure Using the following PowerShell commands, first we upload the pfSense VHD to Microsoft Azure Storage Account and then we create a custom image: # Variables Section $DestFile = "https://pfsa.blob.core.windows.net/vhds/pfSense-2.2.3-amd64.vhd" $SourceFile = "C:\Hyper-V\pfSense\Virtual Hard Disks\pfSense-2-2-3.vhd" # VHD Upload Add-AzureVhd -Destination $DestFile -LocalFilePath $SourceFile # Create an Image Add-AzureVMImage -ImageName "pfSense-2.2.3" -MediaLocation $DestFile -OS Linux Note that we are using OS type Linux instead of FreeBSD as it is not currently supported. Create a Multi-NIC Virtual Machine The custom image that we created previously, can be used in order to create a pfSense Virtual Machine with two Virtual Network Interfaces (vNIC), in Microsoft Azure. More details about creating a Virtual Machine with Multiple vNICs in Microsoft Azure, you can find in a previous post here: Create a Virtual Machine with Multiple NICs in Azure IaaS A pfSense Virtual Machine with two vNICs will be created by running the following PowerShell commands: $location = "West Europe" $serviceName = "pfsvc" $vnet = "pf-VNET" $subscriptionName = 'My MSDN Subscription' $storageAccount = 'pfsa' $adminUser = "adminuser" $pwd = "*********" $imageName = "pfSense-2.2.3" $MultiVM = New-AzureVMConfig -ImageName $ImageName ` -Name "pfSense-FW01" -InstanceSize ExtraLarge | Add-AzureProvisioningConfig -Linux -LinuxUser $adminUser ` -Password $pwd | Set-AzureSubnet -SubnetNames "Front-End" | Set-AzureStaticVNetIP -IPAddress "172.16.1.10" | Add-AzureNetworkInterfaceConfig -Name "LAN NIC" ` -SubnetName "LAN-Subnet" -StaticVNetIPAddress 172.16.2.10 New-AzureVM -ServiceName $serviceName ` -Location $location ` -VNetName $vnet ` -VMs $MultiVM Setup User Defined Routes With user defined routes, we have complete control over the traffic flow in our virtual network. Virtual network by default provides system routes for traffic flow between virtual machines. Now, we can customize the routing table by defining routes and that is allowing us to direct traffic through pfSense Virtual Machine that we have just created. Routes can be defined inside a routing table and applied to subnets. Every VM within a subnet automatically inherits the routes from the routing table. The following PowerShell commands, allowing us to: Create the routing tables Create routes in the routing tables Apply routing tables to subnets Enable IP Forwarding on pfSense’s vNICs # # Variables Section # $Location="West Europe" $VNetName="pf-VNET" $FrontendName="FE-Subnet" $LANName="LAN-Subnet" $ServiceName = "pfsvc" $VM = Get-AzureVM -Name "pfSense-FW01" -ServiceName $serviceName # Set the route table of the Frontend network: # $FrontRT = New-AzureRouteTable -Name $FrontendName ` -Location $Location -Label "FE-RT" Set-AzureRoute -RouteTable $FrontRT -RouteName "DMZ-Route" ` -AddressPrefix "172.16.2.0/24" -NextHopType "VirtualAppliance" ` -NextHopIpAddress "172.16.1.10" Set-AzureSubnetRouteTable -VirtualNetworkName $VNetName ` -SubnetName $FrontendName -RouteTableName $FrontendName # Set the route table of the LAN network: # $LANRT = New-AzureRouteTable -Name $LANName ` -Location $Location -Label "LAN-RT" Set-AzureRoute -RouteTable $LANRT -RouteName "FE-Route" ` -AddressPrefix 172.16.1.0/24 -NextHopType VirtualAppliance ` -NextHopIpAddress 172.16.2.10 Set-AzureRoute -RouteTable $LANRT -RouteName default -AddressPrefix 0.0.0.0/0 ` -NextHopType VirtualAppliance -NextHopIpAddress 172.16.2.10 Set-AzureSubnetRouteTable -VirtualNetworkName $VNetName -SubnetName $LANName ` -RouteTableName $LANName # Enable IP Forwarding on the main NIC and secondary NICs: # Set-AzureIPForwarding -ServiceName $ServiceName -VM $VM -Enable Set-AzureIPForwarding -ServiceName $ServiceName -VM $VM ` -NetworkInterfaceName "LAN NIC" -Enable The pfSense Virtual Machines must be able to receive incoming traffic that is not addressed to itself and this is the reason to enable IP forwarding. The post Running pfSense as an Azure IaaS Virtual Machine appeared first on Vaggelis Kappas.

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.

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.

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.

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.

Με μεγάλη χαρά την πρώτη Οκτωβρίου έλαβα ένα 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.

Αυτό που ήταν γνωστό μέχρι τώρα και τονιζόταν ιδιαιτέρως, ήταν να μην αποδίδεται για οποιοδήποτε λόγο 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.