Jump to content

Search the Community

Showing results for tags '{"tags":""}'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • autoexec.gr
  • Events
  • Γενικά

Forums

  • Γενικά
    • Τα πρωτοσέλιδα
    • Café
    • Λοιπά Θέματα
    • Ειδήσεις & Εκδηλώσεις
  • Προϊόντα
    • Εργαλεία και συμβουλές
    • Microsoft Office
    • Windows
    • Windows Server
    • Microsoft SQL Server
    • Exchange Server
    • SharePoint Server
    • Microsoft Hyper-V
    • Microsoft Azure
    • PowerShell
  • Τεχνολογία
    • Cloud
    • Virtualization
    • Management & Automation
  • Εκπαίδευση & Πιστοποίηση
    • Εκπαίδευση
    • Πιστοποίηση
  • Αγγελίες
    • Προσφορά Εργασίας
    • Αγοραπωλησίες
  • Archives
    • Γενικά
    • Εργαλεία και συμβουλές
    • Hardware
    • OS
    • Servers
    • Netwok & Security
    • Magazino

Blogs

  • Το προσωπικό σου blog
  • Bits & Bytes
  • Το Ελληνικό Exchange Blog
  • Ioannis Alexopoulos -- IT Blog
  • Εξομολογήσεις ενός διαχειριστή
  • Για την αντι-γραφή
  • spanougakis.com
  • Project Management: Art or Science? Profession or Competence?
  • BlackTrack
  • Hyper-Vangelis
  • Frees Point
  • Klag Rulez
  • Heimaros
  • Info Overflow
  • The dark side
  • Greek Active Directory Blog
  • The Greek Windows PKI blog
  • Greek Geek Girls "3G"
  • Tips, Tricks and Recipes for IT Pros
  • There is nothing like 127.0.0.1
  • kpsalida's Blog
  • απλά...το βλογ μου
  • Θέλω να γίνω τσομπάνης!
  • Holy IT
  • Admin
  • Catastrophic Failure
  • Rocking with Knowledge of SQL Server
  • Apple Macintosh in the Enteprise
  • Firewall In A Nutshell
  • The Infrastructurer
  • Smart Office
  • Το άδειο σεντούκι
  • iThalis
  • Παιδιά! Έχουμε mail ?
  • SBS & όχι μόνο , Ioannis Zontos
  • Paradigm Shift
  • Αη-Τι (ο άγιος Τι)
  • The TroubleShooter
  • George Markou's Blog
  • fmarkos' Blog
  • dead:beef::1
  • Vaggelis' Blog
  • Apostolidis Cloud Corner
  • Who Is General Dentist?

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests


Occupation

Found 22 results

  1. Intro In this blog post I will describe a way to implement an architecture that includes a private Azure Kubernetes Service (AKS) Cluster by using Bicep, a declarative language for describing and deploying Azure resources. According to project’s page on GitHub, Bicep is a Domain Specific Language (DSL) for deploying Azure resources declaratively and It aims to drastically simplify the authoring experience with a cleaner syntax, improved type safety, and better support for modularity and code re-use. The control plane or API server, in a fully private AKS cluster, has internal IP address and it communicates with the node pools through the private network, by leveraging the technology of Azure Private Link service. Furthermore, there is no need for the worker nodes to have a public IP assigned to a standard loadbalancer for egress the traffic as we are able to redirect the egress path through a Network Virtual Appliance or Azure Firewall. In a nutshell, a fully private AKS cluster does not expose or use any public IP. References The initial idea to create a Bicep script that deploys an architecture like the one mentioned in the architectural diagram section, was taken from the following articles: Baseline architecture for an Azure Kubernetes Service (AKS) cluster Fully private AKS clusters — without any public ips — finally! Create a “Fully private” AKS infrastructure with Terraform Architectural Diagram Bicep script The sources can be found at the following GitHub repository https://github.com/vakappas/private-aks-bicep The main Bicep script that deploys the architecture that is shown in the diagram, follows the modular approach and it has ‘subscription’ as its target scope. // set the target scope to subscription targetScope = 'subscription' / Create the hub vnet with all its components module hubvnet './modules/hub-default.bicep' = { name: 'hub-vnet' scope: resourceGroup(hubrg.name) params: { location: location hubVnetName: hubvnetName hubFwName: 'hub-fw' tags: tags } } there is a folder called ‘modules’ that contains the smaller parts of the whole implementation such as: The hub virtual network with all its components like the Azure Firewall and Azure Bastion The Virtual Network for the AKS cluster The Virtual Network for the Development Virtual Machines (agents) The VNET peering and route tables The private AKS cluster The AKS’s private DNS zone links to hub and dev Virtual Networks The dev VM which is an Ubuntu with Docker extension Running the script First you have to install the Bicep executable by following this guide: Setup your Bicep development environment Then, you will need to install either the Az CLI (2.20.0+) or the PowerShell Az module (v5.6.0+) that have Bicep support built-in. After that, you will need to run the following commands in an Azure CLI or PowerShell console: // Login to your Azure account az login // clone the repository git https://github.com/vakappas/private-aks-bicep.git // Start the deployment az deployment sub create -f ./private-aks.bicep -l northeurope As you see, you can use the standard deployment commands with your *.bicep files and the tooling will transpile the code and send it to ARM on your behalf.
  2. The greatest, community driven, technical event in Greece for IT Professionals and Developers is back! It’s been long time since the last ITPRO|DEV Connections event took place. There are a few reasons for that, but this does not matter anymore as we proudly bring it back to life and this time in virtual form! This event is community driven, and this year the number of the communities that take part are bigger than ever before. This signifies great momentum and deep commitment from the community members to help and support other community members. More than 100 speakers with real-world experiences and different backgrounds, leaving in different parts of the world, as now we have grown outside Greek borders, are getting together and sharing their knowledge with all the members of 15 technical communities that are embracing the ITPRO|DEV Connections 2020! The event’s tracks It will be 2 full days with parallel tracks running from ~10am to ~6pm (local time, that is GMT+2) and it will cover the following categories (in alphabetical order): AI & ML Data & Analytics Development DevOps Infrastructure Learning & Certification Modern Workspace Networks & Security Project Management All sessions are 45 minute long. The event is FREE, but you have to register here: The event’s details We have created the event on a platform that will have all the amenities of a normal conference, like sponsor booths, networking groups for 1-to-1 messaging and video calls, session evaluations, and of course a way to build your own personal schedule for your favorite sessions! The event comes with a very handy mobile app that you get to build your schedule and give session feedback and more. So make sure that you download the app and configure it with the 4-digit code that corresponds to our event. All this information is in the registration confirmation email! Also, this year is going to be delivered in 2 languages, so make sure you check the session tags for the tag “Lang: EL” or “Lang: EN” in a blue-ish color. Since we are in the tags area, there are mainly 4 different colors for tags: Dark blue: Session track Magenta: Session tags Light green: Session level Light blue: Session language I’m speaking! Apart from being in the organizing team, I have also a session, where I will talk about how the cloud is changing the way infrastructure is designed, and how you can build a highly available and scalable security perimeter by using Cisco Firepower Threat Defense virtual appliances. The session is called “Cisco NGFWv scalable design in Azure” and is on Saturday, 12th at 1 pm (GMT+2). The session is demo heavy as it is inspired by real customer project! Looking forward to welcome you if it happens to drop by. Call for action! What are you waiting for? Register here https://www.itprodevconnections.gr build your agenda and join us on 12-13 of December. Don’t forget to use the official hashtag of the event in any of your posts which is #itprodevgreece
  3. As you already know Exchange Server 2016 will be entering Extended Supporton October 14th 2020.. During that period it will receive only Critical and will be no further release of CUs, with the last planned CU to be released in December 2020. One of the many concerns regarding that transition is that at the moment there is no free Exchange Server 2019 license for just managing the exchange attributes on hybrid deployments as there is for Exchange 2016. According to the Product Group that specific license for the Exchange Server 2019 will be release after 14th October. Also as a heads-up the product group is working on a solution that will remove the need of those on-premise “management attributes| only servers. Microsoft encourages Exchange Server 2016 customers to adopt CU19 as soon as possible to ensure uninterrupted delivery of any future security related fixes. After December 15, 2020, only CU19 or its successors will receive critical updates. During the Extended Support phase, only the latest CU is eligible to receive critical updates once the standard 3 month transition period of the prior CU has lapsed. Critical updates will continue to be made available via Windows Update and the Microsoft Download Center. Additional lifecycle information for all Microsoft products is available on docs.microsoft.com. These are great news since is the first time that a working plan for the retirement of those on-premise server serving only for management is announced.
  4. This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues Cumulative Update 6 for Microsoft Exchange Server 2019 was released on June 16, 2020. This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues. These fixes will also be included in later cumulative updates for Exchange Server 2019. This update also includes new daylight saving time (DST) updates for Exchange Server 2019. For more information about DST, see Daylight Saving Time Help and Support Center. Known issues in this cumulative update In multidomain Active Directory forests in which Exchange is installed or has been prepared previously by using the /PrepareDomain option in Setup, this action must be completed after the /PrepareAD command for this cumulative update has been completed and the changes are replicated to all domains. Setup will try to run the /PrepareAD command during the first server installation. Installation will finish only if the user who initiated Setup has the appropriate permissions. Notes If you are upgrading from Cumulative Update 2 for Exchange Server 2019 or a later cumulative update for Exchange Server 2019 to Cumulative Update 6 for Exchange Server 2019, there’s no need to run the /PrepareAD or /PrepareDomain. No additional actions (prepareAD, prepareDomain, or assigning permissions) are required. If you have ever skipped a Cumulative Update (for example, you are upgrading from an earlier version before Cumulative Update 2 for Exchange Server 2019), or this is a first Exchange Server installation in the AD, then this Known Issue section should be taken care of. About the /PrepareDomain operation in multidomain: The /PrepareDomain operation automatically runs in the Active Directory domain in which the /PrepareAD commandis run. However, it may be unable to update other domains in the forest. Therefore, a domain administrator should run the /PrepareDomain in other domains in the forest. About the permission question: As the /PrepareAD is triggered in Setup, if the user who initiates Setup isn’t a member of Schema Admins and Enterprise Admins, the readiness check will fail and you receive the following error messages. To avoid the errors, either the user should join Schema Admins and Enterprise Admins groups or another user in Schema Admins and Enterprise Admins groups manually runs the /PrepareAD for this Cumulative Update first. Then, the Exchange admin user can start Setup. Autodiscover Event ID 1 occurs after you install Cumulative Update 3 for Exchange Server 2019. For more information, see KB 4532190. Issues that this cumulative update fixes This cumulative update also fixes the issues that are described in the following Microsoft Knowledge Base articles: 4559441 Foreign language characters set in RejectMessageReasonText of a transport rule aren’t shown correctly in Exchange Server 2019 4547707 Enable piping for Restore-RecoverableItems in Exchange Server 2019 4549689 HMA EvoSTS certificate rollover causes authentication prompts due to stalled key on worker process spawn (warmup phase) in Exchange Server 2019 4559446 Changes to Outlook on the web blocked file extensions and MIME types in Exchange Server 2019 4559440 Export to a PST for an eDiscovery search fails Exchange Server 2019 4559439 EAS creates failure report if a message with unknown recipients is in Drafts in Exchange Server 2019 4559442 2080 Events caused by empty values in HKLM\SYSTEM\CurrentControlSet\Services\MSExchange ADAccess\Instance0 in Exchange Server 2019 4559438 Edge Transport server hangs in Exchange Server 2019 4559443 Managed Folder Assistant fails with Event ID 9004 NotInBagPropertyErrorException in Exchange Server 2019 4559437 PR_RECIPIENT_ENTRYID is computed if no email address or type in Exchange Server 2019 4559444 Conversion from HTML to RTF removes non-breaking space in Exchange Server 2019 4559436 Attachments with properties (like Azure Information Protection labels) not always matching in Exchange Server 2019 4559435 Introduce an OrganizationConfig flag to enable or disable recipient read session in Exchange Server 2019
  5. This cumulative update includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues. Known issues in this cumulative update In multidomain Active Directory forests in which Exchange is installed or has been prepared previously by using the /PrepareDomain option in Setup, this action must be completed after the /PrepareAD command for this cumulative update has been completed and the changes are replicated to all domains. Setup will try to run the /PrepareAD command during the first server installation. Installation will finish only if the user who initiated Setup has the appropriate permissions. Notes If you are upgrading from Cumulative Update 13 for Exchange Server 2016 or a later cumulative update for Exchange Server 2016 to Cumulative Update 17 for Exchange Server 2016, then there’s no need to run the /PrepareAD or /PrepareDomain. No additional actions (prepareAD, prepareDomain, or assigning permissions) are required. If you have ever skipped a Cumulative Update (for example, you are upgrading from an earlier version before Cumulative Update 13 for Exchange Server 2016), or this is a first Exchange Server installation in the AD, then this Known Issue section should be taken care of. About the /PrepareDomain operation in multidomain: The /PrepareDomain operation automatically runs in the Active Directory domain in which the /PrepareAD command is run. However, it may be unable to update other domains in the forest. Therefore, a domain administrator should run the /PrepareDomain in other domains in the forest. About the permission question: As the /PrepareAD is triggered in Setup, if the user who initiates Setup isn’t a member of Schema Admins and Enterprise Admins, the readiness check will fail and you receive the following error messages.To avoid the errors, either the user should join Schema Admins and Enterprise Admins groups or another user in Schema Admins and Enterprise Admins groups manually runs the /PrepareAD for this Cumulative Update first. Then the Exchange admin user can start Setup. Autodiscover Event ID 1 occurs after you install Cumulative Update 14 for Exchange Server 2016. For more information, see KB 4532190. Issues that this cumulative update fixes This cumulative update fixes the issues that are described in the following Microsoft Knowledge Base articles: 4559444 Conversion from HTML to RTF removes non-breaking space in Exchange Server 2016 4559435 Introduce an OrganizationConfig flag to enable or disable recipient read session in Exchange Server 2016 4547707 Enable piping for Restore-RecoverableItems in Exchange Server 2019 and 2016 4559436 Attachments with properties (like Azure Information Protection labels) don’t always match in Exchange Server 2016 4559437 PR_RECIPIENT_ENTRYID is computed if no email address or type in Exchange Server 2016 4559438 Edge Transport server hangs in Exchange Server 2016 4559439 EAS creates failure report if a message with unknown recipients is in Drafts in Exchange Server 2016 4559440 Export to a PST for an eDiscovery search fails in Exchange Server 2016 4559441 Foreign language characters set in RejectMessageReasonText of a transport rule aren’t shown correctly in Exchange Server 2016 4559442 2080 Events caused by empty values in HKLM\SYSTEM\CurrentControlSet\Services\MSExchange ADAccess\Instance0 in Exchange Server 2016 4549689 HMA EvoSTS certificate rollover causes authentication prompts due to stalled key on worker process spawn (warmup phase) in Exchange Server 2016 4559443 Managed Folder Assistant fails with Event ID 9004 NotInBagPropertyErrorException in Exchange Server 2016 4559446 Changes to Outlook on the web blocked file extensions and MIME types in Exchange Server 2016
  6. This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues Κnown issues in this cumulative update In multidomain Active Directory forests in which Exchange is installed or has been prepared previously by using the /PrepareDomain option in Setup, this action must be completed after the /PrepareAD command for this cumulative update has been completed and the changes are replicated to all domains. Setup will try to run the /PrepareAD command during the first server installation. Installation will finish only if the user who initiated Setup has the appropriate permissions. Notes If you are upgrading from Cumulative Update 2 for Exchange Server 2019 or a later cumulative update for Exchange Server 2019 to Cumulative Update 5 for Exchange Server 2019, there’s no need to run the /PrepareAD or /PrepareDomain. No additional actions (prepareAD, prepareDomain, or assigning permissions) are required. If you have ever skipped a Cumulative Update (for example, you are upgrading from an earlier version before Cumulative Update 2 for Exchange Server 2019), or this is a first Exchange Server installation in the AD, then this Known Issue section should be taken care of. About the /PrepareDomain operation in multidomain: The /PrepareDomain operation automatically runs in the Active Directory domain in which the /PrepareAD commandis run. However, it may be unable to update other domains in the forest. Therefore, a domain administrator should run the /PrepareDomain in other domains in the forest. About the permission question: As the /PrepareAD is triggered in Setup, if the user who initiates Setup isn’t a member of Schema Admins and Enterprise Admins, the readiness check will fail and you receive the following error messages. To avoid the errors, either the user should join Schema Admins and Enterprise Admins groups or another user in Schema Admins and Enterprise Admins groups manually runs the /PrepareAD for this Cumulative Update first. Then, the Exchange admin user can start Setup. Autodiscover Event ID 1 occurs after you install Cumulative Update 3 for Exchange Server 2019. For more information, see KB 4532190. Issues that this cumulative update fixes This cumulative update also fixes the issues that are described in the following Microsoft Knowledge Base articles: 4552472 Exchange Server 2019 Sizing Calculator version 10.4 is available 4536552 Export-ModernPublicFolderStatistics.ps1 is not working in Exchange Server 2019 4538303 Exchange 2019 Setup Prerequisite Check fails for .NET 4.8 Framework in CU4 on Windows builds 1909 and 1903 4547705 Authentication loop between msft.sts.microsoft.com/adfs and OWA in Exchange Server 2019 4547706 Birthday isn’t correctly synced to iOS native mail app in Exchange Server 2019 4547708 Elevation of privileges possible when Active Directory permissions role is granted in Exchange Server 2019 4547709 InternetWebProxyBypassList is ignored by Mailbox Replication service in Exchange Server 2019 4547710 New-MailboxSearch with In-Place Hold enabled replaces all values in msExchUserHoldPolicies if adding a value in Exchange Server 2019 4547711 Public folder permissions aren’t applied from Outlook in Exchange Server 2019 hybrid environment 4547712 Outlook on the web (OWA) exposes junk operations even if disabled via OwaMailboxPolicy in Exchange Server 2019 4547713 IsOnlineMeeting is always false for Teams-only meetings in Exchange Server 2019 4547714 Can’t add remote shared mailbox using ECP into distribution group in Exchange Server 2019 hybrid environment 4547715 New created search folder retention policy is changed in Exchange Server 2019 4547719 MCDB status is “Offline” and SSDs are not formatted in Exchange Server 2019 4547720 Partial word searches not working for mailboxes in Outlook online mode in Exchange Server 2019 4547721 Exchange Sizing Calculator still supports mail.que database over 2 TB in Exchange Server 2019 4547722 Can’t go from Office 365 to Enterprise in Exchange Server 2019 Exchange admin center (EAC) if Chrome SameSite Cookie is enabled 4547723 Can’t sign in to Office 365 if configuring hybrid with Chrome SameSite Cookie enabled in Exchange Server 2019 4536987 Description of the security update for Microsoft Exchange Server 2019: February 11, 2020 4540123 Description of the security update for Microsoft Exchange Server 2019: March 10, 2020
  7. This cumulative update includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues Known issues in this cumulative update In multidomain Active Directory forests in which Exchange is installed or has been prepared previously by using the /PrepareDomain option in Setup, this action must be completed after the /PrepareAD command for this cumulative update has been completed and the changes are replicated to all domains. Setup will try to run the /PrepareAD command during the first server installation. Installation will finish only if the user who initiated Setup has the appropriate permissions. Notes If you are upgrading from Cumulative Update 13 for Exchange Server 2016 or a later cumulative update for Exchange Server 2016 to Cumulative Update 16 for Exchange Server 2016, then there’s no need to run the /PrepareAD or /PrepareDomain. No additional actions (prepareAD, prepareDomain, or assigning permissions) are required. If you have ever skipped a Cumulative Update (for example, you are upgrading from an earlier version before Cumulative Update 13 for Exchange Server 2016), or this is a first Exchange Server installation in the AD, then this Known Issue section should be taken care of. About the /PrepareDomain operation in multidomain: The /PrepareDomain operation automatically runs in the Active Directory domain in which the /PrepareAD command is run. However, it may be unable to update other domains in the forest. Therefore, a domain administrator should run the /PrepareDomain in other domains in the forest. About the permission question: As the /PrepareAD is triggered in Setup, if the user who initiates Setup isn’t a member of Schema Admins and Enterprise Admins, the readiness check will fail and you receive the following error messages.To avoid the errors, either the user should join Schema Admins and Enterprise Admins groups or another user in Schema Admins and Enterprise Admins groups manually runs the /PrepareAD for this Cumulative Update first. Then the Exchange admin user can start Setup. Autodiscover Event ID 1 occurs after you install Cumulative Update 14 for Exchange Server 2016. For more information, see KB 4532190. Issues that this cumulative update fixes This cumulative update fixes the issues that are described in the following Microsoft Knowledge Base articles: 4547705 Authentication loop between msft.sts.microsoft.com/adfs and OWA in Exchange Server 2016 4547706 Birthday isn’t correctly synced to iOS native mail app in Exchange Server 2016 4547708 Elevation of privileges possible when Active Directory permissions role is granted in Exchange Server 2016 4547709 InternetWebProxyBypassList is ignored by Mailbox Replication service in Exchange Server 2016 4547710 New-MailboxSearch with In-Place Hold enabled replaces all values in msExchUserHoldPolicies if adding a value in Exchange Server 2016 4547711 Public folder permissions aren’t applied from Outlook in Exchange Server 2016 hybrid environment 4547712 Outlook on the web (OWA) exposes junk operations even if disabled via OwaMailboxPolicy in Exchange Server 2016 4547713 IsOnlineMeeting is always false for Teams-only meetings in Exchange Server 2016 4547714 Can’t add remote shared mailbox by using ECP into distribution group in Exchange Server 2016 hybrid environment 4547715 New created search folder retention policy is changed in Exchange Server 2016 4547722 Can’t go from Office 365 to Enterprise in Exchange Server 2016 Exchange admin center (EAC) if Chrome SameSite Cookie is enabled 4547723 Can’t sign in to Office 365 if configuring hybrid with Chrome SameSite Cookie enabled in Exchange Server 2016 4547716 Event ID 1325 and Test-ExchangeSearch crashes application pool with NullReferenceException in Exchange Server 2016 4536987 Description of the security update for Microsoft Exchange Server 2016: February 11, 2020 4540123 Description of the security update for Microsoft Exchange Server 2016: March 10, 2020
  8. This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues. Known issues in this cumulative update In multidomain Active Directory forests in which Exchange is installed or has been prepared previously by using the /PrepareDomain option in Setup, this action must be completed after the /PrepareAD command for this cumulative update has been completed and the changes are replicated to all domains. Setup will try to run the /PrepareAD command during the first server installation. Installation will finish only if the user who initiated Setup has the appropriate permissions. Notes:If you are upgrading from Cumulative Update 2 for Exchange Server 2019 or a later cumulative update for Exchange Server 2019 to Cumulative Update 4 for Exchange Server 2019, then there’s no need to run the /PrepareAD or /PrepareDomain. No additional actions (prepareAD, prepareDomain, or assigning permissions) are required. If you has ever skipped a Cumulative Update (for example, you are upgrading from an earlier version before Cumulative Update 2 for Exchange Server 2019), or this is a first Exchange Server installation in the AD, then this Known Issue section should be taken care of. a. About the /PrepareDomain operation in multidomain: The /PrepareDomain operation automatically runs in the Active Directory domain in which the /PrepareAD commandis run. However, it may be unable to update other domains in the forest. Therefore, a domain administrator should run the /PrepareDomain in other domains in the forest. b. About the permission question: As the /PrepareAD is triggered in Setup, if the user who initiates Setup isn’t a member of Schema Admins and Enterprise Admins, the readiness check will fail and you receive the following error messages: To avoid the error messages, either the user should join Schema Admins and Enterprise Admins groups, or another user in Schema Admins and Enterprise Admins groups manually runs the /PrepareAD for this Cumulative Update first. Then the Exchange admin user can start Setup. Autodiscover Event ID 1 after installing Cumulative Update 3 for Exchange Server 2019. For more information, see KB 4532190. The Export-ModernPublicFolderStatistics.ps1 script doesn’t work in Microsoft Exchange Server 2019. For more information, see KB 4536552. Issues that this cumulative update fixes This cumulative update also fixes the issues that are described in the following Microsoft Knowledge Base articles: 4528696 Exchange PowerShell cmdlets take longer time to run in Exchange Server 2019 4528695 Event ID 4009 when using SubjectOrBodyMatchesPatterns on Edge server in Exchange Server 2019 4528694 Can’t open .ics file in Outlook on the web in Exchange Server 2019 4528692 “A parameter was specified that isn’t valid” error when creating transport rule in Exchange Server 2019 4523519 Set-SendConnector doesn’t work for Exchange Server in hybrid scenarios with Edge Server installed 4528688 Only one recipient shows when saving draft by using Exchange ActiveSync version 16.0 in Exchange Server 2019 4528693 Get-CalendarDiagnosticLog is proxied for queries within the same forest in Exchange Server 2019 4528687 NotificationClient logs aren’t purged and consume lots of disk in Exchange Server 2019 4528689 Outlook on the web shows MailTip when recipients equal the large audience size in Exchange Server 2019 4528690 Can’t move or delete folder in Outlook online mode if the destination has a folder with the same name in Exchange Server 2019 4532744 System.ArgumentNullException when you use Set-user to assign block legacy auth policy in Exchange Server 2019 4532747 Address list separation not working for a user without a mailbox in Exchange Server 2019 4523171 Description of the security update for Microsoft Exchange Server 2019, 2016, and 2013: November 12, 2019
  9. This cumulative update includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues Known issues in this cumulative update In multidomain Active Directory forests in which Exchange is installed or has been prepared previously by using the /PrepareDomain option in Setup, this action must be completed after the /PrepareAD command for this cumulative update has been completed and the changes are replicated to all domains. Setup will try to run the /PrepareAD command during the first server installation. Installation will finish only if the user who initiated Setup has the appropriate permissions. Notes: If you are upgrading from Cumulative Update 13 for Exchange Server 2016 to Cumulative Update 14 for Exchange Server 2016, then there’s no need to run the /PrepareAD or /PrepareDomain. No additional actions (prepareAD, prepareDomain, or assigning permissions) are required. If you has ever skipped a Cumulative Update (for example, you are upgrading from an earlier version before Cumulative Update 13 for Exchange Server 2016), or this is a first Exchange Server installation in the AD, then this Known Issue section should be taken care of. a. About the /PrepareDomain operation in multidomain: The /PrepareDomain operation automatically runs in the Active Directory domain in which the /PrepareAD command is run. However, it may be unable to update other domains in the forest. Therefore, a domain administrator should run the /PrepareDomain in other domains in the forest. b. About the permission question: As the /PrepareAD is triggered in Setup, if the user who initiates Setup isn’t a member of Schema Admins and Enterprise Admins, the readiness check will fail and you receive the following error messages:To avoid the error messages, either the user should join Schema Admins and Enterprise Admins groups, or another user in Schema Admins and Enterprise Admins groups manually runs the /PrepareAD for this Cumulative Update first. Then the Exchange admin user can start Setup. The Set-SendConnector cmdlet does not work for Exchange Server 2016 in hybrid scenarios that have a Edge server installed. For more information, see KB 4523519. Autodiscover Event ID 1 after installing Cumulative Update 14 for Exchange Server 2016. For more information, see KB 4532190. Issues that this cumulative update fixes This cumulative update fixes the issues that are described in the following Microsoft Knowledge Base articles: 4515255 “X-InnerException: Microsoft.Mapi.MapiExceptionRpcServerTooBusy” error when you try to use a mailbox in Exchange Server 2016 4515254 Event 1009 frequently occurs in application logs for lagged database copies in Exchange Server 2016 4502159 Adding or removing mailbox permission in EAC doesn’t address the msExchDelegateListLink attribute in Exchange Server 2016 4515276 Room mailbox accepts a meeting as “Free” if a booking delegate is set in Exchange Server 2016 4515275 Enable Get/Restore-RecoverableItems to work with Purges folder in Exchange Server 2016 4515274 AutodiscoverV2 request returns REST API endpoint not AutoDiscoverV1 endpoint in Exchange Server 2016 4515269 SentToMemberOf shows every recipient type not distribution groups when creating transport rule in Exchange Server 2016 4515272 Message is blocked in “SMTP Delivery to Mailbox” queue if exchange server is added in groups of a child domain in Exchange Server 2016 4515271 Can’t convert a migrated remote user mailbox to shared in Exchange Server 2016 4515270 SubmissionQueueLengthMonitor shows “System.ArgumentException: Transition timeout…” in Exchange Server 2016 4515267 NDR occurs when you resend message from alternate journaling mailbox to journaling mailbox in Exchange Server 2016 4515265 Removing In-Place Hold doesn’t work for mailboxes in different domains in Exchange Server 2016 4515264 FindPeople request from Skype for Business on Mac fails with “Invalid Shape Specification” in Exchange Server 2016 4515263 Hide the “Validate-MailFlowThroughFrontDoor” command for Exchange Server 2016 4515262 Enable Remove-MobileDevice to delete mobile devices after migrating to Office 365 from Exchange Server 2016 4515261 Can’t copy eDiscovery search results for mailboxes with Exchange online archives in Office 365 in Exchange Server 2016 4515273 Mailbox auditing fails when you use SHA1Managed in Exchange Server 2016 4515266 Infinite loop in Recurrence.GetNumberOfYearsBetween() with the Japanese calendar in Exchange Server 2016 4520319 S/MIME signed reply draft behaves like the first message in conversation in Exchange Server 2016 4515832 Description of the security update for Microsoft Exchange Server 2019 and 2016: September 10, 2019
  10. This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues. Known issues in this cumulative update In multidomain Active Directory forests in which Exchange is installed or has been prepared previously by using the /PrepareDomain option in Setup, this action must be completed after the /PrepareAD command for this cumulative update has been completed and the changes are replicated to all domains. Setup will try to run the /PrepareAD command during the first server installation. Installation will finish only if the user who initiated Setup has the appropriate permissions. Notes:If you are upgrading from Cumulative Update 2 for Exchange Server 2019 to Cumulative Update 3 for Exchange Server 2019, then there’s no need to run the /PrepareAD or /PrepareDomain. No additional actions (prepareAD, prepareDomain, or assigning permissions) are required. If you has ever skipped a Cumulative Update (for example, you are upgrading from an earlier version before Cumulative Update 2 for Exchange Server 2019), or this is a first Exchange Server installation in the AD, then this Known Issue section should be taken care of. a. About the /PrepareDomain operation in multidomain: The /PrepareDomain operation automatically runs in the Active Directory domain in which the /PrepareAD commandis run. However, it may be unable to update other domains in the forest. Therefore, a domain administrator should run the /PrepareDomain in other domains in the forest. b. About the permission question: As the /PrepareAD is triggered in Setup, if the user who initiates Setup isn’t a member of Schema Admins and Enterprise Admins, the readiness check will fail and you receive the following error messages: To avoid the error messages, either the user should join Schema Admins and Enterprise Admins groups, or another user in Schema Admins and Enterprise Admins groups manually runs the /PrepareAD for this Cumulative Update first. Then the Exchange admin user can start Setup. The Set-SendConnector cmdlet does not work for Exchange Server 2019 in hybrid scenarios that have a Edge server installed. For more information, see KB 4523519. Autodiscover Event ID 1 after installing Cumulative Update 3 for Exchange Server 2019. For more information, see KB 4532190. Issues that this cumulative update fixes This cumulative update also fixes the issues that are described in the following Microsoft Knowledge Base articles: 4515257 Hash mismatch is reported for Exchange DLLs in the bin directory of Exchange Server 2019 4513500 Can’t sign in to OWA or EAC after you install Exchange Server 2019 CU2 with AD FS 4502159 Adding or removing mailbox permission in EAC doesn’t address the msExchDelegateListLink attribute in Exchange Server 2019 and 2016 4515276 Room mailbox accepts a meeting as “Free” if a booking delegate is set in Exchange Server 2019 and 2016 4515275 Enable Get/Restore-RecoverableItems to work with Purges folder in Exchange Server 2019 and 2016 4515274 AutodiscoverV2 request returns REST API endpoint not AutoDiscoverV1 endpoint in Exchange Server 2019 and 2016 4515269 SentToMemberOf shows every recipient type not distribution groups when you create transport rule in Exchange Server 2019 and 2016 4515272 Message is blocked in “SMTP Delivery to Mailbox” queue if exchange server is added in groups of a child domain in Exchange Server 2019 and 2016 4515271 Can’t convert a migrated remote user mailbox to shared in Exchange Server 2019 and 2016 4515270 SubmissionQueueLengthMonitor shows “System.ArgumentException: Transition timeout…” in Exchange Server 2019 and 2016 4515267 NDR occurs when you resend message from alternate journaling mailbox to journaling mailbox in Exchange Server 2019 and 2016 4515265 Removing In-Place Hold doesn’t work for mailboxes in different domains in Exchange Server 2019 and 2016 4515264 FindPeople request from Skype for Business on Mac fails with “Invalid Shape Specification” in Exchange Server 2019 and 2016 4515263 Hide the “Validate-MailFlowThroughFrontDoor” command for Exchange Server 2019 and 2016 4515262 Enable Remove-MobileDevice to delete mobile devices after migrating to Office 365 from Exchange Server 2019 and 2016 4515261 Can’t copy eDiscovery search results for mailboxes with Exchange online archives in Office 365 in Exchange Server 2019 and 2016 4515273 Mailbox auditing fails when using SHA1Managed in Exchange Server 2019 and 2016 4515266 Infinite loop in Recurrence.GetNumberOfYearsBetween() with the Japanese calendar in Exchange Server 2019 and 2016 4520319 S/MIME signed reply draft behaves like the first message in conversation in Exchange Server 2019 and 2016 4515832 Description of the security update for Microsoft Exchange Server 2019 and 2016: September 10, 2019
  11. This cumulative update includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues. Known issues The Set-SendConnector cmdlet does not work for Exchange Server 2013 in hybrid scenarios that have a Edge server installed. For more information, see KB 4523519. Issues that this cumulative update fixes This cumulative update fixes the issues that are described in the following Microsoft Knowledge Base articles: 4502131 “TLS negotiation failed with error UnknownCredentials” error after updating TLSCertificateName on Office 365 send connector in Exchange Server 2013 hybrid environment 4503028 Description of the security update for Microsoft Exchange Server 2013 and 2010: June 11, 2019
  12. This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues. Issues that this cumulative update fixes 4502134 Can’t get all the emails when searching mailbox by using an end date that’s different from today in Exchange Server 2019 4502135 Correct the error message that you receive when installing Exchange Server 2019 in an organization that has Exchange Server 2010 installed 4502154 Providing information to administrators when auto forward limit is reached in Exchange Server 2019 and 2016 4502155 “The primary SMTP address must be specified when referencing a mailbox” error when you use impersonation in Exchange Server 2019 and 2016 4502156 Audit logs aren’t updated when “-WhatIf” is used as $false in the command in Exchange Server 2019 and 2016 4502157 The Find command not returning the HasAttachments element in Exchange Server 2019 and 2016 4502158 SyncFolderItems contains duplicated ReadFlagChange items in Exchange Server 2019 and 2016 4502131 “TLS negotiation failed with error UnknownCredentials” error after you update TLSCertificateName on Office 365 send connector in Exchange Server 2019 hybrid environment 4502132 Can’t reply to old emails after migration even though old legacyExchangeDN is set to migrated mailbox in Exchange Server 2019 and 2016 4502136 The response of FETCH (BODYSTRUCTURE) command of IMAP violates RFC 3501 in Exchange Server 2019 and 2016 4502140 Can’t preview an eDiscovery search when there are multiple domains in Exchange Server 2019 and 2016 4502141 Appointment that’s created by responding to an email message doesn’t show in any Outlook calendar views in Exchange Server 2019 and Exchange Server 2016 4502133 Can’t use Outlook on the web to reply a partner email through mutual TLS in Exchange Server 2019 and 2016 4488396 Can’t search any results in manually added shared mailbox in Outlook in Exchange Server 2019 and 2016 4488078 Public folder contact lists don’t show contact’s profile picture in Outlook on the web in Exchange Server 2019 and 2016 4499503 Heavy organizational forms traffic because of materialized restriction when organization forms library has more than 500 items in Exchange Server 2019 and 2016 4503027 Description of the security update for Microsoft Exchange Server 2019 and 2016: June 11, 2019
  13. 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. Please note that if you are running New-NanoServerImage.ps1 on a non-English installation of Windows you should include –language en-us. If you don’t include this, the script will default to your local language–because there are currently no localized builds of Windows Server 2016 it will fail to find the appropriate packages. 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.
  14. 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.
  15. 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.
  16. 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][admin@pfSense.localdomain]/: 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][admin@pfSense.localdomain]/: You should symlink the new python 2.7 binary [2.2.3-RELEASE][admin@pfSense.localdomain]/: 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][admin@pfSense.localdomain]/: 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][admin@pfSense.localdomain]/: 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][admin@pfSense.localdomain]/: 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][admin@pfSense.localdomain]/: mv ./waagent /usr/sbin/ [2.2.3-RELEASE][admin@pfSense.localdomain]/: chmod 755 /usr/sbin/waagent [2.2.3-RELEASE][admin@pfSense.localdomain]/: /usr/sbin/wa [2.2.3-RELEASE][admin@pfSense.localdomain]/: /usr/sbin/waagent -install [2.2.3-RELEASE][admin@pfSense.localdomain]/: 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. Με μεγάλη χαρά την πρώτη Οκτωβρίου έλαβα ένα 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.
  22. Αυτό που ήταν γνωστό μέχρι τώρα και τονιζόταν ιδιαιτέρως, ήταν να μην αποδίδεται για οποιοδήποτε λόγο 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.
×
×
  • Create New...