Jump to content

Jordan_Tsafaridis

Members
 View Profile  See their activity

  • Posts

    106

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by Jordan_Tsafaridis

  1. Jordan_Tsafaridis
    Εχθές, η Microsoft ανακοίνωσε ότι θα τερματίσει την ανάπτυξη του Forefront TMG 2010. Βεβαίως η Microsoft θα συνεχίσει να παρέχει mainstream support για τον TMG μέχρι και την 14η Απριλίου του 2015, καθώς επλισης extended support μέχρι και την 14η Απριλίου 2020. Η υπηρεσία των The Forefront TMG 2010 Web Protection Services (WPS) θα τερματιστεί την 31η Δεκεμβρίου 2015. Ξεκινώντας την 1η Ιανουαρίου 2016 τα Web Protection Services (URL filtering, virus/malicious software scanning, and Network Inspection System) θα συνεχίσουν να λειτουργούν αλλά δεν θα παρέχουν πλέον updates.
     
    To end of life του Forefront TMG 2010 αποτελεί μέρος μιας σειράς σαρωτικών αλλαγών (part of sweeping changes) οι οποίες αφορούν όλη την σειρά των προϊόντων Forefront. Πέραν δε του τερματισμού της ανάπτυξης του Forefront TMG 2010, η Microsoft ανακοίνωσε επίσης ότι τερματίζεται η ανάπτυξη των Forefront Protection for Exchange (FPE), Forefront Protection for SharePoint (FPSP), Forefront Security for OCS (FSOCS), και Forefront Protection Server Management Console (FPSMC) αντίστοιχα.
     
    Κοιτώντας όμως μπροστά ο Forefront Unified Access Gateway (UAG) 2010 και ο Forefront Identify Manager (FIM) 2010 R2 τα δύο αυτά προϊόντα θα συνεχίσουν να αναπτύσσονται κανονικά, αν και οι πληροφορίες αναφέρουν ότι θα αλλάξει το Forefront brand name με κάτι άλλο.
  2. Jordan_Tsafaridis
    Σε έναν ForeFront Threat Management Gateway (TMG) 2010 firewall είναι δυνατόν να αντιμετωπίσουμε ένα Configuration Error alert όπως το παρακάτω :

    Η περιγραφή του συγκεκριμένου alert ορίζει τα εξής:
     
    “The routing table for the network adapter Internal includes IP address ranges that are not defined in the array-level network Internal, to which it is bound. As a result, packets arriving at this network adapter from the IP address ranges listed below or sent to these IP address ranges via this network adapter will be dropped as spoofed. To resolve this issue, add the missing IP address ranges to the array network.
    The following IP address ranges will be dropped as spoofed:
    External:172.16.2.0-172.16.3.255;

    Το alert είναι το αποτέλεσμα του Forefront TMG firewall routing table και του network definition το οποίο είναι εκτός συγχρονισμού (being out of sync) μεταξύ τους. Στο συγκεκριμένο παράδειγμα το routing table μοιάζει όπως το παρακάτω:
     
    Εντούτοις το Forefront TMG Internal network definition μοιάζει όπως το παρακάτω:

    Όπως διαπιστώνετε, ο Forefront TMG firewall είναι ρυθμισμένος με ένα Internal network IP address range το οποίο είναι το 172.16.1.0/24. Παρόλα αυτά το routing table περιλαμβάνει επιπλέον static routes τα οποία κάνουν τα δίκτυα 172.16.2.0/24 και 172.16.3.0/24 προσβάσιμα.
    Για να επιλύσουμε αυτό το θέμα επιλέγουμε (highlight) το Networking node στο navigation tree. Εν συνεχεία επιλέγουμε το Networks tab στο κέντρο του παραθύρου, και αμέσως μετά επιλέγουμε το δίκτυο το οποίο αντιστοιχεί στην δέσμη των IP address οι οποίες περιλαμβάνεται στο συγκεκριμένο alert. Στο παράδειγμά μας η δέσμη διευθύνσεων 172.16.2.0-172.16.3.255 επίσης ανήκει στο εσωτερικό δίκτυο. Κάνοντας δεξί κλικ στο εσωτερικό δίκτυο (Internal network) εν συνεχεία επιλέγουμε τα properties, και αμέσως μετά επιλέγουμε το Addresses tab, όπου εκεί αφαιρούμε όλα τα address ranges τα οποία προηγουμένως είχαν ρυθμιστεί. Το επόμενο βήμα, είναι να επιλέξουμε την επιλογή Add Adapter και εν συνεχεία επιλέγουμε το network adapter γι’αυτό το δίκτυο.

    Με την μέθοδο αυτή το IP address range για το δίκτυο αυτό δημιουργείτε χρησιμοποιώντας το routing table για το συγκεκριμένο network interface. Συνεπώς αυτή η μέθοδος αποτελεί την ενδεδειγμένη μέθοδο για τον καθορισμό IP address ranges για τα Forefront TMG networks. Ολοκληρώνοντας σώστε τις αλλαγές και κάνετε εφαρμογή (apply) του configuration.
    Για περισσότερες πληροφορίες σχετικά με την ρύθμιση (configuration) των network interfaces στον Forefront TMG 2010 firewall, σας προτρέπω να διαβάσετε τα εξαιρετικά άρθρα του Jason Jones τα οποία είναι σχετικά με το συγκεκριμένο θέμα:
     
    Recommended Network Adapter Configuration for Forefront TMG Standard Edition Servers
    Recommended Network Adapter Configuration for Forefront TMG Enterprise Edition Servers
     
  3. Jordan_Tsafaridis
    Αγαπητοί
    συνάδελφοι της κοινότητας στο τρίτο αυτό μέρος αυτής της σειράς άρθρων έφτασε
    πλέον η στιγμή να τροποποιήσουμε την ακολουθία εργασιών Hyper-V (task sequence), έτσι
    ώστε να είμαστε σε θέση να αναπτύξουμε (deploy) τους Hyper-V servers οι οποίοι
    θα χρησιμοποιηθούν με την σειρά τους για να φιλοξενήσουν (host) τις
    εικονικές μηχανές (virtual machines) στο δικό
    μας private cloud.

     

    Εισαγωγή
     

    Στο προηγούμενο άρθρο της συγκεκριμένης
    σειράς, σας παρουσίασα τον τρόπο με τον οποίο να εξαγάγουμε (extract) τα περιεχόμενα του Windows installation media με σκοπό την δημιουργία ενός deployment image. Εάν έχετε διαβάσει το συγκεκριμένο άρθρο,
    το ολοκλήρωσα δημιουργώντας δύο ακολουθίες εργασιών (task sequences). Η μια εκ των δύο ακολουθιών αφορούσε
    μια ανάπτυξη (deployment)
    γενικής χρήσης των Windows Server
    2008 R2,
    και η άλλη αφορούσε μια μηχανή Windows Server
    2008 R2
    η οποία τρέχει τον Hyper-V. Στο συγκεκριμένο σημείο οι δύο ακολουθίες
    εργασιών είναι πλήρως ταυτόσημες και πανομοιότυπες (completely identical), συνεπώς έφτασε η στιγμή κατά την οποία
    είμαστε σε θέση να ξεκινήσουμε την τροποποίηση (modifying) την ακολουθία εργασιών Hyper-V έτσι ώστε να μπορούμε να την
    χρησιμοποιήσουμε για την ανάπτυξη (deploy) των Hyper-V servers οι οποίοι πρόκειται να χρησιμοποιηθούν
    για να φιλοξενήσουν (host)
    τις εικονικές μηχανές (virtual machines)
    στο δικό μας private cloud.
     

    Αναδιαμόρφωση (Reconfiguring) της ακολουθίας εργασιών Hyper-V
     

    Ξεκινώντας την διαδικασία ανοίγοντας
    το Deployment
    Workbench
    και κατευθυνόμαστε (navigating) διαμέσου του console tree στην επιλογή Deployment Workbench | Deployment Shares | MDT Deployment Share | Task Sequences | OS Install. Αμέσως μετά κάνουμε δεξί κλικ στην ακολουθία
    εργασιών (task
    sequence) την οποία
    έχουμε δημιουργήσει για τον Hyper-V και επιλέγουμε την εντολή Properties από το shortcut menu. Όταν ολοκληρώσουμε την συγκεκριμένη ενέργεια
    η σελίδα properties θα
    εμφανιστεί αυτόματα.
     

    Εν συνεχεία από τη σελίδα properties επιλέγουμε το Task Sequence tab. Το συγκεκριμένο tab μπορεί να χρησιμοποιηθεί για την
    τροποποίηση της υπάρχουσας ακολουθίας εργασιών (task sequence). Με δεδομένο ότι δημιουργούμε έναν Hyper-V server, είναι απαραίτητο να εγκαταστήσουμε
    τον Hyper-V server role. Για να τα προηγούμενα, επιλέγουμε το
    Tattoo option από την υφιστάμενη ακολουθία εργασιών
    και αμέσως μετά επιλέγουμε την εντολή Roles | Install Roles and Features από το Add menu. Εφόσον επιλέξουμε την συγκεκριμένη εντολή,
    στο details
    pane θα εμφανιστεί μια σειρά από ρόλους και
    χαρακτηριστικά που είναι διαθέσιμα προς εγκατάσταση. Επιλέγουμε “τσεκάροντας” το
    Hyper-V (x64 only) check box, όπως αυτό απεικονίζεται στην Εικόνα
    1.
     
























    Εικόνα 1: Θαπρέπει να εγκαταστήσουμε τον
    Hyper-V role. 

    Είναι φυσικό και θεμιτό ότι ανάλογα
    με τις ανάγκες σαςνα επιλέξετε μια σειρά επιπλέον χαρακτηριστικών τα οποία θα
    θελήσετε να εγκαταστήσετε. Για παράδειγμα, σε ένα παραγωγικό περιβάλλον πιθανώς
    θα θέλετε να εγκαταστήσετε την υπηρεσία Failover Clustering service. Στην συγκεκριμένη σειρά άρθρων όμως δεν
    πρόκειται να χρησιμοποιήσω το failover clustering.
     

    Ανεξαρτήτως βεβαίως του γεγονότος
    του εάν θα χρησιμοποιήσετε ή όχι την υπηρεσία failover clustering, θα πρέπει να επιλέξουμε το Multipath I/O (Core) check box. Η επιλογή αυτή θα μας επιτρέψει την ευκολότερη
    σύνδεση σε ένα storage pool
    αργότερα. Εν συνεχεία επιλέγουμε
    τα components
    τα οποία θέλουμε να
    εγκαταστήσουμε, και αμέσως μετά κάνουμε κλικ στο Apply ακολουθούμενο από το OK.
     

    Σε μια εγκατάσταση επιχειρησιακού
    παραγωγικού περιβάλλοντος θα ισχυριζόταν κάποιος ότι χρειάζετε κάποια επιπλέον
    εργασία όσον αφορά τις ακολουθίες εργασιών. Χαρακτηριστικά αναφέρω ότι ενδεχομένως
    θα θέλαμε να προσθέσουμε μια σειρά οδηγών συσκευών (drivers) ή κάποιες εφαρμογές (applications). Λόγω του ότι είναι πολλά αυτά τα οποία
    θα πρέπει να αναλύσω σε αυτήν την σειρά άρθρων, θα επιστρέψω αργότερα για το
    συγκεκριμένο θέμα, στοιχείο το οποίο είναι άρρηκτα συνδεδεμένο αν΄λογα με την
    έκταση την οποία θα λάβει η συγκεκριμένη σειρά άρθρων. Για την ώρα θα συνεχίσουμε
    με σκοπό να καταδείξω τον τρόπο εργασίας και διαχείρισης των ακολουθιών
    εργασιών τις οποίες έχουμε ενεργοποιήσει και ρυθμίσει.
     

    Αναβαθμίζοντας το Deployment
    Share
     

    Σε αυτό το σημείο θα πρέπει
    να αναβαθμίσουμε το deployment share.
    Διαφορετικά εάν δεν το αναβαθμίσουμε καμία από τις ακολουθίες εργασιών (task sequences) τις οποίες έχουμε δημιουργήσει δεν
    πρόκειται να δουλέψει. Για να το επιτύχουμε αυτό θα πρέπει να πλοηγηθούμε διαμέσου
    του console
    tree στο Deployment Workbench | Deployment Shares | MDT Deployment Share. Εν συνεχεία, κάνουμε δεξί κλικ στο MDT Deployment Share container και επιλέγουμε την εντολή Update Deployment Share από το αναδιπλούμενο shortcut menu.
     

    Ως αποτέλεσμα της προηγούμενης
    επιλογής θα εμφανιστεί ο wizard
    του οποίου η αρχική οθόνη
    μας ερωτά εάν επιθυμούμε να βελτιστωποιήσουμε (optimize) την διαδικασία αναβάθμισης του boot image ή εάν επιθυμούμε αντίστοιχα την πλήρη
    επαδημιουργία (completely regenerate)
    των boot images. Στην δεδομένη στιγμή, προχωρούμε μπροστά
    και επιλέγουμε την επιλογή της πλήρους επαναδημιουργίας των boot images, όπως αυτό απεικονίζεται στην Εικόνα
    2.
     





    Εικόνα 2: Πρέπει
    οπωσδήποτε να αναβαθμίσουμε το deployment share.
     

    Κάνουμε κλικ στο Next, στοιχείο το οποίο θα μας οδηγήσει  σε μια οθόνη περίληψης (summary screen) η οποία μας επιβεβαιώνει τις
    επιλογές τις οποίες έχουμε επιλέξει. Κάνουμε κλικ στο Next για μια ακόμη φορά και τα deployment images θα δημιουργηθούν. Το χρονικό διάστημα το
    οποίο θα απαιτηθεί για την ολοκλήρωση της συγκεκριμένης διαδικασίας εξαρτάται άμεσα
    από τις δυαντότητες του hardware capabilities,
    κρίνοντας όμως από τον δικό μου lab server η διαδικασία ολοκληρώθηκε σε πέντε (5)
    λεπτά της ώρας.
     

    Εγκαθιστώντας τα Windows
    Deployment Services
     

    Το επόμενο βήμα στην διαδικασία
    είναι η εγκατάσταση των Windows Deployment Services στον
    διακομιστή (server)
    ο οποίος τρέχει το Deployment Workbench.
    Το
    παραπάνω μπορεί να επιτευχθεί διαμέσου του Server Manager. Συνεπώς ανοίγουμε τον Server Manager και επιλέγουμε το Roles container. Εν συνεχεία κάνουμε κλικ στον σύνδεσμο
    Add Roles και τα Windows θα εκκινήσουν τον Add Roles wizard.
     

    Κάνουμε κλικ στο Next to για να προσπεράσουμε την Welcome screen του wizard. Αμέσως μετά θα εμφανιστεί μια οθόνη στην
    οποία μας ζητείται να επιλέξουμε ποιούς ρόλους θέλουμε να εγκαταστήσουμε. Επιλέγουμε
    τον Windows
    Deployment
    Services
    role και εν συνεχεία κάνουμε κλικ στο Next. Ως αποτέλεσμα της επιλογής αυτής θα εμφανιστεί
    μια οθόνη η οποία μας παρουσιάζει μια εισαγωγή των Windows Deployment Services. Κάνουμε κλικ στο Next για να προσπεράσουμε την συγκεκριμένη
    οθόνη.
     

    Στην επόμενη οθόνη η οποία αυτομάτως
    θα εμφανιστεί ερωτόμαστε ποια role
    services
    επιθυμούμε να
    εγκαταστήσουμε. Αναλυτικότερα έχουμε την δυνατότητα να επιλέξουμε την εγκατάσταση
    του Deployment
    Server και την εγκατάσταση ή μη του Transport Server. Η συμβουλή μου είναι να αφήσετε και τις
    δύο επιλογές επιλεγμένες όπως αυτό απεικονίζεται στην Εικόνα 3.
     





    Εικόνα 3: Προχωρήστε
    στην εγκατάσταση και των δύο role
    services.
     

    Κάνουμε κλικ στο Next, ακολουθούμενο από την εγκατάσταση. Τα
    Windows
    θα ξεκινήσουν αυτομάτως την
    εγκατάσταση των Windows Deployment Services.
    Όταν η όλη διαδικασία ολοκληρωθεί κάνουμε κλικ στο Close.
     

    Ρυθμίζοντας τα Windows
    Deployment Services
     

    Τώρα που τα Windows Deployment Services έχουν εγκατασταθεί θα πρέπει να
    παραμετροποιηθούν. Για να το επιτύχουμε αυτό δεν έχουμε παρά να πλοηγηθούμε διαμέσου
    του Server Manager στο Roles | Windows Deployment Services | Servers | <στον δικό σας διακομιστή - your server>, όπως αυτό απεικονίζεται στην
    Εικόνα 4.
     





    Εικόνα 4: Θα
    πρέπει να παραμετροποιήσετε τον διακομιστή σας.
     

    Στο σημείο αυτό κάνουμε δεξί κλικ
    στην λίστα όπου εμφανίζεται ο διακομιστής μας και επιλέγουμε την εντολή Configure Server από το υφιστάμενο shortcut menu. Όταν ο configuration wizard ξεκινά, κάνουμε κλικ στο Next για να προσπεράσουμε την εισαγωγική
    οθόνη.
     

    Στην επόμενη οθόνη η οποία ακολουθεί
    το σύστημα μας ερωτά να παράσχουμε μια διαδρομή (path) για τον remote installation folder. Εάν είναι δυνατόν συνιστώ την αποθήκευση
    του συγκεκριμένου φακέλου σε έναν οδηγό δίσκου (disk drive) διαφορετικό από το C:.
     

    Εν συνεχεία κάνουμε κλικ στο Next και στο σημείο αυτό ο wizard θα μας ρωτήσει για τον τρόπο με τον
    οποίο ο διακομιστής (server)
    θέλουμε να διαχειρίζεται τα client
    requests. Επιλέγουμε
    την επιλογή να δίνεται απάντηση σε όλους τους client computers (γνωστούς και αγνώστους) και αμέσως
    κάνουμε κλικ στο Next.
    Όταν το κάνουμε αυτό, τα Windows θα
    υλοποιήσουν την παραμετροποίηση και θα εκκινήσουν τα Windows Deployment Services. Όταν αυτή η διαδικασία ολοκληρωθεί, θα
    εμφανιστεί μια οθόνη η οποία θα μας ερωτά εάν θέλουμε να προσθέσουμε images στον διακομιστή μας τώρα. Η επιλογή αυτή
    είναι προεπιλεγμένη εξ ορισμού, αλλά θα χρειαστεί να την αποεπιλέξουμε αυτήν
    την επιλογή διότι χρησιμοποιούμε το Deployment Workbench για δικά μας images. Εν συνεχεία κάνουμε κλικ στο Finish για να ολοκληρωθεί η διαδικασία
    παραμετροποίησης.
     

    Προσθέτοντας τα δικά μας Images
     

    Τώρα ας προχωρήσουμε μπροστά και
    ας προσθέσουμε μερικά deployment images
    στα Windows Deployment Services. Για να το επιτύχουμε αυτό, θα πρέπει
    να πλοηγηθούμε διαμέσου του Server
    Manager
    στο Roles | Windows Deployment Services | Servers | <your server> | Boot Images. Αμέσως κάνουμε δεξί κλικ στον Boot Images φάκελο και επιλέγουμε την εντολή Add Boot Image από το shortcut menu. Στο σημείο αυτό θα μας ζητηθεί να εισαγάγουμε
    την τοποθεσία του Windows Image
    (το .WIM
    file) το οποίο
    θέλουμε να προσθέσουμε. Κάνουμε κλικ στο Browse button και αμέσως μετά θα πρέπει να πλοηγηθούμε
    (navigate) στην διαδρομή
    δίσκου (path)
    η οποία χρησιμοποιείται από το deployment share
    το οποίο δημιουργήσαμε
    διαμέσου του Deployment Workbench.
    Στα προηγούμενα άρθρα της συγκεκριμένης σειράς δημιούργησα το deployment share στο C:\DeploymentShare, συνεπώς η δική μου διαδρομή (path) θα είναι το C:\DeploymentShare\Boot. Σε αυτήν την διαδρομή υπάρχει ένα αρχείο
    το οποίο ονομάζεται LiteTouchPE_x64, όπως αυτό απεικονίζεται στην Εικόνα
    5. Αυτό είναι το αρχείο χρειάζεται να εισαχθεί, συνεπώς θα το επιλέξουμε και
    αμέσως μετά θα κάνουμε κλικ στο OK.
     





    Εικόνα 5: Εισάγουμε
    το αρχείο LiteTouchPE_x64.wim.
     

    Κάνουμε κλικ στο Next και αμέσως μετά θα μας ζητηθεί να εισάγουμε
    το όνομα του image.
    Αμέσως μετά την ολοκλήρωση της προηγούμενης διαδικασίας κάνουμε δύο φορές κλικ
    στο Next και αυτομάτως το image θα εισαχθεί. Όταν η όλη διαδικασία ολοκληρωθεί κάνουμε κλικ στο Finish.
     

    Συμπέρασμα
     

    Εως αυτό το σημείο
    έχουμε δημιουργήσει ένα boot
    image το οποίο μπορεί να γίνει deployed, αλλά συνεχίζουμε να βρισκόμαστε αρκετά
    μακριά από τον στόχο μας ο οποίος είναι χρησιμοποιώντας αυτήν την τεχνική για
    να δημιουργήσουμε ένα private cloud.
    Ζητώ την υπομονή σας μέχρι την δημοσίευση του τέταρτου μέρους της σειράς αυτής
    άρθρων.
  4. Jordan_Tsafaridis
    Αγαπητοί
    συνάδελφοι της κοινότητας πρωτίστως θα ήθελα να ευχηθώ σε όλους και τις
    οικογένειές σας καλή χρονιά με υγεία και ευτυχία. Το συγκεκριμένο άρθρο
    αποτελεί την δεύτερη συνέχεια της συζήτησης την οποία έθεσα στο πρώτο μέρος και
    αφορά την κατασκευή ενός private cloud
    παρουσιάζοντας αρχικώς την διαδικασία δημιουργίας των deployment images τα οποία θα χρησιμοποιηθούν εντός του
    cloud.
     

    Εισαγωγή
     

    Στο πρώτο
    μέρος αυτής της σειράς άρθρων, σας παρουσίασα πως να κατεβάσετε (download), να εγκαταστήσετε (install) και να παραμετροποιήσετε (configure) λογισμικό Microsoft’s Deployment Toolkit. Τώρα μιας και έχουμε δημιουργήσει
    ένα deployment share, το επόμενο βήμα είναι η δημιουργία
    μερικών εικόνων λειτουργικών συστημάτων (operating system images) τις οποίες μπορούμε να φιλοξενούμε
    (host) στο
    συγκεκριμένο share.
     

    Προσθέτοντας λειτουργικά συστήματα
     

    Η διαδικασία
    πρόσθεσης λειτουργικών συστημάτων στο “Deployment Share” είναι ιδιαίτερα απλή. Όταν “ξετυλίγουμε”
    - (expand) – το deployment share το οποίο προηγουμένως έχουμε δημιουργήσει,
    θα παρατηρήσουμε ότι εμπεριέχει έναν φάκελο ο οποίος ονομάζεται Operating Systems. Κάνουμε δεξί κλικ στο συγκεκριμένο
    container και εν συνεχεία επιλέγουμε την
    εντολή  New Folder από το συγκεκριμένο shortcut menu. Η επιλογή αυτή έχει ως αποτέλεσμα
    στα Windows την εκκίνηση του New Folder Wizard.
     

    Η αρχική οθόνη
    του New Folder Wizard.εμφανίζεται και μας ζητά να
    συμπληρώσουμε το όνομα του φακέλου καθώς επίσης και μια περιγραφή. Για τους
    σκοπούς αυτού του άρθρου, θα ονοματίσω τον συγκεκριμένο φάκελο ως Windows Server 2008 R2. Αμέσως ματά την εισαγωγή του
    ονόματος και της περιγραφής του φακέλου, κάνουμε κλικ στο Next. Στο σημείο αυτό θα πρέπει να
    εμφανιστεί μια οθόνη περίληψης (summary screen) η οποία μας παρέχει την δυνατότητα
    να πιστοποιήσουμε (verify) το όνομα και την περιγραφή στοιχεία τα οποία
    συμπληρώσαμε προηγουμένως. Αφιερώστε μερικά δευτερόλεπτα για να επιβεβαιώσετε
    ότι τα πάντα είναι σωστά και αμέσως μετά κάνουμε κλικ στο Next. Όταν τα Windows ολοκληρώσουν την δημιουργία του φακέλου, κάνουμε κλικ
    στο Finish.
     

    Αμέσως μετά την
    δημιουργία του αρχικού φακέλου λειτουργικού συστήματος (initial operating system folder), καλό θα ήταν να δημιουργήσουμε επίσης
    όλους εκείνους τους φακέλους τους οποίους πιθανόν να χρειαστούμε στην συνέχεια.
    Για τις ανάγκες του συγκεκριμένου άρθρου, δημιούργησα δύο φακέλους, τον φάκελο Windows Server 2008 R2 και τον φάκελο Windows 7 αντίστοιχα. Μπορείτε να δείτε
    αυτούς τους φακέλους στην εικόνα 1.
     























    Εικόνα 1: Δημιουργία φακέλων για οποιοδήποτε λειτουργικό σύστημα το οποίο
    επιθυμούμε να φιλοξενούμε (host) στον server.
     

    Μόλις οι φάκελοι
    αυτοί βρίσκονται στην θέση τους θα πρέπει άμεσα να εισάγουμε σε αυτούς τα
    αρχεία των λειτουργικών συστημάτων. Ξεκινάμε την διαδικασία εισάγοντας το DVD εγκατάστασης του λειτουργικού συστήματος το οποίο
    θέλουμε να εισάγουμε. Εν συνεχεία, κάνουμε δεξί κλικ στον φάκελο τον οποίο δημιουργήσαμε
    για το λειτουργικό σύστημα και επιλέγουμε την εντολή Import Operating System από το εμφανιζόμενο shortcut menu. Τα Windows αυτόματα θα εκκινήσουν τον Import
    Operating System Wizard.
     

    Η αρχική οθόνη
    του wizard μας ζητά τον τύπο του λειτουργικού συστήματος
    τον οποίο θέλουμε να προσθέσουμε. Επιλέγουμε την επιλογή Full Set of Source Files και κάνουμε κλικ στο Next. Η οθόνη η οποία ακολουθεί μας ζητά
    την διαδρομή (path) των
    πηγαίων αρχείων (source files). Μιας και στην ουσία αντιγράφουμε το
    μέσο εγκατάστασης (installation media), απλά υποδεικνύουμε στον wizard τον οδηγό DVD. Στο σημείο αυτό δεν υπάρχει η ανάγκη
    για την επιλογή ενός υποφακέλου (sub folder) μέσα από το μέσο εγκατάστασης.
     

    Κάνουμε κλικ στο Next και ο wizard θα μας ζητήσει να καθορίσουμε το όνομα της διαδρομής
    προορισμού (destination directory name). Η
    διαδρομή προορισμού (destination directory) συμπληρώνεται αυτόματα και οι
    προεπιλογές μπορεί να είναι κατάλληλες για τους σκοπούς σας. Στην περίπτωση μου,
    ο wizard αυτόματα ονομάζει την διαδρομή προορισμού Windows Server 2008 R2 x64. Η μόνη αλλαγή
    την οποία έκανα ήταν να προσθέσω το SP1 στο τέλος
    του ονόματος της διαδρομής προορισμού.
     

    Αμέσως μετά κάνουμε
    κλικ στο Next και αυτόματα εμφανίζεται μια περίληψη
    των επιλογών των οποίων επιλέξαμε. Υποθέτοντας ότι όλα είναι σωστά κάνουμε κλικ στο Next. Ο wizard θα προχωρήσει άμεσα στην εισαγωγή του λειτουργικού συστήματος
    από το μέσο εγκατάστασης. Ο χρόνος ο οποίος απαιτείται για την ολοκλήρωση της διαδικασίας
    εξαρτάται από τις δυνατότητες του server αλλά και από το λειτουργικό σύστημα
    το οποίο έχουμε επιλέξει. Στον δικό μου lab server χρειάστηκαν τέσσερα λεπτά για την εισαγωγή του Windows Server 2008 R2 και επτά περίπου λεπτά για την
    εισαγωγή των Windows 7. Όταν η όλη
    διαδικασία ολοκληρωθεί, όλες οι επιμέρους εκδόσεις των Windows θα εμφανιστούν μέσα στους αντίστοιχους φακέλους όπως
    απεικονίζονται στην εικόνα 2.
     





    Εικόνα 2: Tα Deployment images έχουν προστεθεί στους φακέλους λειτουργικών συστημάτων
    οι οποίοι έχουν δημιουργηθεί νωρίτερα.
     

    Οικοδόμηση μιας ακολουθίας εργασιών (Building a Task Sequence)
     

    Αργότερα στην
    σειρά αυτών των άρθρων θα παρουσιάσω την υλοποίηση (deploying) ενός System Center Virtual Machine Manager server και μερικών Hyper-V host servers. Εντούτοις δεν υπάρχει η ανάγκη για
    την δημιουργία με τον συμβατικό τρόπο (manually) αυτών των servers διότι πολύ απλά έχουμε ήδη δημιουργήσει το deployment image. Αν και τα deployment images πρόκειται να χρησιμοποιηθούν για την δημιουργία virtual machines μέσα στο private cloud, μπορούμε ωστόσο να τα χρησιμοποιήσουμε
    και για την υλοποίηση του δικού μας private cloud infrastructure. Συνεπώς το πρώτο βήμα για την συγκεκριμένη
    διαδικασία είναι η οικοδόμηση μια ακολουθίας εργασιών (build a task sequence) η οποία μπορεί να χρησιμοποιηθεί
    για την δημιουργία μίας γενικής χρήσης Windows Server 2008 R2 μηχανής.
     

    Για να δημιουργήσουμε
    αυτήν την ακολουθία εργασιών, ξετυλίγουμε (expand) το deployment share και αμέσως μετά κάνουμε δεξί κλικ στο Task Sequences container. Στο σημείο αυτό επιλέγουμε την εντολή
    New Folder από το shortcut menu, και ενσυνεχεία χρησιμοποιούμε τον
    εμφανιζόμενο wizard για να δημιουργήσουμε έναν φάκελο ο
    οποίος ονομάζεται OS Install. Όταν ο φάκελος αυτός δημιουργηθεί,
    κάνουμε δεξί κλικ στον φάκελο OS Install και επιλέγουμε την εντολή New Task Sequence από το shortcut menu.
     

    Τα Windows αυτόματα θα εκκινήσουν τον New Task Sequence wizard. Η αρχική οθόνη του wizard απαιτεί από εμάς να εισάγουμε έναν κωδικό ταυτότητας (identification code) για το task στο οποίο βρισκόμαστε στην φάση δημιουργίας του. Μπορούμε
    δε να χρησιμοποιήσουμε έναν οποιοδήποτε αλφαριθμητικό κώδικα επιθυμούμε αρκεί
    αυτός να χαρακτηρίζεται από την μοναδικότητά. Επιπροσθέτως απαιτείται και η ονοματολογία του συγκεκριμένου task. Στην περίπτωση μου, ονόμασα την ακολουθία εργασιών (task
    sequence) ως Windows Server 2008 R2 Generic σε συνδυασμό με Task
    Sequence ID το W2K8R2G.
     

    Ολοκληρώνοντας
    την εισαγωγή του ονόματος και του sequence ID, κάνουμε κλικ στο Next. Ο wizard στην συνέχεια θα μας ρωτήσει τον τύπο του task sequence template τον οποίο θέλουμε να χρησιμοποιήσουμε. Επιλέγουμε το Select the
    Standard Server Task Sequence option και κάνουμε κλικ στο Next.
     

    Στο σημείο αυτό
    επιλέγουμε το λειτουργικό σύστημα το οποίο θέλουμε να υλοποιήσουμε ως μέρος της
    συγκεκριμένης διαδικασίας (task) και κάνουμε κλικ στο Next. Η οθόνη η οποία ακολουθεί μας δίνει την δυνατότητα εισαγωγής του product key.
    Εάν έχουμε στην
    διάθεσή μας ένα πολλαπλής ενεργοποίησης κλειδί (multiple activation key) για τον Windows Server 2008 R2 θα πρέπει να το εισάγουμε τώρα. Στην
    αντίθετη περίπτωση επιλέγουμε να μην εισάγουμε το κλειδί ενεργοποίησης (product key) σε αυτήν την χρονική στιγμή.
     

    Ενσυνεχεία κάνοντας
    κλικ στο Next μας παρέχεται η δυνατότητα να εισάγουμε
    το όνομά μας, το όνομα του οργανισμού-επιχείρησης στην οποία εργαζόμαστε, αλλά
    και το Internet Explorer home page. Μόλις ολοκληρώσουμε την εισαγωγή των πληροφοριών αυτών κάνουμε κλικ στο Next. Αμέσως μετά θα πρέπει να εισάγουμε το
    local administrator password το οποίο θα χρησιμοποιείται από όλους τους servers οι οποίοι υλοποιούνται από το
    συγκεκριμένο image.
     

    Κάνοντας κλικ
    στο Next θα εμφανιστεί αυτόματα μια περίληψη των
    επιλογών μας στην ακολουθία εργασιών την οποία πρόκειται να υλοποιήσουμε. Πιστοποιούμε
    ότι όλα είναι σωστά και κάνουμε κλικ στο Next to για να δημιουργήσουμε την ακολουθία. Όταν η όλη διαδικασία ολοκληρωθεί, κάνουμε κλικ στο Finish. Σαν επακόλουθο θα μπορούμε να δούμε την
    νέα αυτή ακολουθία εργασιών να εμφανίζεται εντός του φακέλου OS Install, όπως αυτό φαίνεται στην εικόνα 3.
     





    Εικόνα 3: Η νέα ακολουθία εργασιών εμφανίζεται στον φάκελο OS Install.
     

    Όπως προαναφέρθηκε,
    πρόκειται να χρησιμοποιήσουμε τα συγκεκριμένα deployment images για την υλοποίηση του δικού μας private cloud infrastructure, και ενσυνεχεία για την δημιουργία
    των virtual machines εντός του private cloud. Μιας και θα χρησιμοποιήσουμε τα images για να μας βοηθήσουν στην δημιουργία του private cloud infrastructure, θα χρειαστούμε και μια ακολουθία
    εργασιών (task sequence) η οποία μπορεί να χρησιμοποιηθεί
    για την υλοποίηση ενός Hyper-V server.
     

    Για την ώρα,
    μπορούμε να προχωρήσουμε και να δημιουργήσουμε μια ακολουθία εργασιών η οποία
    θα είναι αντίγραφο αυτής που δημιουργήσαμε προηγουμένως. Η μόνη διαφορά θα είναι
    ότι αυτή η ακολουθία εργασιών θα έχει ένα διαφορετικό όνομα και ID το οποίο θα αντικατροπτίζει το γεγονός του ότι η
    συγκεκριμένη ακολουθία εργασιών θα χρησιμοποιηθεί για την υλοποίηση Hyper-V host servers. Στο τρίτο μέρος αυτής της σειράς άρθρων
    θα σας παρουσιάσω την μέθοδο με την οποία θα τροποποιήσετε αυτήν την ακολουθία
    εργασιών έτσι ώστε να επιτρέπει την εκπλήρωση του σκοπού για τον οποίο
    δημιουργήθηκε.
     

    Συμπέρασμα
     

    Έχοντας δημιουργήσει
    μερικές deployment images,
    έφτασε η ώρα να κάνουμε ορισμένες ελάσσονος σημασίας τροποιποιήσεις στις ακολουθίες
    εργασιών έτσι ώστε να ξεκινήσουμε την υλοποίση των δικών μας infrastructure servers. Υπομονή μέχρι το τρίτο μέρος.
  5. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι
    της κοινότητας θα παρουσιάσω την διαδικασία με την οποία μπορούμε να υλοποιήσουμε
    μια υποδομή private IaaS cloud στην οποία διαμέσου ενός απλού Web Interface μπορούμε
    να δημιουργήσουμε νέους servers στιγμαία (on the fly).

     

    Εισαγωγή
     

    Κατά την τελευταία τριετία ο όρος
    cloud αποτελεί τον πλέον δημοφιλή όρο στον
    κόσμο της πληροφορικής και γενικότερα της τεχνολογίας. Τα Infrastructure as a Service (IaaS) clouds προσφέρουν πρωτοφανή επίπεδα ευελιξίας
    διότι επιτρέπουν νέες εικονικές μηχανές να δημιουργούνται και να τροφοδοτούνται
    με πόρους συστήματος ταχύτατα (quickly provisioned and
    deployed).
     

    Βεβαίως οφείλω να ομολογήσω ότι
    σε καμία περίπτωση δεν μπορώ να αρνηθώ τα πλεονεκτήματα των υποδομών οι οποίες χρησιμοποιούν
    IaaS clouds, αλλά πάντοτε ήμουν απρόθυμος να τις
    χρησιμοποιήσω στον οργανισμό τον οποίο εργάζομαι, διότι πολύ απλά όταν ξεκινούμε την
    εξωτερική ανάθεση των διακομιστών μας (Servers) σε εξωτερικά clouds εξαρτόμαστε πλέον αποκλειστικά από την
    σύνδεσή μας στο διαδίκτυο (Internet connection).
    Συνεπώς εάν η σύνδεση στο διαδίκτυο διακόπτεται λόγω βλάβης (ή βρίσκεται σε κατάσταση
    τέλματος λόγω υπερβολικής κίνησης - becomes bogged down due to excessive traffic) τότε η δυνατότητα πρόσβασης των
    διακομιστών μας καθίσταται προβληματική.
     

    Άρα λοιπόν γιά όλους εμάς οι οποίοι
    θέλουμε να επιτύχουν την ευελεξία μιας υποδομής IaaS cloud, αλλά δεν θέλουμε σε καμία περίπτωση να
    χάσουμε την πρόσβαση στους δικτυακούς διακομιστές μας λόγω απώλειας πρόσβασης
    στο διαδίκτυο τότε η λύση για να πετύχουμε το μέγιστο μεταξύ των δύο κόσμων η
    ενδεδειγμένη λύση είναι αυτή της ανάπτυξης μιας υποδομής private cloud.
     

    Σε αυτήν την σειρά άρθρων αντικειμενικός
    σκοπός μου είναι να παρουσιάσω με κατανοητό τρόπο πως μπορείτε να κατασκευάσετε
    ένα private
    cloud το οποίο μπορεί να χρησιμοποιηθεί για
    την γρήγορη ανάπτυξη διαφόρων δικτυακών διακομιστών (deploy various types of network servers). Το cloud θα απαρτίζεται από ένα self-service portal το οποίο θα επιτρέπει στους διαχειριστές
    του συστήματος (ή σε συγκεκριμένους χρήστες στους οποίους έχουμε δώσει δικαίωματα) χρησιμοποιώντας
    ένα απλό Web
    interface
    να επιλέγουμε τους
    απαραίτητους πόρους συστήματος (μνήμη, αποθηκευτικός χώρος κ.τ.λ.) σε
    συνδυασμό με τους ρόλους του διακομιστή (pick and choose the resources that they want to provision and the server roles) τον οποίο θέλουμε να υλοποιήσουμε. Χαρακτηριστικά
    αναφέρω την δημιουργία με το εφαρμογή λιγοστών κλικ στο mouse από έναν διαχειριστή συστήματος συννέφου
    (cloud administrator) ενός καινούριου domain controller ή ενός νέου Exchange Server.
     

    Απαιτήσεις σε επίπεδο Active Directory
     

    Η λύση του private cloud solution την οποία πρόκειται να παρουσιάσω σε αυτήν
    την σειρά άρθρων εξαρτάται άμεσα ή ακόμη καλύτερα προϋποθέτει την ύπαρξη μιας υποδομής
    Active Directory σε λειτουργία. Και αυτό διότι πολύ απλά
    ο τρόπος με τον οποίο θα υλοποιηθεί το private cloud απαιτεί την ύπαρξη ήδη εγκατεστημέων
    φυσικών domain
    controllers. Εάν παρόλα
    αυτά τολμήσετε να κατασκευάσετε – υλοποιήσετε ένα private cloud και στην συνέχεια προσπαθήσετε μία μετατροπή
    φυσικής μηχανής σε εικονική (physical to
    virtual
    migration) στους
    δικούς σας domain
    controllers
    τότε το πιθανότερο είναι
    ότι θα βρεθείτε σε μια δυσάρεστη κατάσταση στην οποία το private cloud θα καταστεί μη προσβάσιμο. Ως εκ τούτου
    για να αποφύγετε να συμβεί αυτό θα πρέπει οπωσδήποτε να υπάρχει κατ’ ελάχιστον ένας
    domain controller (το συνιστώμενο είναι να υπάρχουν
    περισσότεροι του ενός) ο οποίος θα βρίσκεται εκτός του εικονικού περιβάλλοντος
    (outside
    of the virtual environment).
     

    Το Microsoft Deployment Toolkit
     

    Το πρώτο βήμα για την κατασκευή
    του δικού μας private cloud
    αποτελεί η εγκατάσταση
    και ρύθνιση του Microsoft Deployment Toolkit
    2010. Το Microsoft Deployment Toolkit είναι
    ένα ελεύθερο σε χρήση εργαλείο και μπορείται να το κατεβάσετε από εδώ.
     

    Για τον σκοπό της συγκεκριμένης
    σειράς άρθρων, θα εγκαταστήσω το Microsoft Deployment Toolkit σε έναν φυσικό διακομιστή (physical server) ο οποίος θα είναι προσβάσιμος από
    όλους εκείνους τους διακομιστές οι οποίοι θα υλοποιούν το private cloud. Το Microsoft Deployment Toolkit δεν είναι μια εφαρμογή υψηλών απαιτήσεων
    και δεν απαιτεί την εγκατάστασή της σε έναν διακομιστή αποκλειστικά (dedicated server). Ο διακομιστής ο οποίος θα χρησιμοποιηθεί
    θα εξυπηρετεί το όλο σύστημα ως το αποθηκευτικό μέσο (repository) για τα deployment images. Για την αποφυγή παρεξηγήσεων θα ήθελα
    σε αυτό το σημείο να τονίσω θα πρέπει να εξασφαλίσουμε ότι ο συγκεκριμένος
    διακομιστής διαθέτει περίσσεια αποθηκευτικού χώρου (plenty of free disk space) για τα deployment images τα οποία θελετα να δημιουργήσετε. Αυτές
    οι εικόνες (images)
    θα πρέπει να είναι διαθέσιμες διαμέσου ενός network share το οποίο θα δημιουργήσουμε αργότερα.
     

    Εγκαθιστώντας το Microsoft Deployment Toolkit
     

    Το μέγεθος του Windows Deployment Toolkit είναι περίπου 16 MB. Από την στιγμή κατά την οποία θα ολοκληρωθεί
    το «κατέβασμά» του από το διαδίκτυο, τρέχουμε αμέσως το εκτελέσιμο αρχείο και
    θα ξεκινήσει αυτόματα ο Microsoft Deployment Toolkit Setup
    Wizard. Για τις ανάγκες
    του συγκεκριμένου άρθρου θα χρησιμοποιήσω το Update 1 (5.1.1642.01) του συγκεκριμένου toolkit.
     

    Κάνουμε κλικ στο Next για να προσπεράσουμε την Welcome οθόνη του wizard και αμέσως μετά εμφανίζεται η οθόνη στην
    οποία μας ζητείται να αποδεχτούμε το license agreement. Αμέσως μετά την αποδοχή κάνουμε κλικ
    στο Next. Εν συνεχεία θα
    εμφανιστεί η επόμενη οθόνη στην οποία μας ζητείται να επιλέξουμε τα
    χαρακτηριστικά (components)
    τα οποία θέλουμε να εγκατασταθούν. Στην περίπτωσή μας θα επιλέξουμε όλα τα διαθέσιμα
    χαρακτηριστικά (ούτως ή άλλως αυτή είναι η εξορισμού επιλογή) και κάνουμε κλικ
    στο Next και ενσυνεχεία ακολουθεί το Install και το Finish.
     

    Δημιουργώντας ένα Deployment Share
     

    Μιας και η εγκατάσταση του Windows Deployment Toolkit έχει πλέον ολοκληρωθεί, τώρα θα πρέπει
    να δημιουργήσουμε το deployment share.
    Για να το επιτύχουμε αυτό ανοίγουμε το Deployment Workbench, και εν συνεχεία κάνουμε δεξί κλικ στο
    Deployment
    Shares container, από το οποίο επιλέγουμε το New Deployment Share command από το εμφανιζόμενο μενού shortcut, όπως αυτό απεικονίζεται στην Εικόνα
    1.
     






















     
    Εικόνα 1:
    Δεξί κλικ στο Deployment Share container και επιλογή του New Deployment Share command από το μενού shortcut.
     

    Κατά την διάρκεια της διαδικασίας
    δημιουργίας του deployment share,
    υπάρχει η πιθανότητα να εμφανιστεί ένα μήνυμα λάθους το οποίο θα σας κοινοποιεί
    ότι απαιτείται μια νεότερη έκδοση του Windows Automated Installation Kit. Εφόσον λάβετε αυτό το μήνυμα μπορείται
    να κατεβάσετε το Windows Automated Installation Kit.
    Θα πρέπει να λάβετε υπόψην σας ότι πριν από την εγκατάσταση της συγκεκριμένης έκδοσης
    του Automated
    Installation
    Kit θα πρέπει πρωτίστως να εγκαταστήσετε
    το SP1 των Windows Server 2008 R2. Μπορείται να κατεβάσετε το service pack από εδώ.
     

    Όταν ενημερώνεται το Deployment
    Workbench για την δημιουργία ενός καινούριου deployment share, τα Windows θα εκκινήσουν αυτόματα τον New Deployment Share Wizard. Η αρχική οθόνη του wizard σας ερωτά να δώσετε μια διαδρομή δίσκου
    (deployment
    share path), όπως αυτό απεικονίζεται στην εικόνα
    2. Αυτή η διαδρομή (path)
    είναι αυτή στην οποία όλες τα deployment images
    θα βρίσκονται
    αποθηκευμένα. Συνεπώς θα πρέπει να λάβετε υπόψην σας έτσι ώστε η επιλογή της
    συγκεκριμένης τοποθεσίας να διαθέτει άφθονο ελεύθερο αποθηκεθτικό χώρο.
     




     
    Εικόνα 2: Θα
    πρέπει να επιλέξετε μια τοποθεσία (location) με άφθονο ελεύθερο χώρο.
     

    Αμέσως μετά κάνουμε κλικ στο Next, όπου αυτόματα θα μας ζητηθεί να εισάγουμε
    ένα όνομα για το deployment share
    το οποίο πρόκειται να
    δημιουργήσουμε. Όπως θα παρατηρήσετε στην εικόνα 3, το προκαθορισμένο όνομα (default name) είναι το DeploymentShare$. Το σύμβολο του δολαρίου $ στο τέλος
    του share name καθιστά το συγκεκριμένο share αόρατο.
     




     
    Εικόνα 3: Η
    εξορισμού επιλογή είναι η δημιουργία ενός κρυφού share.
     

    Μόλις κάνουμε κλικ στο Next, θα μας ζητηθεί να εισάγουμε μια περιγραφή
    του share το οποίο θα δημιουργήσουμε σε λίγο. Στην
    συγκεκριμένη περίπτωση πρόκειται να χρησιμοποιήσω την εξ ορισμού επιλογή η οποία
    είναι το MDT
    Deployment
    Share.
     

    Εν συνεχεία κάνουμε κλικ στο Next και ο wizard θα μας ρωτήσει εάν πρόκειται κάποιο image να πρέπει να γίνει captured κατά την διάρκεια ενός bare metal deployment. Αφήνουμε την επιλογή αυτή επιλεγμένη
    και κάνουμε κλικ στο Next.
     

    Η επόμενη οθόνη μας ρωτά εάν θέλουμε
    το σύστημα να ζητά από τους χρήστες το administrative password. Σας συνιστώ να μην επιλέξετε αυτήν την
    επιλογή διότι όπως γίνεται άμεσα αντιληπτό δεν θα επιθυμείτε σε καμία περίπτωση
    οι χρήστες να γνωρίζουν το τοπικό administrative password.
     

    Κάνοντας κλικ στο Next, ο wizard θα μας ρωτήσει εάν θέλουμε τα Windows να ζητά από τους χρήστες για το κλειδί
    ενεργοποίησης (product key).
    Για λόγους αυτοματισμού στην διαδικασία δημιουργίας ο κωδικός θα εισάγεται αυτόματα
    και συνεπώς δεν θα επιλέξουμε την συγκεκριμένη επιλογή.
     

    Κάνοντας κλικ στο Next θα παρουσιαστεί αυτόματα μια περίληψη
    των configuration
    options
    τις οποίες έχουμε
    επιλέξει. Θα συνιστούσα να αφιερώσετε λίγο χρόνο και να διαβάσετε προσεκτικά την
    συγκεκριμένη περίληψη έτσι ώστε να διασφαλίσετε ότι όλα είναι σωστά. Υποθέτωντας
    ότι τα πάντα είναι σωστά κάνουμε κλικ στο Next για να δημιουργηθεί το deployment share. Όταν η διαδικασία ολοκληρωθεί τότε κάνουμε κλικ στο Finish.
     

    Εάν ξεδιπλώσουμε το Deployment Shares container, θα παρατηρήσετ ένα deployment share με το όνομα το οποίο δηλώσατε στον wizard. Αυτο το deployment share περιλαμβάνει ένα αριθμό από υποφακέλους
    (sub folders) τους οποίους θα χρησιμοποιήσουμε όταν
    θα συσχετίσουμε τα operating system
    images με το share. Για του λόγου το αληθές μπορείτε να δείτε
    πως θα απεικονίζεται το νέο deployment share
    στην εικόνα 4.
     




     
    Εικόνα 4: Το νέο deployment share περιλαμβάνει μια σειρά από sub
    containers.
     

    Συμπέρασμα
     

    Ολοκληρώντας έχοντας δημιουργήσει το deployment share, έφτασε η ώρα να προσθέσουμε ορισμένα λειτουργικά
    συστήματα σε αυτό. Υπομονή μέχρι την δημοσίευση του δευτέρου μέρους του
    συγκεκριμένου άρθρου.
  6. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι της κοινότητας η Microsoft πριν από λίγες ώρες μας αποκάλυψε τις τεχνικές προδιαγραφές του καινούριου συστήματος διαχείρισης αρχείων (file system) το οποίο ονομάζεται RsFS (Resilient File System) και το οποίο θα αποτελεί αναπόσπαστο χαρακτηριστικό των Windows 8 Server.
    Για περισσότερες λεπτομέρειες σας παραθέτω παρακάτω το πρωτότυπο κείμενο στην Αγγλική γλώσσα όπως δημοσιεύθηκε από την τεχνική υπηρεσία της Microsoft και συγκεκριμένα από τον Surendra Verm. Όπως θα συμφωνήσετε πιστεύω μαζί μου τα τεχνικά χαρακτηριστικά του καινούριου συστήματος διαχείρισης αρχείων είναι απλά συγκλονιστικά.
     
    We wanted to continue our dialog about data storage by talking about
    the next generation file system being introduced in Windows 8.  Today,
    NTFS is the most widely used, advanced, and feature rich file system in
    broad use. But when you’re reimagining Windows, as we are for Windows 8,
    we don’t rest on past successes, and so with Windows 8 we are also
    introducing a newly engineered file system. ReFS, (which stands for
    Resilient File System), is built on the foundations of NTFS, so it
    maintains crucial compatibility while at the same time it has been
    architected and engineered for a new generation of storage technologies
    and scenarios. In Windows 8, ReFS will be introduced only as part of
    Windows Server 8, which is the same approach we have used for each and
    every file system introduction. Of course at the application level, ReFS
    stored data will be accessible from clients just as NTFS data would be.
    As you read this, let’s not forget that NTFS is by far the industry’s
    leading technology for file systems on PCs.
     
    This file system, which we call ReFS, has been designed from the
    ground up to meet a broad set of customer requirements, both today’s and
    tomorrow’s, for all the different ways that Windows is deployed.
    The key goals of ReFS are:
    Maintain a high degree of compatibility with a subset of NTFS features that are
    widely adopted while deprecating others that provide limited value at
    the cost of system complexity and footprint.
    Verify and auto-correct data. Data can get corrupted due to a number of reasons and
    therefore must be verified and, when possible, corrected automatically.
    Metadata must not be written in place to avoid the possibility of “torn
    writes,” which we will talk about in more detail below.
    Optimize for extreme scale. Use scalable structures for everything. Don’t assume
    that disk-checking algorithms, in particular, can scale to the size of
    the entire file system.
    Never take the file system offline. Assume that in the event of corruptions, it is advantageous to isolate
    the fault while allowing access to the rest of the volume. This is done
    while salvaging the maximum amount of data possible, all done live.
    Provide a full end-to-end resiliency architecture when used in conjunction with
    the Storage Spaces feature, which was co-designed and built in
    conjunction with ReFS.
    The key features of ReFS are as follows (note that some of these features are provided in conjunction with Storage Spaces).
    Metadata integrity with checksums Integrity streams providing optional user data integrity Allocate on write transactional model for robust disk updates (also known as copy on write) Large volume, file and directory sizes Storage pooling and virtualization makes file system creation and management easy Data striping for performance (bandwidth can be managed) and redundancy for fault tolerance Disk scrubbing for protection against latent disk errors Resiliency to corruptions with "salvage" for maximum volume availability in all cases Shared storage pools across machines for additional failure tolerance and load balancing In
    addition, ReFS inherits the features and semantics from NTFS including
    BitLocker encryption, access-control lists for security, USN journal,
    change notifications, symbolic links, junction points, mount points,
    reparse points, volume snapshots, file IDs, and oplocks.
    And of
    course, data stored on ReFS is accessible through the same file access
    APIs on clients that are used on any operating system that can access
    today’s NTFS volumes.
    Key design attributes and features
    Our
    design attributes are closely related to our goals. As we go through
    these attributes, keep in mind the history of producing file systems
    used by hundreds of millions of devices scaling from the smallest
    footprint machines to the largest data centers, from the smallest
    storage format to the largest multi-spindle format, from solid state
    storage to the largest drives and storage systems available. Yet at the
    same time, Windows file systems are accessed by the widest array of
    application and system software anywhere. ReFS takes that learning and
    builds on it. We didn’t start from scratch, but reimagined it where it
    made sense and built on the right parts of NTFS where that made sense.
    Above all, we are delivering this in a pragmatic manner consistent with
    the delivery of a major file system—something only Microsoft has done at
    this scale.
    Code reuse and compatibility
    When we look
    at the file system API, this is the area where compatibility is the
    most critical and technically, the most challenging. Rewriting the code
    that implements file system semantics would not lead to the right level
    of compatibility and the issues introduced would be highly dependent on
    application code, call timing, and hardware. Therefore in building ReFS,
    we reused the code responsible for implementing the Windows file system
    semantics. This code implements the file system interface (read, write,
    open, close, change notification, etc.), maintains in-memory file and
    volume state, enforces security, and maintains memory caching and
    synchronization for file data. This reuse ensures a high degree of
    compatibility with the features of NTFS that we’re carrying forward.
    Underneath
    this reused portion, the NTFS version of the code-base uses a newly
    architected engine that implements on-disk structures such as the Master
    File Table (MFT) to represent files and directories. ReFS combines this
    reused code with a brand-new engine, where a significant portion of the
    innovation behind ReFS lies. Graphically, it looks like this:

    Reliable and scalable on-disk structures
    On-disk
    structures and their manipulation are handled by the on-disk storage
    engine. This exposes a generic key-value interface, which the layer
    above leverages to implement files, directories, etc. For its own
    implementation, the storage engine uses B+ trees
    exclusively. In fact, we utilize B+ trees as the single common on-disk
    structure to represent all information on the disk. Trees can be
    embedded within other trees (a child tree’s root is stored within the
    row of a parent tree). On the disk, trees can be very large and
    multi-level or really compact with just a few keys and embedded in
    another structure. This ensures extreme scalability up and down for all
    aspects of the file system. Having a single structure significantly
    simplifies the system and reduces code. The new engine interface
    includes the notion of “tables” that are enumerable sets of key-value
    pairs. Most tables have a unique ID (called the object ID) by which they
    can be referenced. A special object table indexes all such tables in
    the system.
    Now, let’s look at how the common file system abstractions are constructed using tables.

    File structures
    As
    shown in the diagram above, directories are represented as tables.
    Because we implement tables using B+ trees, directories can scale
    efficiently, becoming very large. Files are implemented as tables
    embedded within a row of the parent directory, itself a table
    (represented as File Metadata in the diagram above). The rows within the
    File Metadata table represent the various file attributes. The file
    data extent locations are represented by an embedded stream table, which
    is a table of offset mappings (and, optionally, checksums). This means
    that the files and directories can be very large without a performance
    impact, eclipsing the limitations found in NTFS.
    As expected,
    other global structures within the file system such ACLs (Access Control
    Lists) are represented as tables rooted within the object table.
    All
    disk space allocation is managed by a hierarchical allocator, which
    represents free space by tables of free space ranges. For scalability,
    there are three such tables – the large, medium and small allocators.
    These differ in the granularity of space they manage: for example, a
    medium allocator manages medium-sized chunks allocated from the large
    allocator. This makes disk allocation algorithms scale very well, and
    allows us the benefit of naturally collocating related metadata for
    better performance. The roots of these allocators as well as that of the
    object table are reachable from a well-known location on the disk. Some
    tables have allocators that are private to them, reducing contention
    and encouraging better allocation locality.
    Apart from global
    system metadata tables, the entries in the object table refer to
    directories, since files are embedded within directories.
    Robust disk update strategy
    Updating
    the disk reliably and efficiently is one of the most important and
    challenging aspects of a file system design. We spent a lot of time
    evaluating various approaches. One of the approaches we considered and
    rejected was to implement a log structured file system. This approach is
    unsuitable for the type of general-purpose file system required by
    Windows. NTFS relies on a journal of transactions to ensure consistency
    on the disk. That approach updates metadata in-place on the disk and
    uses a journal on the side to keep track of changes that can be rolled
    back on errors and during recovery from a power loss. One of the
    benefits of this approach is that it maintains the metadata layout in
    place, which can be advantageous for read performance. The main
    disadvantages of a journaling system are that writes can get randomized
    and, more importantly, the act of updating the disk can corrupt
    previously written metadata if power is lost at the time of the write, a
    problem commonly known as torn write.
    To maximize
    reliability and eliminate torn writes, we chose an allocate-on-write
    approach that never updates metadata in-place, but rather writes it to a
    different location in an atomic fashion. In some ways this borrows from
    a very old notion of “shadow paging”
    that is used to reliably update structures on the disk. Transactions
    are built on top of this allocate-on-write approach. Since the upper
    layer of ReFS is derived from NTFS, the new transaction model seamlessly
    leverages failure recovery logic already present, which has been tested
    and stabilized over many releases.
    ReFS allocates metadata in a
    way that allows writes to be combined for related parts (for example,
    stream allocation, file attributes, file names, and directory pages) in
    fewer, larger I/Os, which is great for both spinning media and flash. At
    the same time a measure of read contiguity is maintained. The
    hierarchical allocation scheme is leveraged heavily here.
    We
    perform significant testing where power is withdrawn from the system
    while the system is under extreme stress, and once the system is back
    up, all structures are examined for correctness. This testing is the
    ultimate measure of our success. We have achieved an unprecedented level
    of robustness in this test for Microsoft file systems. We believe this
    is industry-leading and fulfills our key design goals.
    Resiliency to disk corruptions
    As
    mentioned previously, one of our design goals was to detect and correct
    corruption. This not only ensures data integrity, but also improves
    system availability and online operation. Thus, all ReFS metadata is
    check-summed at the level of a B+ tree page, and the checksum is stored
    independently from the page itself. This allows us to detect all forms
    of disk corruption, including lost and misdirected writes and bit rot
    (degradation of data on the media). In addition, we have added an
    option where the contents of a file are check-summed as well. When this
    option, known as “integrity streams,” is enabled, ReFS always writes the
    file changes to a location different from the original one. This
    allocate-on-write technique ensures that pre-existing data is not lost
    due to the new write. The checksum update is done atomically with the
    data write, so that if power is lost during the write, we always have a
    consistently verifiable version of the file available whereby
    corruptions can be detected authoritatively.
    We blogged about Storage Spaces
    a couple of weeks ago. We designed ReFS and Storage Spaces to
    complement each other, as two components of a complete storage system.
    We are making Storage Spaces available for NTFS (and client PCs) because
    there is great utility in that; the architectural layering supports
    this client-side approach while we adapt ReFS for usage on clients so
    that ultimately you’ll be able to use ReFS across both clients and
    servers.
    In addition to improved performance, Storage Spaces
    protects data from partial and complete disk failures by maintaining
    copies on multiple disks. On read failures, Storage Spaces is able to
    read alternate copies, and on write failures (as well as complete media
    loss on read/write) it is able to reallocate data transparently. Many
    failures don’t involve media failure, but happen due to data
    corruptions, or lost and misdirected writes.
    These are exactly
    the failures that ReFS can detect using checksums. Once ReFS detects
    such a failure, it interfaces with Storage Spaces to read all available
    copies of data and chooses the correct one based on checksum validation.
    It then tells Storage Spaces to fix the bad copies based on the good
    copies. All of this happens transparently from the point of view of the
    application. If ReFS is not running on top of a mirrored Storage Space,
    then it has no means to automatically repair the corruption. In that
    case it will simply log an event indicating that corruption was detected
    and fail the read if it is for file data. I’ll talk more about the
    impact of this on metadata later.
    Checksums (64-bit) are always
    turned on for ReFS metadata, and assuming that the volume is hosted on a
    mirrored Storage Space, automatic correction is also always turned on.
    All integrity streams (see below) are protected in the same way. This
    creates an end-to-end high integrity solution for the customer, where
    relatively unreliable storage can be made highly reliable.
    Integrity streams
    Integrity
    streams protect file content against all forms of data corruption.
    Although this feature is valuable for many scenarios, it is not
    appropriate for some. For example, some applications prefer to manage
    their file storage carefully and rely on a particular file layout on the
    disk. Since integrity streams reallocate blocks every time file content
    is changed, the file layout is too unpredictable for these
    applications. Database systems are excellent examples of this. Such
    applications also typically maintain their own checksums of file content
    and are able to verify and correct data by direct interaction with
    Storage Spaces APIs.
    For those cases where a particular file
    layout is required, we provide mechanisms and APIs to control this
    setting at various levels of granularity.
    At the most basic
    level, integrity is an attribute of a file
    (FILE_ATTRIBUTE_INTEGRITY_STREAM). It is also an attribute of a
    directory. When present in a directory, it is inherited by all files and
    directories created inside the directory. For convenience, you can use
    the “format” command to specify this for the root directory of a volume
    at format time. Setting it on the root ensures that it propagates by
    default to every file and directory on the volume. For example:

    D:\>format /fs:refs /q /i:enable <volume>
     
    D:\>format /fs:refs /q /i:disable <volume>

     

    By default, when the /i switch is not specified, the behavior that
    the system chooses depends on whether the volume resides on a mirrored
    space. On a mirrored space, integrity is enabled because we expect the
    benefits to significantly outweigh the costs. Applications can always
    override this programmatically for individual files.
     

    Battling “bit rot”
     

    As we described earlier, the combination of ReFS and Storage Spaces
    provides a high degree of data resiliency in the presence of disk
    corruptions and storage failures. A form of data loss that is harder to
    detect and deal with happens due to ­­­“bit rot,” where parts of the
    disk develop corruptions over time that go largely undetected since
    those parts are not read frequently. By the time they are read and
    detected, the alternate copies may have also been corrupted or lost due
    to other failures.
     

    In order to deal with bit rot, we have added a system task that
    periodically scrubs all metadata and Integrity Stream data on a ReFS
    volume residing on a mirrored Storage Space. Scrubbing involves reading
    all the redundant copies and validating their correctness using the ReFS
    checksums. If checksums mismatch, bad copies are fixed using good ones.
     

    The file attribute FILE_ATTRIBUTE_NO_SCRUB_DATA indicates that the
    scrubber should skip the file. This attribute is useful for those
    applications that maintain their own integrity information, when the
    application developer wants tighter control over when and how those
    files are scrubbed.
     

    The Integrity.exe command line tool is a powerful way to manage the integrity and scrubbing policies.
     

    When all else fails…continued volume availability
     

    We expect many customers to use ReFS in conjunction with mirrored
    Storage Spaces, in which case corruptions will be automatically and
    transparently fixed. But there are cases, admittedly rare, when even a
    volume on a mirrored space can get corrupted – for example faulty system
    memory can corrupt data, which can then find its way to the disk and
    corrupt all redundant copies. In addition, some customers may not choose
    to use a mirrored storage space underneath ReFS.
     

    For these cases where the volume gets corrupted, ReFS implements
    “salvage,” a feature that removes the corrupt data from the namespace on
    a live volume. The intention behind this feature is to ensure that
    non-repairable corruption does not adversely affect the availability of
    good data. If, for example, a single file in a directory were to become
    corrupt and could not be automatically repaired, ReFS will remove that
    file from the file system namespace while salvaging the rest of the
    volume. This operation can typically be completed in under a second.
     

    Normally, the file system cannot open or delete a corrupt file,
    making it impossible for an administrator to respond. But because ReFS
    can still salvage the corrupt data, the administrator is able to recover
    that file from a backup or have the application re-create it without
    taking the file system offline. This key innovation ensures that we do
    not need to run an expensive offline disk checking and correcting tool,
    and allows for very large data volumes to be deployed without risking
    large offline periods due to corruption.
     

    A clean fit into the Windows storage stack
     

    We knew we had to design for maximum flexibility and compatibility.
    We designed ReFS to plug into the storage stack just like another file
    system, to maximize compatibility with the other layers around it. For
    example, it can seamlessly leverage BitLocker encryption, Access Control
    Lists for security, USN journal, change notifications, symbolic links,
    junction points, mount points, reparse points, volume snapshots, file
    IDs, and oplocks. We expect most file system filters to work seamlessly
    with ReFS with little or no modification. Our testing bore this out; for
    example, we were able to validate the functionality of the existing
    Forefront antivirus solution.
     

    Some filters that depend on the NTFS physical format will need
    greater modification. We run an extensive compatibility program where we
    test our file systems with third-party antivirus, backup, and other
    such software. We are doing the same with ReFS and will work with our
    key partners to address any incompatibilities that we discover. This is
    something we have done before and is not unique to ReFS.
     

    An aspect of flexibility worth noting is that although ReFS and
    Storage Spaces work well together, they are designed to run
    independently of each other. This provides maximum deployment
    flexibility for both components without unnecessarily limiting each
    other. Or said another way, there are reliability and performance
    tradeoffs that can be made in choosing a complete storage solution,
    including deploying ReFS with underlying storage from our partners.
     

    With Storage Spaces, a storage pool can be shared by multiple
    machines and the virtual disks can seamlessly transition between them,
    providing additional resiliency to failures. Because of the way we have
    architected the system, ReFS can seamlessly take advantage of this.
     

    Usage
     

    We have tested ReFS using a sophisticated and vast set of tens of
    thousands of tests that have been developed over two decades for NTFS.
    These tests simulate and exceed the requirements of the deployments we
    expect in terms of stress on the system, failures such as power loss,
    scalability, and performance. Therefore, ReFS is ready to be
    deployment-tested in a managed environment. Being the first version of a
    major file system, we do suggest just a bit of caution. We do not
    characterize ReFS in Windows 8 as a “beta” feature. It will be a
    production-ready release when Windows 8 comes out of beta, with the
    caveat that nothing is more important than the reliability of data. So,
    unlike any other aspect of a system, this is one where a conservative
    approach to initial deployment and testing is mandatory.
     

    With this in mind, we will implement ReFS in a staged evolution of
    the feature: first as a storage system for Windows Server, then as
    storage for clients, and then ultimately as a boot volume. This is the
    same approach we have used with new file systems in the past.
     

    Initially, our primary test focus will be running ReFS as a file
    server. We expect customers to benefit from using it as a file server,
    especially on a mirrored Storage Space. We also plan to work with our
    storage partners to integrate it with their storage solutions.
     

    Conclusion
     

    Along with Storage Spaces, ReFS forms the foundation of storage on
    Windows for the next decade or more. We believe this significantly
    advances our state of the art for storage. Together, Storage Spaces and
    ReFS have been architected with headroom to innovate further, and we
    expect that we will see ReFS as the next massively deployed file system.
    FAQ:
     

    Q) Why is it named ReFS?
     

    ReFS stands for Resilient File System. Although it is designed to be
    better in many dimensions, resiliency stands out as one of its most
    prominent features.
     

    Q) What are the capacity limits of ReFS?
     

    The table below shows the capacity limits of the on-disk format.
    Other concerns may determine some practical limits, such as the system
    configuration (for example, the amount of memory), limits set by various
    system components, as well as time taken to populate data sets, backup
    times, etc.
     



    Attribute


    Limit based on the on-disk format


    Maximum size of a single file


    2^64-1 bytes


    Maximum size of a single volume


    Format supports 2^78 bytes with 16KB cluster size (2^64 * 16 * 2^10). Windows stack addressing allows 2^64 bytes


    Maximum number of files in a directory


    2^64


    Maximum number of directories in a volume


    2^64


    Maximum file name length


    32K unicode characters


    Maximum path length


    32K


    Maximum size of any storage pool


    4 PB


    Maximum number of storage pools in a system


    No limit


    Maximum number of spaces in a storage pool


    No limit


     


     
    Q) Can I convert data between NTFS and ReFS?
     

    In Windows 8 there is no way to convert data in place. Data can be
    copied. This was an intentional design decision given the size of data
    sets that we see today and how impractical it would be to do this
    conversion in place, in addition to the likely change in architected
    approach before and after conversion.
     

    Q) Can I boot from ReFS in Windows Server 8?
     

    No, this is not implemented or supported.
     

    Q) Can ReFS be used on removable media or drives?
     

    No, this is not implemented or supported.
     

    Q) What semantics or features of NTFS are no longer supported on ReFS?
     

    The NTFS features we have chosen to not support in ReFS are: named
    streams, object IDs, short names, compression, file level encryption
    (EFS), user data transactions, sparse, hard-links, extended attributes,
    and quotas.
     

    Q) What about parity spaces and ReFS?
     

    ReFS is supported on the fault resiliency options provided by Storage
    Spaces. In Windows Server 8, automatic data correction is implemented
    for mirrored spaces only.
     

    Q) Is clustering supported?
     

    Failover clustering is supported, whereby individual volumes can
    failover across machines. In addition, shared storage pools in a cluster
    are supported.
     

    Q) What about RAID? How do I use ReFS capabilities of striping,
    mirroring, or other forms of RAID? Does ReFS deliver the read
    performance needed for video, for example?
     

    ReFS leverages the data redundancy capabilities of Storage Spaces,
    which include striped mirrors and parity. The read performance of ReFS
    is expected to be similar to that of NTFS, with which it shares a lot of
    the relevant code. It will be great at streaming data.
     

    Q) How come ReFS does not have deduplication, second level caching between DRAM & storage, and writable snapshots?
     

    ReFS does not itself offer deduplication. One side effect of its
    familiar, pluggable, file system architecture is that other
    deduplication products will be able to plug into ReFS the same way they
    do with NTFS.
     

    ReFS does not explicitly implement a second-level cache, but customers can use third-party solutions for this.
     

    ReFS and VSS work together to provide snapshots in a manner
    consistent with NTFS in Windows environments. For now, they don’t
    support writable snapshots or snapshots larger than 64TB.
     
  7. Jordan_Tsafaridis
    Εισαγωγή
     

    Στο τρίτο μέρος αυτής της σειράς άρθρων θα αναφερθούμε στα σενάρια
    Microsoft Cloud και πως αυτά ενεργοποιούνται ή εμπλουτίζονται
    χρησιμοποιώντας τα Windows
    8
    Server και Client τα οποία υποστηρίζουν πλήρως το virtualization και το cloud computing.
     

    Τα τεχνικά
    χαρακτηριστικά του
    Cloud και τα ωφέληαυτού
     

    Η Microsoft προσφέρει λύσεις τόσο public cloud όσο και private cloud.
    Όλες αυτές οι λύσεις έχουν δομηθεί γύρω από ένα κοινό θεμέλειο λίθο ο οποίος
    έχει τέσσερα βασικά τεχνικά χαρακτηριστικά.
     

    Το πρώτο από
    τα τεχνικά αυτά χαρακτηριστικά είναι τα pooled resources τα οποία μας
    επιτρέπουν να βελτιστοποιήσουμε την χρήση των πόρων του συστήματός μας και ως
    εκ τούτου να ελαχιστοποιούμε τα κόστη.
     

    Το δεύτερο
    τεχνικό χαρακτηριστικό είναι η δυνατότητα self-service η οποία επιτρέπει στα στα τμήματα ή στα business units των
    οργανισμών να υλοποιούν system provision ή ακόμη και ολόκληρες λύσεις ως προκαθορισμένες μονάδες (predefined units) περιλαμβάνοντας επίσης ένα φιλικό user interface για την διαχείρισή τους αφότου
    αυτές έχουν γίνει provisioned.
     

    Το τρίτο
    χαρακτηριστικό είναι η ελαστικότητα (elasticity) η οποία
    επιτρέπει την σμίκρυνση ή την μεγένθυση επιτρέψτε μου να πω σε τέσσερις
    διαστάσεις – (Scale up or down,
    Scale in or out) – πάντοτε βασιζόμενοι στις πραγματικές ανάγκες μας. (Capacity needs)
     

    Το τέταρτο
    και τελευταίο χαρακτηριστικό είναι το κόστος βάση χρήσης (usage-based cost or chargeback), στοιχείο το οποίο επιτρέπει
    στους πελάτες να πληρώνουν μόνον για τους πόρους τους οποίους καταναλώνουν.
     

    Τα
    χαρακτηριστικά αυτά περιγράφουν μια υποδομή (infrastructure) η οποία θα μπορεί να προσφέρεται ως υπηρεσία με μοντέλο
    κοστολόγησης, ενεργοποιώντας την δυνατότητα με την κατανάλωση υπηρεσιών να
    λαμβάνουμε τα παρακάτω : application performance, SLAs, καθώς επίσης και lifecycle management χωρίς να απαιτείται η υλοποίηση μιας πλήρους υποδομής (complete infrastructure). Η
    προσέγγιση αυτή επιτρέπει επίσης στην επιχείρηση
    να ανταποκρίνεται γρήγορα στις ανάγκες
    και να λειτουργεί προληπτικά στην κλιμάκωση
    των απαιτήσεων στο επερχόμενο τέλος του
    μήνα ή των εποχιακών αναγκών αντίστοιχα, και στη συνέχεια, την επιστροφή πίσω στα μειωμένα
    επίπεδα έτσι ώστε να πληρώνετε
    μόνο για την πρόσθετη κατανάλωση
    κατά την περίοδο αιχμής.
     

    Μοντέλα Cloud
     

    Είναι γνωστό
    σε όλους μας ότι οι διάφοροι τύποι cloud μοιράζονται κοινά θεμελειώδη χαρακτηριστικά, εντούτοις μπορούν να
    εξυπηρετούν διαφορετικά είδη υπηρεσιών. Το Infrastructure as a Service (IaaS) αποτελεί
    ένα μοντέλο υπηρεσιών το οποίο αποτελεί τον θεμέλειο λίθο των περισσοτέρων private clouds. Αντίστοίχως το Platform as a Service (PaaS) αποτελεί ένα μοντέλο υπηρεσιών το οποίο έχει σχεδιαστεί για να
    παρέχει μια πλατφόρμα ανάπτυξης (development platform) καθώς επίσης και ένα κοινό API
    για μια σειρά επιχειρησιακών εφαρμογών – (line of business applications) – οι οποίες έχουν αναπτυχθεί
    μέσα σε ένα περιβάλλον cloud. Τέλος το Software as a Service (SaaS) είναι και
    αυτό με την σειρά του ένα μοντέλο υπηρεσιών για εφαρμογές οι οποίες έχουν
    ειδικώς αναπτυχθεί σε ένα περιβάλλον public cloud
    και οι οποίες προσφέρονται ως μια λύση fee-based
    για καταναλωτική ή επιχειρησιακή χρήση.
     

    Public Clouds
     

    Τα
    Public clouds μπορούν να
    υλοποιηθούν έτσι ώστε να εξυπηρετούν ένα ή και περισσότερα μοντέλα υπηρεσιών με
    τα ακόλουθα χαρακτηστικά:
     


    Η λύση δεν βρίσκεται/υλοποιείται στις εγκαταστάσεις του πελάτη (
    customer facility)
    Ο πελάτης σε καμία περίπτωση δεν διαχειρίζεται την υποδομή (
    infrastructure)
    Οι εφαρμογές οι οποίες προσφέρονται ως υπηρεσία εξυπηρετούνται διαμέσου ενός
    κοινού
    portal
     

    Η
    Microsoft έχει αναπτύξει public clouds για υπηρεσίες
    όπως το Bing, το Windows Live Hotmail και τον Messenger, το Office365, το Azure,
    και το XBOX Live.
    Όλες αυτές υπηρεσίες διαστρωματόνονται –(layered)- πάνω από μια υλοποίηση IaaS. Το Microsoft Azure αποτελεί στην ουσία μια υλοποίση PaaS της οποίας η διαστρωμάτωση βρίσκεται επάνω σε μία λύση IaaS. Τέλος το Hotmail, ο Messenger, και το Office
    365 είναι τυπικά παραδείγματα μιας υλοποίησης SaaS η οποία και αυτή με την σειρά της διαστρωματώνεταο επάνω σε μία
    λύση IaaS.
     

    Private Clouds
     

    Ο πλέον κοινότυπος ορισμός του private cloud έρχεται από το “National Institutes of Standards and Technology (NIST)”. Παρακάτω σας παραθέτω το πρωτότυπο κείμενο του ορισμού στην Αγγλική γλώσσα όπως έχει δημοσιευθεί από το προαναφερθέντα οργανισμό : “Private cloud functionality
    includes provisioning, storage, networks, and other fundamental computing
    resources upon which the consumer is able to deploy and run arbitrary software.
    The software can include a variety of operating systems and applications. The
    consumer does not manage or control the underlying cloud infrastructure, but
    has control over the operating systems, storage, deployed applications, and
    possibly limited control of selected network components that are provided as
    resources”.
     

    Η Microsoft υιοθέτησε τον ορσιμό του NIST για το private cloud βάση του οποίου
    προσφέρει μια λύση η οποία διέπεται από τέσσερεις κύριες συνιστώσες. Η πρώτη συνιστώσα περιστρέφεται γύρω από
    την εφαρμογή. Ένα private cloud πρέπει να παρέχει προβλέψιμες
    και κλιμακούμενες υπηρεσίες εφαρμογής, επιτρέποντας στον πελάτη να πρόσβαση στις πληροφορίες της
    εφαρμογής και συνάμα για την κατάστασή της –( deep application information and health status). Η δεύτερη
    συνιστώσα υπαγορεύει ότι το private cloud πρέπει να
    είναι σε θέση να υποστηρίξει ένα cross-platform
    περιβάλλον για να είναι επιτυχής.
    Ως εκ τούτου, η λύση της Microsoft στο private cloud αγκαλιάζει λύσεις τρίτων κατασκευαστών
    όσον αφορά hypervisors, υποστήριξη λειτουργικών
    συστημάτων, λύσεων διαχείρισης, και
    τέλος πλαισίων εφαρμογής. Η τρίτη
    συνιστώσα είναι μια λύση διαχείρισης
    που υποστηρίζει ένα ετερογενές
    περιβάλλον. Ειδικά στην περίπτωση της Microsoft, αυτό αποτελεί το κέντρο του συστήματος διαχείρισης της σουίτας. Η τέταρτη και
    τελευταία συνιστώσα είναι η δυνατότητα
    να εφαρμοστεί μια λύση private cloud στις εγκαταστάσεις του πελάτη με την υιοθέτηση ορισμένων, αλλά όχι απαραίτητα όλων, των
    χαρακτηριστικών τα οποία μπορεί να διαθέτει ένα private cloud, διασφαλίζοντας
    μια σαφή και σταθερή πορεία καθόσον ο πελάτης εξελίσσει την στρατηγική
    του cloud του.
     

    Hybrid Clouds
     

    Τα Hybrid clouds αποτελούν ένα
    συνδυασμό λύσεων public cloud και private cloud οι οποίες σκοπό έχουν να επιλύουν σύνθετες επιχειρηματικές ανάγκες.
    Για παράδειγμα, μια επιχείρηση μπορεί να επιθυμεί την χρήση της λύσης Office365
    για Exchange και SharePoint σε public cloud,
    διατηρώντας ταυτόχρονα ένα private cloud για όλες τις εφαρμογές file και LOB.
     

    Ο Windows Server 8 για το Private Cloud
     

    Ο Windows Server 8 διευκολύνει την ανάπτυξη των private cloud μέσω
    της στήριξης κάποιων βασικών χαρακτηριστικών, τα οποία
    είναι τα παρακάτω :
     

    1.     
    Πολυμίσθωση (multi-tenancy)
     

    2.     
    Ασφάλεια και Απομόνωση (security and isolation)
     

    3.     
    Επεκτασιμότητα (scalability)
     

    Πολυμίσθωση – Ασφάλεια – Απομόνωση (Multi-tenancy, Security, and Isolation)
     

    Τα Private clouds παρέχουν την μέγιστη
    αξία τους όταν αντιστοίχως επιτρέπουν την μέγιστη αξιοποίηση των πόρων της υποδομής
    –(infrastructure resources). Αυτό συνεπάγεται ότι ένα private cloud θα πρέπει να επιτρέπει
    πολλαπλά τμήματα (multiple departments), επιχειρηματικές μονάδες (business units), ή πελάτες (customers) να μοιράζονται κοινούς πόρους (common resources). Ο Windows Server 8 έχει σχεδιαστεί για να παρέχει network και partition isolation για customer workloads από το επίπεδο του  hypervisor έως και το virtualization stack.

     

    Hyper-V Network Virtualization
     

    Όσον αφορά την κλίμακα της υποδομής (infrastructure scale), ο Windows Server 8 Hyper-V
    παρέχει μια σειρά χαρακτηριστικών εικονικού δικτύου –(network virtualization features)- τα οποία επιτρέπουν την απομόνωση του φόρτου εργασίας δεδομένων πάνω σε μία μοιραζόμενη δικτυακή υποδομή – (allow isolation of workload data across a shared network
    infrastructure) – χωρίς την πολυπλοκότητα (complexity) ή τους περιορισμούς οι οποίοι αποτελούν μέρος της υλοποίησης VLAN υποδομών. Συνεπώς χρησιμοποιώντας λύσεις virtual switch
    configuration και απομόνωσης (isolation) σε συνδυασμό με εικονικά δίκτυα (network virtualization), οι εικονικές μηχανές (virtual machines) μπορούν να μετακινούνται με ασφάλεια σε μια υποδομή private cloud, διατηρώντας ταυτόχρονα το ίδιο σχέδιο διευθυνσιοδότησης (network addressing scheme). Το Hyper-V network virtualization επιτρέπει την ολοκλήρωση-ενσωμάτωση (integration) υπαρχόντων private network address
    ranges στην υποδομή του private cloud, και παρέχει ένα μέσο για να φιλοξενήσει πολλαπλά cloud tenant workloads ακόμη και αν αυτά είναι αντικρουόμενα private address ranges.
     

    Quality of Service (QOS)
     

    Ο Windows Server 8 υποστηρίζει χαρακτηριστικά Quality of Service (QoS) παρέχοντας την
    δυνατότητα εγγύησης τόσο για το ελάχιστο (minimum) όσο και για το μέγιστο (maximum) bandwidth σε μία εικονική
    μηχανή (virtual machine) ή υπηρεσία (service). Αυτό επιτρέπει στις εικονικές μηχανές
    να έχουν μια προβλεπόμενη δικτυακή απόδοση (predictable network performance) και προλαμβάνει επίσης κάθε εικονική μηχανή από το να καταναλώσει
    όλο το διαθέσιμο network bandwidth.
     

    Κλιμάκωση και Απόδοση (Scalability and Performance)
     

    Ο Windows Server 8 Hyper-V περιλαμβάνει επίσης βελτιώσεις κλιμάκωσης και απόδοσης (scalability and performance enhancements) για τα private clouds. Η κλιμάκωση των εικονικών μηχανών βελτιώνεται
    διαμέσου της αυτόματης ανάθεσης επιπλέον πόρων (π.χ., dynamic memory), καθώς επίσης και από την χρήση
    νέων virtual interfaces. Αναλυτικότερα, ο Windows Server
    8 Hyper-V εισάγει έναν virtual fibre channel network adapter για την υποστήριξη virtual SANs.
    Ο Windows Server
    8 Hyper-V επίσης υποστηρίζει offloaded data transfer (ODX) για μεγιστοποιήσει χαρακτηριστικά μετάδοσης δεδομένων (storage data transfer features) διαμέσου απευθείας πρόσβασης στο
    hardware αντί διαμέσου των αργών intermediary virtual interfaces.
     

    Υπηρεσίες διασύνδεσης Cloud (Connected Cloud Services)
     

    Όταν υλοποιούμε
    λύσεις private cloud,
    ένα κοινότυπο πρόβλημα είναι το πως θα δημιουργήσουμε πολλαπλά datacenters τα οποία θα υποστηρίζουν εύρωστες και αξιόπιστες λύσεις disaster recovery και backup.
    Ο Windows Server
    8 εισάγει τον Hyper-V Replica ο οποίος παρέχει asynchronous replication των εικονικών μηχανών πάνω από δίκτυα IP.
    Αυτή η δυνατότητα ενεργοποιεί λύσεις out of the box business continuity και disaster recovery σε remote sites χρησιμοποιώντας λύσεις storage και workload agnostic. Το Replication ελέγχεται στο επίπεδο της εικονικής μηχανής (virtual machine level)
    και ολοκληρώνεται μαζί με τον Hyper-V Manager και τον Failover Cluster Manager.
     

    Επιπροσθέτως το
    να παρέχεις λύσεις business continuity και disaster recovery, με τον Windows Server
    8 γίνεται πέον μια εύκολη υπόθεση μιας και εισάγει πραγματικά differential backups των εικονικών
    μηχανών. Εφαρμόζοντας την αντιγραφή μόνον εκείνων των δεδομένων τα οποία έχουν αλλάξει,
    το κόστος των αποθηκευτικών μέσων (storage costs)
    αλλά και ο χρόνος των ααντιγράφων ασφαλείας (backup time) μειώνεται σημαντικά.
     

    Διαρκής διαθεσιμότητα (Continuous
    Availability)
     

    Τα Private clouds απαιτούν συνεχή
    διαθεσιμότητα του shared resource pool. Ο Windows Server
    8 ενεργοποιεί την συνεχή δικτυακή διαθεσιμότητα (continuous network availability) με την υποστήριξη του network adapter teaming out of the box. Με τον Windows Server
    8, δεν είναι πλέον απαραίτητο να αγοράσουμε, να υλοποιήσουμε και να υποστηρίζουμε
    τεχνικά την λύση κάποιου συγκεκριμένου κατασκευαστή. Οι πελάτες πλέον μπορούν να
    συνδυάσουν εσωτερικά internal network adapter ports με ports τα οποία προέρχονται
    από πρόσθετους (add-in) network adapters αφήνοντας την Microsoft NIC teaming λύση solution η οποία εκτίνεται σε στοιχεία υλικού διαφορετικών κατασκευαστών.
     

    Επίσης ο Windows Server 8 παρέχει Live Migration και Live Storage Migration. Το Live Migration επιτρέπει στις εικονικές μηχανές να μετακινούνται on-the-fly εως και σε 63 node Hyper-V host clusters βάσει των απαιτήσεων πόρων αλλά και των αναγκών διαχείρισης (resource requirements or maintenance needs). Ομοίως, το Live Storage Migration επιτρέπει στο VM storage νε μετακινείται μεταξύ λύσεων/συστημάτων αποθήκευσης, ενεργοποιώντας
    το backend maintenance, την ανακατανομή του φορτίου, και την αναβάθμιση της τεχνολογίας αποθήκευσης,
    χωρίς κανενός είδους VM downtime.
     

    Λύσεις αποθήκευσης (Storage
    solutions)
     

    Ο Windows Server 8 εισάγει την υποστήριξη αποθήκευσης των εικονικών μηχανών (configuration files, virtual hard disks, snapshots, και paging files) σε διαμοιραζόμενους file servers οι οποίοι υποστηρίζουν το πρωτόκολο SMB2. Συσκευές NAS devices επίσης υποστηρίζονται. Αυτό
    το χαρακτηριστικό επιτρέπει στους πελάτες να χρησιμοποιούν συσκευές χαμηλού κόστους,
    επίσης να επιτυγχάνουν την μείωση προβλέψεων και του κόστους διαχείρισης,
    καθώς και την αυξημένη ευελιξία στη δημιουργία
    μιας πολυεπίπεδης, dynamic storage υποδομής.
     

    Enhanced Virtual Desktop Infrastructure
    Support (VDI)
     

    Ο Windows Server 8 επίσης βελτιστοποιεί τα σενάρια
    VDI με την υποστήριξη  RemoteFX διαμέσου WAN,
    με τον διαχωρισμό της  αποθήκευσης των ρυθμίσεων
    των χρηστών από το λειτουργικό σύστημα, και την αυξημένη υποστήριξη των USB συνδέσεων στα RDP sessions. Το RemoteFX διαμέσου WAN επιτρέπει την χρήση του πρωτοκόλου UDP για να μειώσει το overhead, και προσαρμόζεται αυτομάτως στην
    απόδοση του δικτύου η οποία καθορίζεται από το διαθέσιμο bandwidth, και αξιοποιώντας τα δεδομένα από τον έλεγχο συμφόρησης του δικτύου
    (congestion control), προλαμβάνει την απώλεια πακέτων καθώς επίσης μειώνει την καθυστέρηση
    για την υποστήριξη απαιτητικών γραφικών εφαρμογών.
     

    Επιπροσθέτως,
    ο Windows Server
    8 επεκτείνει την υποστήριξη του USB στα RDP sessions προσφέροντας
    δυνατότητες RemoteFX USB αναδρομολόγησης (redirection). Με άλλα λόγια αυτό επιτρέπει επιπλέον
    συσκευές να υποστηρίζονται στις εικονικές μηχανές, περιλαμβάνοντας scanners, all-in-one printers, webcams, καθώς επίσης και τηλέφωνα VOIP με headsets.
     

    Συμπέρασμα
     

    Σε αυτό το άρθρο ενημερωθήκατε για τα Microsoft cloud
    services (IaaS, PaaS, SaaS) και για τα μονέλα cloud (private, public, hybrid), σε συνδυασμό με τις υλοποιήσεις της Microsoft για κάθε τύπο υπηρεσίας. Παρότι ο Windows Server 2008 R2 παρέχει μια
    ξιόπιστη πλατφόρμα cloud, με την έλευση
    του Windows Server 8 παρέχονται πολλαπλές βελτιώσεις για τις οποίες
    η Microsoft πιστεύει ότι
    θα την καθιερώσουν ως μια premier
    cloud platform.
  8. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι της κοινότητας σε αυτό το δεύτερο μέρος της σειράς άρθρων τα οποία αναφέρονται στο Hyper-V Cloud Computing των Windows 8 θα αναφερθούμε στον Hyper-V ο οποίος τρέχει στον Windows 8 client.

     


    Hyper-V στον Windows 8 Client
    Στον Windows 8 client, η Microsoft
    καθιστά διαθέσιμη την Hyper-V virtualization engine με τα ίδια core
    feature τα οποία υπάρχουν στον Windows Server 8, σε συνδυασμό με όλη εκείνη την επιπλέον λειτουργικότητα η οποία είναι απαραίτητη για να λειτουργεί σε mobile platform. 

    Τα προαπαιτούμενα για να τρέχουμε τον Hyper-V στον Windows 8 client είναι να έχουμε μια 64-bit processor platform με δυνατότητα hardware virtualization καθώς επίσης η πλατφόρμα αυτή να υποστηρίζει το Second Level
    Address Translation (SLAT). Όπως γίνεται άμεσα αντιληπτό εξαιρώντας το χαρακτηστικό του SLAT, τα προαπαιτούμενα είναι ακριβώς τα ίδια με αυτά τα οποία χρειάζονται για να τρέχει ο Hyper-V στον Windows
    Server 8. Η διαφορά είναι ότι ο Hyper-V τρέχει στον Windows 8 client μόνον όταν υπάρχει υποστήριξη του SLAT, εν αντιθέσι όταν τρέχει στον Windows Server 8 δεν απαιτείται το SLAT, αλλά υπάρχει βελτίωση στην απόδοση εφόσον αυτό το χαρακτηριστικό αυτό υπάρχει. Η υποστήριξη του χαρακτηριστικού SLAT κρίθηκε απαραίτητη για τον Hyper-V στον Windows 8 client για να διασφαλίσει την απόδοση των virtual machines (VM) σε μη βέλτιστες hardware platforms. Για παράδειγμα,
    το SLAT βοηθά να προλαμβάνεται το jitter στις virtual machines οι οποίες φιλοξενούν host
    graphic-intensive applications χωρίς hardware GPU, καθώς επίσης αυξάνει την απόδοση εφαρμογών (applications) οι οποίες είναι highly memory intensive.

    Hyper-V Core Features στον Windows 8 Client 
    Η φιλοσοφία της Microsoft
    στην εφαρμογή του Hyper-V στον Windows 8 client είναι να διασφαλίζεται το virtual
    machine compatibility με τον Windows Server 8. Αυτό αποτελεί σημαντικό χαρακτηριστικό όταν αναφερόμαστε σε σενάρια τα οποία απαιτούν η ανάπτυξη και η δοκιμή των VMs να λαμβάνει χώρα σε περιβάλλον Windows 8 client και εν συνεχεία να εξάγονται σε περιβάλλον Windows Server 8 το οποίο είναι και το παραγωγικό περιβάλλον. Στον πίνακα 1 παρουσιάζεται με λίστα σύγκρισης των core Hyper-V
    χαρακτηριστικών μεταξύ του  Windows 8 client και των Windows Server 8.




    Hyper-V Features

    Windows 8 Client

    Windows Server 8

    Running VMs

    1024 (Max)

    1024 (Max)

    Guest VM Memory

    512 GB (Max)

    512 GB (Max)

    Guest Virtual Processors

    32 per VM (Max)

    32 per VM (Max)

    Guest NUMA

    Y

    Y

    Guest VMs

    32 and 64-bit

    32 and 64-bit

    Dynamic Memory

    Y

    Y

    VHD and VHDX

    Y

    Y

    Guest VM Fibre Channel NIC

    Y

    Y

    Extensible Switch

    Y

    Y

    Wireless NIC

    Y

    Y

    Snapshots

    Y

    Y

    PowerShell

    Y

    Y

    Live Storage Migration

    Y

    Y

    VM Connection

    VM Console or RDP

    VM Console or RDP

    Sleep and Hibernate

    Y

    N

    Πίνακας 1: Σύγκριση χαρακτηριστικών Hyper-V μεταξύ του Windows 8 client και των Windows Server 8

    Memory, Virtual Processors, και NUMA Support
    Ο αριθμός των υποστηριζόμενων VMs ανέρχεται στις 1024 και συνδυαζόμενος με την δυνατότητα ανάθεσης εως και 512 GB
    μνήμης RAM και ως 32 virtual processors σε κάθε VM αντιλαμβάνεται κανείς ότι οι δυνατότητες είναι απεριόριστες. Επιπροσθέτως ο Guest virtual machine
    processor και το memory affinity μαζί με τα physical host resources επίσης υποστηρίζονται σε περιβάλλοντα non-uniform memory access (NUMA) architecture platform. 

    Ο Hyper-V στον Windows 8 client επίσης υποστηρίζει το χαρακτηριστικό dynamic memory και το οποίο βοηθά νε βελτιστοποιεί τον αριθμό των virtual machines οι οποίες μπορούν να τρέχουν ταυτόχρονα (execute
    concurrently), καθώς επίσης επιτρέπει τον hypervisor να πραγματοποιεί on-the-fly
    adjustments στην virtual machine memory βασιζόμενος στα πραγματικά φορτία επεξεργασίας (actual workload
    requirements).  

    Υποστήριξη Guest
    Ένα πολύ επιθυμητό χαρακτηριστικό της κοινότητας, το οποίο έλειπε από την τρέχουσα Microsoft virtualization client technology, Windows Virtual
    PC, είναι η υποστήριξη 64-bit guest VM. Στον Windows 8 client, ο Hyper-V υποστηρίζει τόσο 32-bit όσο και 64-bit VMs, ενισχύοντας την αξία του ως εργαλείο-πλατφόρμα ανάπτυξης και δοκιμών καθώς επίσης και την επέκταση της δυνατότητας παρέχοντας μια καλύτερη application compatibility platform. Επίσης υπάρχει η δυνατότητα μεταφοράς (migrate) VMs από τα Windows Virtual PC στον Hyper-V και τον Windows 8 client, κάτι το οποίο απαιτεί την απεγκατάσταση των Integration Components πριν από την μετακίνηση των VMs. 

    Υποστήριξη Virtual Disk Format
    Ο Hyper-V στον Windows client 8
    υποστηρίζει τόσο το standard VHD format για τα virtual hard disks (VHD) όσο και το καινούριο VHDX format. Το νέο VHDX format υποστηρίζει VHDs εως και τα 16
    TB σε μέγεθος, και ταυτοχρόνως ενεργοποιεί την υποστήριξη large sector, και επιτρέπει την ενσωμάτωση user-defined metadata σε ένα αρχείο VHD. Αν και ακόμη υποστηρίζονται οι pass-through disks, η χρήση των VHDX εξαφανίζει την ανάγκη για την χρήση των pass-through disks
    για να ικανοποιηθεί η ανάγκη για large virtual disk storage. 

    Υποστήριξη
     Fibre Channel Adapter
    Ένα καινούριο χαρακτηριστικό είναι η υποστήριξη
    virtual Fibre Channel HBA adapter για χρήση από τις virtual machines. Αυτό το συγκεκριμένο χαρακτηριστικό είναι ιδιαιτέρως χρήσιμο για σενάρια όπως guest clustering, χρήσ του MPIO, καθώς και άλλων λύσεων multipathing απαραίτητες για φόρτο εργασίας (workloads) ο οποίος απαιτεί high-performing SAN
    και application availability. Αυτό το χαρακτηριστικό είναι διαθέσιμο για Windows
    virtual machines οι οποίες τρέχουν τα Windows Server 2008 R2 καθώς επίσης και όλες τις εκδόσεις των Windows
    Server 8.


    Υποστήριξη
    Switch Extensibility
    Στον Windows 8 client, υπάρχει ένα καινούριου API το οποίο επιτρέπει την ανάπτυξη switch extensions τα οποία βελτιώνουν δραματικά το out-of-box Hyper-V functionality. Η βασική λειτουργικότητα του
    Hyper-V switch επιτρέπει την δημιουργία external,
    internal, και private virtual networks, σε συνδυασμό με VLAN configuration.
    Με το καινούριο, οι κατασκευαστές hardware μπορούν να προσφέρουν pluggable switch modules τα οποία παρέχουν επιπρόσθετη ασφάλεια δικτύου, διαχείρση και χαρακτηριστικά monitoring. Είναι δε χαρακτηριστικό να αναφέρουμε ότι η ίδια έκδοση των switch extensions υποστηρίζει τόσο τον Windows
    Server 8 όσο και τον Windows 8 client. Ένα τέτοιο παράδειγμα αποτελεί το Cisco Systems Nexus 1000V για το οποίο προσφάτως ανακοινώθηκε η υποστήριξη για τον Hyper-V στα Windows 8.


    Υποστήριξη
    NIC
    Ένα πολύ σημαντικό και εξόχως απαραίτητο χαρακτηριστικό στον Hyper-V στα Windows 8 client εγκατεστημένος σε ένα notebook ή laptop είναι η υποστήριξη των wireless Network Interface Cards (NICs). Το χαρακτηριστικό για να υλοποιηθεί απαίτησε την αλλαγή του virtual switch architecture έτσι ώστε να επιτρέπει το routing πολλαπλών MAC
    addresses (μία ή περισσότερες μοναδικές MAC addresses για κάθε VM, εξαρτώνται από τον αριθμό των virtual NICs οι οποίες είναι συνδεδεμένες σε μια VM) διαμέσου μίας μοναδικής φυσικής wireless NIC για ενός external network connectivity. Στις προγενέστερες εκδόσεις του Hyper-V (π.χ., Windows Server 2008 και Windows Server 2008 R2 Hyper-V),
    μόνον ενσύρματες (wired) NICs ήταν υποστηριζόμενες διότι το πολλαπλό MAC address routing προς
    external networks επιτυγχάνεται τοποθετώντας τις ενσύρματες NIC σε promiscuous
    mode, μια λειτουργία η οποία δεν υποστηρίζεται από τα wireless NICs.

    Στα Windows 8 ο Hyper-V υλοποιεί την λύση Microsoft Bridging διαμέσου του ARP proxy (για το IPv4) και του Neighbor Discovery proxy (για το IPv6) και αντικαθιστά τα virtual NIC MAC address με MAC address από τα wireless NIC για εκείνα τα πακέτα τα οποία έχουν external network destination.
    Χρησιμοποιώντας δε τον internal mapping table για να πιστοποιεί ότι μία virtual NIC IP address σε μία virtual NIC MAC address, διασφαλίζεται ότι το σωστό routing για τα external packets προς/από την ενδεδειγμένη virtual NIC.

    Η λύση αυτή απαιτεί ότι θα πρέπει να υπάρχει μια γέφυρα μεταξύ ενός external
    virtual switch το οποίο είναι συνδεδεμένο σε μία φυσική wireless NIC. Συνεπώς ο Hyper-V
    πρώτα δημιουργεί μια γέφυρα και ενσυνεχεία την συνδέει με την φυσική wireless NIC. Τέλος, δημιουργεί το external virtual switch, και το συν΄δει με την γέφυρα (binds it to the
    bridge), αντί να το συνδέσει απευθείας στην φυσική wireless NIC.


    Υποστήριξη
    Snapshot
    Με το χαρακτηριστικό του snapshot, ο Hyper-V επιτρέπει "φωτογράφιση" σε μια δεδομένη χρονική στιγμή το configuration και το state μιας virtual machine, παρέχοντας την δυνατότητα επανφόρτωσης (reload) ενός υπάρχοντος snapshot σε ελάχοστα δευτερόλεπτα. Αυτό το χαρακτηριστικό είναι ιδιαιτέρως χρήσιμο για την δημιουργία περιβαλλόντων για δοκιμές έτσι να παραγματοποιούνται οι απαραίτητες δοκιμές και το debugging για την διόρθωση πιθανών λογικών λαθών πριν αυτά εφαρμοστούν σε περιβάλλοντα παραγωγής.

    Όταν ένα snapshot δημιουργείται, όλα τα λειτουργικά συστήματα, οι εφαρμογές,
    καθώς επίσης και οι αλλαγές στα δεδομένα οι οποίες λαμβάνουν χώρα κατά την διάρκεια εκτέλεσης των virtual machines αποθηκεύονται σε differencing disks. Για κάθε snapshot το οποίο δημιουργείται, ένα καινούριο differencing disk (ή πολλαπλά differencing disks εάν πολλαπλά VHDs είναι συνδεδεμένα με την συγκεκριμένη VM) φωτογραφίζει τις αλλαγές της συγκεκριμένης virtual machine. Τα differencing disks τα οποία δημιουργούνται για κάθε snapshot σε μια λογική γονέα-παιδιού -(parent and child hierarchy)- με τα πρωτότυπα VHDs να αποτελούντα top-level nodes.

    Επιπροσθέτως μεμονομένα snapshots ή ολόκληρα snapshot hierarchies μπορούν να διαγραφούν ή να ενωθούν εφόσον αυτό απαιτείταιΣτην πραγματικότητα ο Hyper-V στον Windows 8 client βελτιστοποιεί την λειτουργικότητα παλαιοτέρων snapshot διαμέσου ασύγχρονης ενοποίησης των snapshots, και αυτόματης απελευθέρωσης του αποθηκευτικού χώρου (automatic reclamation of storage).


    Υποστήριξη
    PowerShell
    Το PowerShell μας επιτρέπει να αυτοματοποιήσουμε την δημιουργία, ανάπτυξη και την διαχείριση των VMs. Με την προσθήκη 150 νέων cmdlets, μπορούμε να αυτοματοποιήσουμε όλες τις λειτουργίες οι οποίες είναι διαθέσιμες και στο Hyper-V
    Manager Graphical User Interface (GUI). Το PowerShell υποστηρίζει την απευθείας διαχείριση των VMs σε έναν local host, όπως επίσης και την διαχείριση των VMs σε
    remote hosts.


    Υποστήριξη
    Live Storage Migration
    Ο Hyper-V στον Windows 8 client
    επίσης παρέχει το χαρακτηριστικό του Live Storage Migration για την μετακίνηση των virtual machine storage
    resources μεταξύ physical storage units χωρίς διακοπή των VM services. Αυτό το χαρακτηριστικό επιτρέπει οι VMs να είναι ανεξάρτητες από τους υφιστάμενους αποθηκευτικούς χώρους καθώς επίσης υποστηρίζονται directly-attached physical storage, removable
    storage όπως USB flash drives, SANs, και τέλος άλλα remote file shares.

    Κατά την διάρκεια ενός Live Storage Migration, μπορούμε να επιλέξουμε να μετακινήσουμε μέρος ή όλα τα VM files:


    VHD files
    Configuration files
    Snapshot files
    Second level paging files
    Επιπροσθέτως, μπορούμε να καθορίσουμε συγκεκριμένες τοποθεσίες για κάθε επιλεγμένο machine file, ή να μετακινησουμε όλα τα αρχεία σε μια μοναδική τοποθεσία. Στο σημείο αυτό θα πρέπει να σημειώσουμε ότι το VM Live Migration (running state without service
    interruption) προς το παρόν δεν υποστηρίζεται στον Windows 8 client.


    Υποστήριξη
    VM Connection
    Υπάρχουν δύο επιλογές για να συνδεθούμε στις VMs
    οι οποίες τρέχουν στον Windows 8 client: το VMConnect και το RDP client. Το VMConnect είναι μια εφαρμογή  η οποία χρησιμοποιείται για να συνδεθούμε σε μια VM μέσα από τον Hyper-V Manager. Μας επιτρέπει δε να συνδεθούμε σε μια εκκινούμενη VM στο boot phase, και παρέχει δυνατότητες διαχείρισης διαμέσου ενός single monitor με 32-bit color και ανάλυση εως και 1600x1200.

    Ο Windows 8 RDP client επιτρέπει την σύνδεση σε μια booted VM, παρέχοντας μια πιο πλούσια εμπειρία χαρακτηριστικών.Για παράδειγμα χρησιμοποιώντας μια σύνδεση RDP client από έναν φυσικό υπολογιστή με πολλαπλές οθόνες μας επιτρέπετε η εμφάνιση της μιας VM σε όλες τις συνδεδεμένες οθόνες. Τέλος διαμέσου του RDP, μια VM έχει το πλεονέκτημα ότι μπορεί να χρησιμοποιήσει ένα multipoint touch interface, καθώς επίσης και άλλων περιφερειακών όπως ηχεία, και την απευθείας σύνδεση σε USB devices.


    Υποστήριξη
    Sleep and Hibernation
    Τρέχοντας στον Windows 8 client,
    ο Hyper-V υποστηρίζει τα χαρακτηριστικά του sleep και του hibernation. Εφόσον ένα φυσικό σύστημα τοποθετηθεί σε κατάσταση sleep ή hibernation, τότε αυτομάτως γίνεται παύση των VMs και το state
    information (memory και register state) αποθηκεύονται σε αρχεία. Όταν το σύστημα επανέλθει, τότε στις VMs επαναπροωθούνται τα processor και memory resources, καθώς επίσης και το state information τους επανέρχεται από το αρχείο το οποίο δημιουργήθηκε για τον λόγο του "resume
    execution".

    Ενεργοποίηση του Hyper-V στον Windows 8 Client
    Όπως ανέφερα και προηγουμένως,
    μπορούμε να ενεργοποιήσουμε τον Hyper-V σε έναν Windows 8 client ο οποίος τρέχει σε ένα φυσικό σύστημα 64-bit το οποίο υποστηρίζει SLAT. Για να διαπιστώσουμε έαν το συστήμά μας υποστηρίζει το χαρακτηριστικό SLAT, μπορούμε να κάνουμε download
    και να τρέξουμε ένα free tool, το οποίο ονομάζεται Coreinfo, από το Microsoft site. Το Coreinfo αναπτύχθηκε από τον Mark Russinovich, ο οποίος μέχρι πρόσφατα μέλος του Sysinternals fame, ο οποίος τώρα αποτελέι μέλος της οικογένειας της Microsoft και συγκεκριμένα στο Windows Azure team.

    Καθορίζοντας το System Compatibility
    Για να τρέξουμε το Coreinfo
    tool, ανοίγουμε ένα command window τρέχοντας με Administrator context,
    κάνουμε αλλαγή directory στον φάκελο όπου έχουμε αποθηκεύσει το συγκεκριμένο εργαλείο. εφόσον είμαστε στο κατάλληλο directory, πληκτρολογούμε τα ακόλουθα:

    Coreinfo –v

    Χρησιμοποιώντας το –v switch, το Coreinfo θα επιστρέψει εκείνη την πληροφορία η οποία αναφέρεται στα virtualization σχετιζόμενα χαρακτηριστικά του συστήματός μας, περιλαμβάνοντας και την πληροφορία εάν υποστηρίζεται ή όχι το SLAT (Εικόνα 1.)


    Εικόνα 1: Virtualization Support Information για το Coreinfo Tool

    Το Coreinfo μπορεί επίσης να παρέχει πληροφορία για τα system sockets, cores, core features, caches, NUMA nodes, και τα οποία τα ομαδοποιεί χρησιμοποιώντας διαφορετικά switch options στο command line. Μπορείτς να δείτε όλα τα switch options πληκτρολογώντας Coreinfo /?  στο command line.

    Hyper-V Configuration
    Ο Hyper-V ενεργοποιείται στον Windows 8 client
    χρησιμοποιώντας το Windows Features applet στο Control Panel. Εφαρμόστε την παρακάτω διαδικασία για να ενεργοποιήσετε τον Hyper-V στον Windows 8 client:


    Από την Start page, επιλέγουμε το Control Panel tile (Εικόνα 2).


    Εικόνα 2: Windows 8 Client Start Page



    Στο Control Panel, επιλέγουμε το More Settings option (Εικόνα 3).

    Εικόνα 3: Windows 8 Client Control Panel Page



    Στο Control Panel window, επιλέγουμε το Programs (Εικόνα 4).


    Εικόνα 4: Windows 8 Client Control Panel Window



    Στο Programs window, επιλέγουμε το Turn Windows Features On or Off option (Εικόνα 5).


    Εικόνα 5: Windows 8 Client Programs Window



    Στο Windows Features dialog, κάνουμε ξετύλιγμα (Expand) και επιλέγουμε το Hyper-V node, και εν συνεχεία κάνουμε κλικ στο OK (Εικόνα 6).


    Εικόνα 6: Windows 8 Client Windows Features Dialog



    Αμέσως μετά την ολοκλήρωση της εγκατάστασης του Hyper-V, κάνουμε κλικ στο Restart Now μέσα από το status window (Εικόνα 7).


    Εικόνα 7: Windows 8 Client Hyper-V Installation Status



    Μόλις ο Windows 8 client ολοκληρώσει την επανεκίννηση, ο Hyper-V
    hypervisor είναι ενεργοποιημένος, και το the Hyper-V Manager tile εμφανίζεται στο Start
    page (Εικόνα 8).


    Εικόνα 8: Windows 8 Client Start Page με τον Hyper-V Manager

    Συμπέρασμα

    Σε αυτό το άρθρο ενημερωθήκαμε για τα physical system requirements που προαπαιτούνται για τρέξει ο Hyper-V στον windows 8 client, καθώς επίσης και τα core χαρακτηριστικά τα οποία η Microsoft παρέχει έτσι ώστε να εξασφαλίζεται η συμβατότητα όταν τρέχει ο Hyper-V στον Windows Server 8. Τέλος χρησιμοποιώντας το ελεύθερο Microsoft Coreinfo tool, μπορείται εύκολα να πληροφοροθείτε έαν ο 64-bit υπολογιστής σα υποστηρίζει το χαρακτηριστικό SLAT το οποίο είναι απαραίτητο για τον Hyper-V σε περιβάλλον Windows 8 client. Ελπίζω ότι θα σας φανεί ιδιαιτέρως χρήσιμο.


     
  9. Jordan_Tsafaridis
    Οι δημιουργοί του Stuxnet επέστρεψαν με ένα καινούριο είδος malware, το οποίο μπορεί να είναι ο προάγγελος ενός Stuxnet-like attack.
     
    Παρακάτω σας παραθέτω αυτούσιο στην Αγγλική γλώσσα το άρθρο του Tom Brewster, το οποίο δημοσιεύθηκε στις 19 Οκτωβρίου 2011 στις 14:42 στην ιστοσελίδα www.itpro.co.uk.



    The team behind the most sophisticated piece of malware ever seen has returned with some fresh malicious software.

    Stuxnet
    creators have used much of the same code for their new creation, known
    as Duqu, which has grabbed the attention of security researchers after
    an unnamed independent team detected it.

    However, Duqu is not as sophisticated as Stuxnet and is not targeting the same SCADA systems used in power plants.


    The attackers are looking for information such as
    design documents that could help them mount a future attack on an
    industrial control facility.

    Instead, Duqu has been used to acquire information in the lead-up to
    another Stuxnet-esque attack in the future, researchers have suggested.

    A small number of organisations have been hit, including some in the manufacturing of industrial control systems.

    “The attackers are looking for information such as design documents
    that could help them mount a future attack on an industrial control
    facility,” a blog post from Symantec read.

    “Our telemetry shows the threat was highly targeted toward a limited
    number of organisations for their specific assets. However, it’s
    possible that other attacks are being conducted against other
    organisations in a similar manner with currently undetected variants.”

    Attacks using Duqu could stretch back as far as December 2010. The
    malware has been used to download a separate information stealer onto
    systems. That info-stealer was able to pilfer data in a variety of ways,
    including keystroke logging, before sending it off to a command and
    control centre in India inside an encrypted file.

    The malware was programmed to run for 36 days before removing itself from systems.

    Stuxnet similarities

    Security researchers across the board have been fairly certain Duqu
    was created by the same team behind Stuxnet, even though there is no
    direct proof.

    “They had to have access to the original source code, which only the
    creators of Stuxnet have. There are various decompilations available
    online. Those would not do,” Mikko Hypponen, chief research officer at
    F-Secure, told IT Pro.

    “It's perfectly possible they [the team behind Stuxnet] did a similar
    information-cathering phase in 2008 or 2009 for the original Stuxnet
    and we just missed it.”

    Aside from the code similarities, Duqu's driver files are signed with
    certificates apparently stolen from a Taiwanese company, as were
    Stuxnet’s.

    Certificates were stolen from RealTek and JMicron in the case of
    Stuxnet, whereas in Duqu only one was compromised - C-Media Electronics
    Incorporation.

    In recent cases, certificate authorities have been compromised so
    hackers could issue fraudulent certificates, as was seen with the now-defunct CA DigiNotar.
    However, the certificate used to sign Duqu appears to have been stolen
    somehow, even though McAfee’s analysis suggested otherwise.

    “Symantec has known that some of the malware files associated with
    the W32.Duqu threat were signed with private keys associated with a code
    signing certificate issued to a Symantec customer,” the security giant
    said today.

    “Symantec revoked the customer certificate in question on 14 October
    2011. Our investigation into the key’s usage leads us to the conclusion
    that the private key used for signing Duqu was stolen, and not
    fraudulently generated for the purpose of this malware.”

    McAfee said Duqu was being used in areas occupied by “Canis Aureus,”
    the Golden Jackal. See below for a map outlining where these areas are:

    (Source: Wikipedia)
    Ελπίζω ότι θα το βρείτε εξαιρετικά ενδιαφέρον.
  10. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι της κοινότητας είναι γεγονός ότι ένα επιπλέον κόστος σε εγκαταστάσεις του Microsoft Exchange 2010, αποτελεί συχνά η χρήση ενός hardware
    load balancer, ή και αρκετές φορές επίσης η χρήση ενός virtual load balancer appliance. Είναι χαρακτηριστικό ότι οι φθηνές λύσεις ξεκινούν λίγο πάνω από τα 1000 Ευρώ και φθάνοντας σε κόστος αρκετών χιλιάδων Ευρώ. Αυτό το οποίο δεν γνωρίζουν πολλοί είναι ότι υπάρχει και αντίστοιχο open source software το οποίο μπορεί να κάνει την συγκεκριμένη εργασία εξίσου καλά, και το κυριότερο ΔΩΡΕΑΝ. 

    Το ευχάριστο είναι ότι η συγκεκριμένη λύση παρέχει ένα απλό στην χρήση web-based
    management interface, το οποίο επιτρέπει ένα εύκολο setup σε συνδυασμό με την δυνατότητα να χρησιμοποιήσουμε αυτό το Virtual Load Balancer appliance τόσο σε περιβάλλον VMware vSphere όσο και σε περιβάλλον Hyper-V.

    Η έκδοση 0.1 η οποία παρουσιάζεται στα παρακάτω screenshot αποτελεί την πρώτη έκδοση, και συνεπώς όπως αντιλαμβάνεστε δεν θα συνιστούσα να την χρησιμοποιήσετε σε ένα παραγωγικό περιβάλλον. Αυτό το οποίο μπορώ να σας διαβεβαιώσω ότι ύστερα από επικοινωνία την οποία είχα με τον επικεφαλής της ομάδας ανάπτυξης του συγκεκριμένου λογισμικού Load Balancer,
    σε ένα χρονικό διάστημα δύο - τριών μηνών το λογισμικό θα είναι rock-solid σε συνδυασμό με την προσθήκη ορισμένω επιπλέον απαραίτητων χαρακτηριστικών τα οποία αυτή την στιγμή βρίσκονται ήδη στην διαδικασία του debugging για περισσότερο από ένα μήνα. Τα Screenshots είναι τα ακόλουθα :









    Μπορείται να διαβάσετε περισσότερα αλλά και να κατεβάσετε το λογισμικό κάνοντας κλικ εδώ.
    Ολοκληρώνοντας πιστεύω ότι θα πρέπει να λάβετε υπόψην σας και τον παρακάτω σύνδεσμο.

    http://www.stevieg.org/2010/11/exchange-team-no-longer-recommend-windows-nlb-for-client-access-server-load-balancing/

    Ελπίζω ότι το συγκεκριμένο άρθρο θα το βρείτε εξαιρετικά χρήσιμο.
  11. Jordan_Tsafaridis
    Η Microsoft ανακοίνωσε την
    εξάρθρωση του δικτύου Kelihos, ενός botnet που εκτιμάται ότι αποστέλλει
    καθημερινά 4 εκατομμύρια spam email. Η εταιρεία έχει ήδη καταθέσει τις
    σχετικές μηνύσεις και το λόγο έχει τώρα η αμερικανική δικαιοσύνη.
     
    Οι
    κατηγορούμενοι είχαν δημιουργήσει περίπου 3.700 subdomains μέσω της
    υπηρεσίας cz.cc, πολλά από τα οποία χρησιμοποιούνταν για παράνομες
    δραστηριότητες. Εκτιμάται ότι περίπου 41.000 υπολογιστές σε όλο τον
    κόσμο είχαν μολυνθεί και συμμετείχαν στις δραστηριότητες του botnet.
     
    Σύμφωνα
    με τη Microsoft, το Kelihos botnet έχει χρησιμοποιηθεί για την υποκλοπή
    προσωπικών δεδομένων και άλλες παράνομες δραστηριότητες, πέρα από την
    αποστολή spam email.
     

    Το Kelihos είναι επίσης γνωστό με το όνομα
    Waledac 2.0. Να σημειωθεί ότι η πρώτη έκδοση του Waledac έχει επίσης
    εξαρθρωθεί από τη Microsoft, η οποία πιστώνεται επίσης και τη διάλυση
    του διαβόητου Rustock botnet.
     
    Πηγή : www.defencenet.gr

  12. Jordan_Tsafaridis
    Εισαγωγή

    Ένα από τα νέα χαρακτηριστικά του TMG, το οποίο μάλιστα ήταν εδώ και καιρό απαίτηση των administrator προς την ομάδα ανάπτυξης του TMG, είναι η δυνατότητα υποστήριξης πολλαπλών εξωτερικών δικτυακών συνδέσεων. Η λειτουργία αυτή ονομάζεται σύμφωνα με την διεθνή ορολογία ISP Redundancy (ISP-R), η οποία αποτελεί πλέον αναπόσπαστο κομμάτι του TMG 2010. Ο σκοπός του άρθρου αυτού είναι να διερευνήσουμε τις δυνατότητες τις οποίες μα παρέχει αυτή η υπηρεσία του TMG 2010, σε επίπεδο operating modes, εξήγηση του αλγορίθμου load balancing, και τέλος το Dead link process. συνεπώς με την δυνατότητα υποστήριξης δύο μοναδικών και ανεξάρτητων συνδέσεων σε δύο διαφορετικούς ISP's, μπορούμε πλέον να έχουμε fault tolerance και redundancy μεταξύ των Internet ή των WAN συνδέσεων, τις οποίες έχουμε σε χρήση.
     

    Operating Modes

    Η λειτουργία ISP-R στον TMG έχει δύο operating modes – Load Balancing και
    Failover. Στο Load Balancing mode, οι συνδέσεις εξυπηρετούνται
    (balanced) μεταξύ δύο εξωτερικών δικτύων evenly (by default) ή unevenly
    (configurable by the administrator). Εάν κάποια από τις εξωτερικές συνδέσεις καταστεί μη διαθέσιμη τότε όλη η επικοινωνία δρομολογείται από την σύνδεση εκείνη η οποία είναι ενεργή. Στο Failover mode, το ένα από τα δύο εξωτερικά δίκτυα ρυθμίζεται ως primary connection, και το δεύτερο εξωτερικό δίκτυο ως secondary
    connection. Όλες οι υπηρεσίες επικοινωνίας δρομολογούνται από το primary connection. Εάν το primary connection καταστεί μη διαθέσιμο, τότε όλες οι υπηρεσίες επικοινωνίας δρομολογούνται από το secondary connection. Όταν το primary connection καταστεί διαθέσιμο και πάλι, τότε όλες οι υπηρεσίες επικοινωνίας δρομολογούνται ξανά από το primary connection.

    Προετοιμάζοντας τα Network Interfaces

    Το ISP-R υποστηρίζει μόνον δύο συνδέσεις εξωτερικών δικτύων (external network connections), και κάθε σύνδεση θα πρέπει να βρίσκεται σε ένα και μοναδικό subnet. Για την σωστή λειτουργία και την βέλτιστη απόδοση του συστήματος, είναι απαραίτητο και τα δύο external network interfaces νε ρυθμιστούν ταυτόσημα (identically - δώστε ιδιαίτερη προσοχή στο NIC driver
    offload settings). Το ιδανικό θα είναι οι δύο network interface cards να είναι του ιδίου κατασκευαστή και τύπου.

    Ξεκινώντας θα πρέπει να δώσουμε σε κάθε network interface ένα χαρακτηριστικό όνομα (π.χ.
    External_Otenet and External_Vodafone). Εν συνεχεία ρυθμίζουμε το πρώτο fexternal
    network interface με IP address, subnet mask, και default gateway. Εάν ο TMG firewallδεν είναι μέλος ενός domain και δεν επικοινωνεί με κανένα εσωτερικό δίκτυο τότε μπορούμε να χρησιμοποιήσουμε τους ISP’s DNS servers. Ωστόσο, εάν ο TMG firewall είναι domain member, μην χρησιμοποιήσετε εδώ τους ISP DNS servers (Οι Internal DNS servers χρησιμοποιούνται μόνον στο internal network interface). Μόλις ολοκληρώσουμε τις ρυθμίσεις, κάνουμε κλικ στο Advanced…
    button.


    Figure 1

    Uncheck το κουτί με τίτλο Automatic metric, και στην συέχεια εισάγεται την τιμή 1στο κουτί  Interface metric.


    Figure 2

    Επαναλαμβάνουμε την ίδια διαδικασία και για το δεύτερο external network
    interface, χρησιμοποιώντας τώρα Interface metric: με τιμή 2. Θα πρέπει να βεβαιωθείταιότι έχετε όρίσει default gateway στο δεύτερο external
    interface. Μιλώντας σε ενιαία βάση αυτό κανονικά δεν συνιστάται, με συνέπεια τα Windows να παραπονεθούν όταν επιχειρήσετε να το ενεργοποιήσετε.


    Figure 3

    Σε αυτό το σενάριο είναι απολύτως ασφαλές να αγνοήσουμε την προεοδοποίηση και επιλέγουμε Yes για να συνεχίσουμε.

    Σημείωση :
    Εάν οι ISPs που είστε συνδεδεμένοι χρησιμοποιούν DHCP για να αναθέτουν IP addresses, τότε δεν έχετε την δυαντότητα να χρησιμοποιήτε multiple default gateways. Στην περίπτωση αυτή είμαστε υποχρεωμένοι να εισαγάγουμε default persistent static routes πριν από την ρύθμιση των ISP-R. Στο συγκεκριμένο παράδειγμα, τα routes θα πρέπει να ρυθμιστούν όπως περιγράφεται παρακάτω :

    route add –p 0.0.0.0 mask 0.0.0.0 131.107.54.46

    route add –p 0.0.0.0 mask 0.0.0.0 207.213.91.214

    Ρυθμίσεις του ISP Redundancy

    Μόλις το αρχικό network interface configuration ολοκληρωθεί , ανοίγουμε την TMG management console και στο console tree επιλέγουμε Networking,και εν συνεχεία επιλέγουμε το  ISP Redundancy tab.


    Figure 4

    Στο Tasks pane, κάνουμε κλικ στο Configure ISP Redundancy.


    Figure 5

    Επιλέγουμε Next, και ενσυνεχεία επιλέγουμε το ISP redundancy mode που εξυπηρετεί τις απαιτήσεις μας. Στην συγκεκριμένη περίπτωση θα επιλέξουμε το default
    option Load balancing with failover capability.


    Figure 6

    Καθορίζουμε το ISP connection name:, και εν συνεχεία επιλέγουμε το network
    adapter από το drop-down list.


    Figure 7

    Γίνεται έλεγχος, έτσι ώστε να επιβεβαιώσουμε ότι το gateway address και το subnet mask είναι τα σωστά. Εάν ο
    TMG firewall δεν αποτελεί μέλος ενός domain και δεν επικοινωνεί με κανένα internal network κάνοντας χρήση ονομάτων (By name), τότε μπορούμε να ορίσουμε τους ISP’s DNS
    servers εδώ. Εάν ο TMG firewall είναι μέλος domain, τοτε δεν καθορίζουμε εδώ τους
    ISP DNS servers (Οι εσωτερικοί DNS servers ρυθμίζονται μόνον στο
    internal network interface).


    Figure 8

    Σε ορισμένες περιπτώσεις κάποιοι external servers μπορούν να έχουν επικοινωνία μόνον διαμέσου ένός συγκεκριμένου external link. Ένα τέτοιο παράδειγμα μπορεί να είναι ο  ISP DNS
    server ή ένας mail server. Eάν απαιτείται θα πρέπει να εισαγάγουμε αυτούς τους servers εδώ. Έτσι λοιπόν σε αυτό το σημείο έχουμε την δυαντότητα να καθορίσουμε συγκεκριμένους computers, computer sets, ή address
    ranges.


    Figure 9

    Επαναλαμβάνουμε την ίδια διαδικασία και για το δεύτερο external network connection,και στην συνέχεια επιλέγουμε το  distribution percentage μετακινώντας το slider στην επιθυμητή θέση. Εφόσον και τα δύο external links έχουν το ίδιο bandwidth,τότε μπορείτε με ασφάλεια να αφήσετε την ρύθμιση στο 50%. Στην αντίθετη περίπτωση κατά την οποία το bandwidth του ενός link είναι μελύτερο από το άλλο, τότε ηρύθμισετε γίνεται έτσι ώστε το συγκεκριμένο link να δέχεται μεγαλύτερο ποσοστό
    traffic.


    Figure 10

    Επιλέγουμε Finish για να ολοκληρωθεί η διαδικασία ISP-R configuration.


    Figure 11

    Εάν έχουμε ρυθμίσει DNS servers στα external network
    interfaces, τότε θα πρέπει να βεβαιωθούμε ότι έχουμε δημιουργήσει τα αντίστοιχα persistent static routes έτσι ώστε να εξασφαλίσουμε ότι τα requests για τα συγκεκριμένα resources δρομολογούνται (routed) από το σωστό
    network interface.


    Figure 12

    Στο παράδειγμά μας, τα routes αυτά είναι τα παρακάτω:

    route add -p 131.107.54.200 mask 255.255.255.255 131.107.54.46

    route add -p 207.213.91.214 mask 255.255.255.255 207.213.91.214

    Μόλις τα ρυθμίσουμε, η TMG management console θα εμφανίσει την πληροφορία για κάθε σύνδεση ISP, καθώς και το προεπιλεγμένο
    redundancy mode.


    Figure 13

    Μετά από την ρύθμιση του ISP-R, για να κάνουμε αλλαγές στην ρύθμιση κάποιου συγκεκριμένου
    ISP connection κάνουμε right-click στο connection και επιλέγουμε Properties.


    Figure 14

    Εδώ μπορούμε να λλάξουμε το όνομα της σύνδεσης, να μεταβάλλουμε την πληροφορία IP
    address/subnet mask, να ενεροποιήσουμε ή να απενεροποιήσουμε την συγκεκριμένη σύνδεση, να τροποιήσουμε το load balancing ratio, ή να προσθέσουμε, να αλλάξουμε, ή να διαγράψουμε dedicated
    servers.


    Figure 15

    Αλλαγή του ISP-R Operating Mode

    Στο συγκεκριμένο παράδειγμα έχουμε ρυθμίσει το ISP-R για Load Balancing. Εάν θέλουμε να αλλάξουμε το ISP-R operating mode, κάνουμε κλικ στο Change ISP Redundancy
    Mode to Failover στο Tasks pane.
     


    Figure 16

    Όταν γίνεται αλλαγή από το Load Balancing mode στο Failover
    mode, θα πρέπει να κάνουμε edit στα connection properties και να επιλέξουμε το ενδεδειγμένο connection role για την συγκεκριμένη σύνδεση. Θυμηθείτε, ότι στο Failover
    mode όλο το traffic θα σταλεί διαμέσου του primary external connection και το secondary connection θα χρησιμοποιηθεί τότε και μόνον τότεόταν το primary connection καταστεί μη διαθέσιμο.


    Figure 17

    Monitoring ISP-R

    Για να δούμε το status του κάθε ISP connection, highlight Dashboard στο console tree.


    Figure 18

    Το status του κάθε ISP link θα εμφανιστεί στο Network
    Status frame.


    Figure 19

    Εάν καποιο από τα link καταστεί μη διαθέσιμο, τότε το connection status θα εμφανίσει ένα
    alert.


    Figure 20

    Επιπροσθέτως μπορούμε να παρακολουθήσουμε τα Connections Unavailable alert κάτω από το  Alerts tab.


    Figure 21

    Όταν η σύνδεση είναι και πάλι online, ο TMG θα εμφανίσει ένα informative
    alert ενημερώνοντας ότι η σύνδεσηείναι και πάλι διαθέσιμη.


    Figure 22

    Υπάρχει ένας αριθμός από ISP-R alerts με σκοπό ο TMG firewall
    administrator να είναι πάντοτε ενημερωμένος για το the status και το health των external
    network connections.


    Figure 23

    Load Balancing και Dead Link Detection

    Είναι σημαντικό να αντιληφθούμε ότι το ISP-R διανέμει συνδέσεις, και όχι φορτίο. Ο τρόπος με τον οποίο το ISP-R αποφασίζει σε ποιο από τα external interface θα διανείμει το traffic καθορίζεται από την εκτέλεση ενός hash στην source
    IP address και στην destination IP address. Το αποτέλεσμα είναι ένας αριθμός μεταξύ 0 και 100. Εάν το αποτέλεσμα είναι κάτω από το ποσοστό το οποίο έχει επιλεγεί για το πρώτο ISP connection, τότε οTMG θα χρησιμοποιήσει αυτό το connection. Εάν όχι, τότε ο
    TMG θα χρησιμοποιήσει το άλλο external connection. Αυτό εξασφαλίζει το session
    affinity(Ορολογία - Affinity : all connections for a specific source/destination address
    pair will be delivered through the same external network interface). Το
    hash υπολογίζεται για κάθε εξερχόμενη σύμδεση. (Outgoing Connection)

    Για να καθοριστεί η διαθεσιμότητα ενός συγκεκριμένου ISP connection, ο TMG εκτελεί περιοδικά ένα dead link detection επιλέγοντας τυχαία έναν από τουε δεκατρείς (13) Internet root DNS servers στο TCP port 53 (Εάν ο TMG  έχει εγκατασταθεί ωςback firewall, βεβαιωθείτε ότι το TCP port 53 είναι ανοιχτό στο Internet). Εάν ο επιλεγμένος root DNS server ανταποκριθεί, τότε ο TMG θεωρεί ότι το συγκεκριμένο connection είναι διαθέσιμο. Εάν δεν απαντήσει, τότε TMG θα χρησιμοποιήσει επιπλέον root DNS servers σε χρονικά διαστήματα του ενός λεπτού. Εάν και πάλι δεν ληφθούν απαντήσεις μετά από τρεις συνεχείς προσπάθειες, τότε ο TMG θεωρεί ότι το συγκεκριμένο
    connection είναι μη διαθέσιμο και εμφανίζει ένα alert. Εφόσον ο TMG διαπιστώσει ότι ένα
    connection είναι μη διαθέσιμο, θα περιμένει πέντε λεπτά πριν επιχειρήσει ξανά να διαπιστώσει εάν είναι διαθέσιμο ή όχι. Όταν τελικά λάβει μια απάντηση, τότε ο TMG θα συνεχίσει να ρωτά εάν είναιδιαθέσιμο κάθε ένα λεπτό. Όταν τρεις συνεχόμενες απαντήσεις έχουν ληφθεί, τότε ο TMG θα θεωρήσει ότι το connection είναι και πάλι διαθέσιμο.

    Σενάρια Deployment


    Η επιλογή των ISP-R operating modes επηρεάζεται πρωτίστως από τον τύπο των Internet ή των WAN connections τα οποία έχετε. Για παράδειγμα, εάν έχετε δύο όμοια Ιnternet connections όσον αφορά το bandwidth,το Load
    Balancing mode είναι μια καλή επιλογή. Εάν όμως έχετε ένα high bandwidth
    connection και ένα low bandwidth connection, τότε το Failover mode είναι η σωστή επιλογή. Παρόλα αυτά αν και αυτή η τεχνολογία ονομάζεται ‘ISP’
    redundancy, δεν περιορίζεται μόνον στα Internet-connected links. Το ISP-R μπορεί να χρησιμοποιηθεί για να παρέχει load balancing και failover για WAN links μεταξύ ενός υποκαταστήματος και των κεντρικών γραφείων μιας επιχείρησης.

    Επιπλέον Θέματα


    Θα πρέπει να λάβετε υπόψην σας τα παρακάτω όταν σχεδιάζεται και υλοποιείται μια εγκατάσταση ISP-R :
    Τα παρακάτω είναι στην Αγγλική γλώσσα, προκειμένου να μην αλλοιωθεί το νόημά τους μιας και προέρχονται από το Microsoft Technet.
     

    Works with NAT only – ISP-R will only provide load balancing and failover for traffic originating from TMG protected networks and
    destined for the default External network, and will only work when the
    network relationship is configured as NAT. If the network relationship
    is configured as route, ISP-R will not function. This is
    important because traffic originating from the TMG firewall itself will
    not be processed by ISP-R, as the network relationship between the Local
    Host network and the External network is route.
     

    E-NAT overrides ISP-R – For traffic processed by a network rule configured with Enhanced NAT (E-NAT), E-NAT takes
    precedence and will override any routing decisions made by ISP-R.
     

    Load balancing is not perfect – The load balancing mechanism in ISP-R does not distribute traffic perfectly. Since traffic
    is distributed by connections, not load, the potential exists for some
    connections to consume more bandwidth than others, skewing the
    distribution percentage.

    When ISP-R is configured to provide load balancing or failover for
    branch office WAN connections, the default dead link detection mechanism
    may not be appropriate. If you recall, TMG will randomly poll Internet
    root DNS servers to verify connectivity. If, for example, the TMG
    firewall is configured to NAT traffic between a branch office and a main
    office and the main office Internet connection is unavailable, TMG will
    report both of its WAN connections as being unavailable, when in fact
    they are.

    In some cases, branch office TMG firewalls may not have direct
    connectivity to the Internet, which will prevent TMG from polling
    Internet root DNS servers. In this branch office firewall scenario it
    would be better to poll services located directly on the other side of
    the WAN connection. To change the default link detection parameters and
    to make changes to polling frequency, please refer to this article
    [http://blogs.technet.com/isablog/archive/2009/11/26/tmg-isp-redundancy-unleashed.aspx]
    on the Forefront TMG product team blog.

    Συμπέρασμα

    Το ISP Redundancy αποτελεί ένα πολύτιμο χαρακτηριστικό του TMG διότι παρέχει fault
    tolerance και redundancy για εξωτερικές συνδέσεις δικτύου (external network connections); Επίσης σε περιπτώσεις κατά τις οποίες έχουμε ISP
    connections σε ανάπτυξη edge firewall, ή WAN links σε
    branch office firewall scenario. Τα Load Balancing και Failover operating
    modes παρέχουν την δυνατότητα ευέλικτων ρυθμίσεων έτσι ώστε να προσαρμόζονται με βάση τις προδιαγραφές των οποιονδήποτε εξωτερικών δικτύων, και σε συνδυασμό με τις απεριόριστες δυνατότητες πληροφόρησης κρατούν πάντοτε τον TMG
    firewall administrator ενημερωμένο για την κατάσταση των εξωτερικών συνδέσεων δικτύου. (Εxternal network connection
    status)
  13. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι της κοινότητας σε συνέχεια του άρθρου υλοποίσης VPN Tunnel μεταξύ του Juniper SRX
    και του Microsoft Forefront TMG 2010 Secure Gateway προχωρούμε ένα βήμα παρακάτω και υλοποιούμε ένα VPN μεταξύ του Cisco ASAs 5505 και του Forefront TMG 2010. Και σε αυτήν την προσπάθεια το αποτέλεσμα στέφθηκε από επιτυχία. Έτσι λοιπόν θα έχουμε δύο λειτουργικά VPN configurations κάνοντας χρήση εξοπλισμού από διαφορετικούς κατασκευαστές. Ουσιαστικά χρησιμοποιούμε το ίδιο setup, με μόνη αλλαγή την χρησιμοποιήση ορισμένων διαφορετικών IP addresses
    λαθώς επίσης και την αλλαγή στο σχεδιάγραμμα λειτουργίας στο οποίο αντικαθιστούμε το σύστημα SRX με το αντίστοιχο του ASA
    symbol :
     
     
    Όσον αφορά τα βήματα του wizard για λόγους συντομίας μπορείτε να τα βρείτε στο προηγούμενο άρθρο. Απλά προχωρούμε στις απαραίτητες αλλαγές των “default” settings στο IPSec configuration και χρησιμοποιούμε έναν διαφορετικό συνδυασμό στο Phase II συγκρινόμενον με αυτόν του SRX VPN έτσι να είμαστε συμβατοί με τον εξοπλισμό Cisco.
     
     
    Phase I: Εncryption = 3DES, auth SHA1, DH group2, lifetime 28800 seconds
    Phase II: Εncryption = 3DES, integrity SHA1, rekey 4608000bytes and/or 3600 seconds, pfs group2
    Σε καμία περίπτωση δεν θα πρέπει να ξεχάσουμε να επανεκκινήσουμε (restart) τα TMG services μετά από την επιτυχημένη υλοποίηση του configuration ….
    Το τελικό VPN παρουσιάζεται παρακάτω:

     
    Ο VPN wizard δημιούργησε επίσης το παρακάτω network object:
     

    Καθώς επίσης και το ακόλουθο access rule:

    Το χαρακτηριστικό αυτό είναι ιδιαιτέρως χρήσιμο και αποτελεσματικό διότι μας επιτρέπει να να κάνουμε setup για το προς υλοποίηση VPN χωρίς να είναι απαραίτητο να περάσουμε διαμέσου όλων των ενδιάμεσων βημάτων στοιχείο το οποίο από μόνο εγκυμονεί την πιθανότητα λαθών. Συνεπώς η Microsoft μας βοηθά με την χρήση έξυπνων Wizards να αποφύγουμε την πιθανότητα δημιουργίας λαθών (misconfiguration).

    Μετά από το setup και το restart, προχωρούμε στην παραμετροποίηση του Cisco ASA 5505 εφαρμόζοντας ένα απλό VPN site-to-site setup:
    crypto isakmp enable outside
    crypto isakmp policy 10
    authentication pre-share
    encryption 3des
    hash sha
    group 2
    lifetime 28800
    crypto ipsec transform-set TMGTrans esp-3des esp-sha-hmac
    crypto ipsec security-association lifetime seconds 3600
    crypto ipsec security-association lifetime kilobytes 4608000
    access-list toTMG extended permit ip 192.168.114.0 255.255.255.0 192.168.13.0 255.255.255.0
    access-list toTMG extended permit ip 192.168.13.0 255.255.255.0 192.168.114.0 255.255.255.0
    tunnel-group 172.16.100.183 type ipsec-l2l
    tunnel-group 172.16.100.183 ipsec-attributes
    pre-shared-key *
    crypto map TMGVPN 10 match address toTMG
    crypto map TMGVPN 10 set pfs
    crypto map TMGVPN 10 set peer 172.16.100.183
    crypto map TMGVPN 10 set transform-set TMGTrans
    crypto map TMGVPN interface outside
    Όπως θα παρατηρήσουμε το ping μεταξύ των δύο laptops παρουσιάζει τα αναμενόμενα αποτελέσματα στον Forefront TMG 2010:


    Αντιστοίχως στον ASA:

    Το IKE SA
    ciscoasa(config)# show crypto isakmp sa
       Active SA: 1
        Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
    Total IKE SA: 1
    1   IKE Peer: 172.16.100.183
        Type    : L2L             Role    : responder
        Rekey   : no              State   : MM_ACTIVE
     
    Το IPSec SA:
    ciscoasa(config)# show crypto ipsec sa

    interface: outside
        Crypto map tag: TMGVPN, seq num: 10, local addr: 172.16.100.160
          access-list toTMG permit ip 192.168.114.0 255.255.255.0 192.168.13.0 255.255.255.0
          local ident (addr/mask/prot/port): (192.168.114.0/255.255.255.0/0/0)
          remote ident (addr/mask/prot/port): (192.168.13.0/255.255.255.0/0/0)
          current_peer: 172.16.100.183
          #pkts encaps: 6, #pkts encrypt: 6, #pkts digest: 6
          #pkts decaps: 7, #pkts decrypt: 7, #pkts verify: 7
          #pkts compressed: 0, #pkts decompressed: 0
          #pkts not compressed: 6, #pkts comp failed: 0, #pkts decomp failed: 0
          #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
          #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
          #send errors: 0, #recv errors: 0
          local crypto endpt.: 172.16.100.160, remote crypto endpt.: 172.16.100.183
          path mtu 1500, ipsec overhead 58, media mtu 1500
          current outbound spi: D988A73B
        inbound esp sas:
          spi: 0xC740C5FB (3342910971)
             transform: esp-3des esp-sha-hmac no compression
             in use settings ={L2L, Tunnel, PFS Group 2, }
             slot: 0, conn_id: 77824, crypto-map: TMGVPN
             sa timing: remaining key lifetime (kB/sec): (3914999/3553)
             IV size: 8 bytes
             replay detection support: Y
             Anti replay bitmap:
              0x00000000 0x000001FD
        outbound esp sas:
          spi: 0xD988A73B (3649611579)
             transform: esp-3des esp-sha-hmac no compression
             in use settings ={L2L, Tunnel, PFS Group 2, }
             slot: 0, conn_id: 77824, crypto-map: TMGVPN
             sa timing: remaining key lifetime (kB/sec): (3914999/3553)
             IV size: 8 bytes
             replay detection support: Y
             Anti replay bitmap:
              0x00000000 0x00000001
    Ελπίζω ότι θα βρείτε το συγκεκριμένο άρθρο χρήσιμο.
    (Υπενθύμιση :  Συγγραφέας του άρθρου είναι ο Alex Dittman)

  14. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι της κοινότητας παρακάτω σας παραθέτω την διασύνδεση (link) για ένα εξαιρετικά πιστεύω χρήσιμο e-book από τον εκδοτικό οίκο RealTimePublishers.com, όπου μπορεί ο καθένας μας να γίνει μέλος δωρεάν αποκτώντας πρόσβαση σε μια μεγάλη συλογή ηλεκτρονικών βιβλίων όσον αφορά τον χώρο μας, με θεματογράφια η οποία καλύπτει και τις πλέον εξεζετημένες τεχνολογίες. Το συγκεκριμένο e-book με τίτλο "How to Install SSL Certificates on Microsoft Servers by Dan Sullivan" έχετε την δυνατότητα να το κατεβάσετε από τον παρακάτω σύνδεσμο :
     
    http://nexus.realtimepublishers.com/htis.php
     
    Για την καλύτερη ενημέρωσή σας, παραθέτω παρακάτω τα περιεχόμενα του συγκεκριμένου ηλεκτρονικού βιβλίου από το πρωτότυπο στην Αγγλική γλώσσα. Ελπίζω ότι θα το βρείτε χρήσιμο.
     


    Synopsis
    Windows administrators are continually tasked with securing
    servers and applications, including installing SSL certificates for
    authentication and encryption. This raises a number of questions for
    system administrators: which kind of SSL certificate should be used?
    How are SSL certificates installed? What is the Certificate Store? How
    does SSL work in Internet Information Server (IIS), Exchange Server,
     SQL Server and SharePoint?  This how-to guide provides detailed step by
    step instructions on how to select, install and maintain SSL
    certificates in Microsoft environments. Whether you are just starting
    out and need to know how to acquire a certificate, or you are looking
    for tips on troubleshooting and maintaining existing certificate
    configurations, this guide has pragmatic and detailed information to
    help you.

    Chapter Previews
    Chapter 1: Getting Started with SSL Certificates in Windows Server

    We are constantly making use of SSL certificates, although we may not appreciate the
    frequency. When we navigate to a site using HTTPS, we are making use of an SSL certificate.
    When we encrypt a message to send to another party, we are depending on an SSL
    certificate. When we install software that has been signed by a trusted source, we are once
    again making use of SSL certificates. Their prevalence in IT environments indicates just
    how valuable they are in a number of applications. It is not surprising that sooner or later,
    many systems administrators, application managers, and other Windows professionals
    need to install and manage SSL certificates.

    This book is designed to help you understand how to select an SSL certificate, install it in a
    Windows environment, manage multiple certificates, and use them with specialized
    applications, such as the SQL Server relational database. The guide is organized into four
    chapters.


    Chapter 2: Understanding the Microsoft Certificate Store

    One of the things we quickly realize when we start to work with SSL certificates is how
    many we need to manage. We can have SSL certificates for Web servers, mail servers,
    various kinds of application servers, and individual users can have servers, too. And those
    are just the servers we generate or acquire for internal purposes. We also need to manage
    certificates for trusted third parties, like Microsoft or security vendors that provide SSL
    certificates. Certificates from these trusted sources are kept on our computers so that we
    can determine the authenticity of certificates signed by these parties. Clearly, we need a
    way to keep track of all the digital certificates. This is where a certificate store comes in.

    In this, the second chapter of How to Install SSL Certificates for on Microsoft Servers, we will
    examine some of the basic tasks associated with managing and maintaining SSL certificates.
    Before we jump into various certificate operations, we need to understand a bit about the
    certificate store and tools for working with that store.

    The chapter is organized into three main sections:

    Overview of the purpose of the certificate store How to manage certificates with the Microsoft Management Console (MMC) Maintenance tasks associated with SSL certificates
    The object of this chapter is to familiarize you with how the Windows operating systems
    (OSs) manage certificates and what you need to do to before taking the next step of
    deploying SSL certificates in your Web servers, email servers, database servers, and other
    enterprise applications.


    Chapter 3: Using SSL Certificates in Microsoft Internet Information Server (IIS)

    The goal of this book is to provide readers a step‐by‐step guide to working with SSL
    certificates in a Windows environment. In the first chapter, we considered different types
    of SSL certificates and the reasons for choosing one type over another. In the second
    chapter, we delved into the Microsoft Certificate Store and reviewed how to use the
    Microsoft Management Console (MMC) to perform basic certificate operations and
    management tasks. In this chapter, we turn our attention to one of the most common
    business drivers for using SSL certificates: providing assurance about the authenticity of
    our business' Web sites.

    Web sites make use of SSL certificates to authenticate themselves to clients and to support
    encrypted communication with clients. Windows systems administrators responsible for
    maintaining Web sites will likely have to install and maintain SSL certificates for one or
    more sites. This chapter provides a detailed explanation of how to install SSL certificates
    with Internet Information Server (IIS) Manager, including binding certificates to sites,
    configuring SSL settings, and verifying installation. The role of authenticating clients with
    SSL certificates is also discussed. We conclude this chapter with a discussion of setting up
    development and test environments with self‐signed certificates.

    The chapter is organized around three tasks commonly performed when working with IIS:

    Installing SSL certificates in IIS with the IIS Manager Authenticating clients with client certificate mapping Setting up SSL‐enabled development and test environments
    Most of the work involved in these steps occurs within the IIS Manager, but as we will see
    next, an important step begins with requesting a certificate from a trusted third‐party
    provider.


    Chapter 4: Installing SSL Certificates in Microsoft Exchange Server, Microsoft SharePoint, and Microsoft SQL Server

    SSL certificates are often associated with Web servers such as
    Microsoft IIS, but they are actually used in a variety of Microsoft
    applications, including Microsoft Exchange email server, Microsoft
    SharePoint collaboration server, and the Microsoft SQL Server database.
    The process of installing an SSL certificate has both common and
    application-specific steps across these applications. This final chapter
    discusses how to install an SSL certificate in Microsoft Exchange
    Server, Microsoft SharePoint Server, and Microsoft SQL Server. We begin
    with a quick overview of the common parts of the installation process,
    then discuss each application in more detail.


     
  15. Jordan_Tsafaridis
    Λειτουργικό Περιβάλλον : Μετάβαση (Migration) από τον Exchange Server 2003 στον Exchange Server 2010. Το συγκεκριμένο πρόβλημα εμφανίστηκε αμέσως μετά την επιτυχημένη μετάβαση στην έκδοση 2010.

    Θέματα : Κατά την διαδικασία του Downloading του offline address book δημιουργείται το παρακάτω λάθος (error) στους outlook clients.
    The Microsoft Exchange server reported 0x80190194 the operation failed

    Πρώτα απ' όλα θα πρέπει να προχωρήσουμε στους παρακάτω ελέγχους εάν λαμβάνουμε τέτοιας μορφής μηνυμάτα λάθους :

    Ελέγχουμε τα application logs για να διαπιστώσουμε εάν κάτι σχετίζεται με το ίδιο θέμα.
    Βρίσκουμε σε ποια database ο χρήστης ή οι χρήστες βρίσκονται καταχωρημένοι (problematic user) και εν συνεχεία ελέγχουμε την PF folder database (Δείχνει τον σωστό διακομιστή). Offline
    address book : Προσπαθούμε να δημιουργήσουμε ένα καινούριο και το αφήνουμε να κάνει replicate από το υπάρχον και προβληματικό και χρησιμοποιούμε το καινούριο ΟΑΒ στην συγκεκριμένη DB έτσι ώστε να διαπιστώσουμε έαν επιλύεται το πρόβλημα. Πηγαίνουμε στα properties του OAB , και ελέγχουμε εάν είναι τσεκαρισμένα/επιλεγμένα (enabled) τα Version2, και Version 3,
    καθώς και το public folder distribution είναι τσεκαρισμένο/επιλεγμένο (enabled) και ο σωστός PF διακομιστής (server) εμφανίζεται εκεί.
    Εάν συνεχίζουμε να αντιμετωπίζουμε τα ίδια προβλήματα τότε οι ενέργειες οι οποίες πρέπει να λάβουν χώρα είναι οι ακόλουθες :
    Διαγραφή όλων των αρχείων στον κατάλογο (Directory) : C:\Program Files\Microsoft\Exchange Server\Client Access\OAB
    Δημιουργία καινούριου OAΒ. Επανεκίννηση του Microsoft Exchange File Distribution Service και επιβεβαιώνουμε ότι το καινούριο OAB έχει δημιουργηθεί στον συγκεκριμένο κατάλογο (directory) ο οποίος έχει αναφερθεί παραπάνω. Ολοκληρώνοντας για την αποφυγή αλλά και αντιμετώπιση τέτοιων λαθών καλό είναι να παρακολουθούμε τα application logs, ακθώς επίσης θα πρέπει να αυξήσουμε το επίπεδο του diagnostic logon εάν αυτό κρίνεται απαραίτητο στους CAS servers.
  16. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι της κοινότητας του autoexec παρακάτω σας παραθέτω δύο εξαιρετικά σοβαρές περιπτώσεις ασφάλειας του λειτουργικού συστήματος linux οι οποίες έγιναν γνωστές σήμερα Δευτέρα 25 Οκτωβρίου 2010.

    Μια ομάδα Security experts ανακάλυψε δύο vulnerabilities στην πλατφόρμα του Linux operating system οι οποίες δίνουν την δυνατότητα σε κακόβουλους attackers να αποκτήσουν root privileges σε ένα παραβιασμένο/μολυσμένο σύστημα (infected system).

    Το πρώτο Linux vulnerability αναφέρθηκε από την εταιρία ασφάλειας δεδομένων δικτύων VSR,
    η οποία τεκμηρίωσε ότι το συγκεκριμένο security flaw σχετίζεται με την εγκατάσταση/ανάπτυξη του Reliable Datagram Sockets protocol (RDS) στις εκδόσεις 2.6.30 εως και την 2.6.36-rc8 του Linux kernel.

    Σύμφωνα με την επιστημονική ομάδα της εταιρίας, το συγκεκριμένο vulnerability θα επιτρέψει σε έναν attacker να εγγράψει arbitrary data στην kernel memory τα οποία με την σειρά τους μπορούν να χρησιμοποιηθούν για να αναβαθμίσουν το επίπεδο πρόσβασης σε επίπεδο root. (Escalate
    privileges to root)

    Για τον σκοπό αυτό παραθέτω αυτούσια την ανακοίνωση της εν λόγω εταιρίας στην Αγγλική γλώσσα :
    “The exploit leverages the ability to write
    into kernel memory to reset the kernel's security operations structure
    and gain root privileges. The exploit requires that kernel symbol
    resolution is available to unprivileged users”.

    Το δεύτερο Linux vulnerability, το οποίο ανακαλύφθηκε από τον security researcher
    Tavis Ormandy, σχετίζεται σε ένα flaw το οποίο βρέθηκε στο library loader του GNU C library, το οποίο και αυτό με την σειρά του μπορεί να χρησιμοποιηθεί για την απόκτηση δικαιώματων πρόσβασης σε επίπεδο root user.

    Για περισσότερες πληροφορίες δείτε τον παρακάτω σύνδεσμο : http://www.portal.itproportal.com/portal/news/article/2010/10/25/linux-flaws-provide-root-access-hackers/#ixzz13OFYCc7U
  17. Jordan_Tsafaridis
    Αγαπητοί Συνάδελφοι της κοινότητας του autoexec,
     
    με το παρόν άρθρο θα ήθελα να δώσω την δυνατότητα πρόσβασης σε ένα πολύ χρήσιμο εργαλείο για όλους εμάς που ασχολούμαστε επαγγελματικά με την τεχνολογία του Active Directory. Στο link το οποίο παρατίθεται παρακάτω, επισυνάπτεται σε μορφή αρχείου Adobe Acrobat PDF, ένας οδηγός ο οποίος περιλαμβάνει όλα τα πλέον χρησιμοποιούμενα PowerShell cmdlets για το Active Directory στον Windows Server 2008 R2. Άλλωστε πόσες φορές έχουμε βρεθεί σε κάποιο κρίσιμο σημείο μιας εγκατάστασης κατά το οποίο δεν θυμόμαστε κάποια απλή εντολή. Εδώ πιστεύω ότι βρίσκεται η χρησιμότητα του συγκεκριμένου οδηγού.
     
    Ο σύνδεσμος στο διαδίκτυο είναι ο παρακάτω :
     
    http://www.jonathanmedd.net/wp-content/uploads/2009/10/ADPowerShell_QuickReference.pdf
     
    Ελπίζω ότι θα τον βρείτε ιδιαιτέρως χρήσιμο.
     
     
  18. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι της κοινότητας ο σκοπός του συγκεκριμένου άρθρου είναι να σας βοηθήσει με τέτοιο τρόπο έτσι ώστε να έχετε πρόσβαση από έναν και μόνο σημείο χωρίς να χάνετε το χρόνο σας ψάχνοντας στα Microsoft support links για να κατεβάσετε όλα τα απαιτούμενα hot fixes και updates για να εγκαταστήσετε τον Exchange 2010 SP1.
     
     
     
    Συνεπώς κατά την λογική μου κάνω download όλα τα updates και τα διαχωρίζω σε 3 διαφορετικά
    ZIP files. Το αρχείο 2008-R1.zip για τα Server 2008 R1 hot fixes. Το αρχείο 2008-R2.zip για τα Server 2008 R2 hot fixes. Τέλος το αρχείο Shared.zip για όλα εκείνα τα updates τα οποία είναι κοινα και για τις λειτουργικές πλατφόρμες. Τα αποθηκελυω εν συνεχεία για ευκολία σε ένα USB thumb drive.
     
     
     
    Contents of Shared:
     
    FilterPack64bit.exe
     
    UcmaRedist.msp (August 2010 - 3.5.6907.210)
     
     
     
    Contents of 2008-R1:
     
    KB 973136 - request
     
    KB 977592 - request
     
    KB 977624-v2 - request
     
    KB 979099 - request
     
    KB 979744 - request
     
    KB 979917 - request
     
    KB 982867-v2 - request
     
     
     
    Contents of 2008-R2:
     
    KB 977020-v2 - request
     
    KB 977357 - request
     
    KB 979099 - request
     
    KB 979744 - request
     
    KB 979917 - request
     
    KB 981314 - request
     
    KB 982867-v2 - request
     
    KB 983440 - request
     
     
     
    Contents of W7:
     
    KB 977020-v2 - request
     
    KB 982867-v2 - request
     
     
     
    Τα μοναδικά updates στην παραπάνω λίστα τα οποία δεν αποτελούν αναστολείς της εγκατάστασης (deployment blocker)από τον εγκαταστάτη του
    Exchange 2010 SP1 είναι τα Server 2008 R2 WMI memory leak
    hot fixes - KB 977357 και 981314.
    Εφόσον παρακολουθείτε τους Exchange servers με το System Center Operations
    Manager ή με οτιδήποτε άλλο λογισμικό το οποίο συνεχώς καλεί την WMI Win32_Service class, αυτό το hot fix είναι απαραίτητο.
     
     
     
    Από καιρό σε καιρό η Microsoft ανανεώνει αυτά τα hot fixes. Όπως θα παρατηρήσετε μερικά από αυτά τα hot fixes βρίσκονται ήδη στην έκδοση 2.
     
     
     
    Τα επερχόμενα service packs των Windows και του .NET Framework θα αντικαταστήσουν την χρησιμότητα των συγκεκριμένων updates και έτσι δεν θα χρειάζονται πλέον
     
    Ελπίζω ότι το συγκεκριμένο άρθρο θα σας φανεί χρήσιμο.
     
     
  19. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι της κοινότητας σκοπός του συγκεκριμένου άρθρου είναι να παρουσίασουμε τον τρόπο με τον οποίο μπορούμε να κάνουμε
    publish τις δικές μας external DNS services χρησιμοποιώντας τον TMG 2010. Φυσικά κάποιος εύλογα θα ρωτήσει για ποιό λόγο θα θέλαμε να το πραγματοποιήσουμε αυτό; Απλά ο λόγος είναι ένας και μόνος Α Σ Φ Α Λ Ε Ι Α.

    Εφαρμόζοντας αυτήν την τεχνική, διασφαλίζουμε ότι δικοί μας BIND servers βρίσκονται - κρατούνται ασφαλείς στο εσωτερικό δίκτυο, χρησιμοποιώντας κανόνες για secure web publishing για όλες τις Internet facing services, έχοντας το πλεονέκτημα το οποίο απορρέει από το DNS
    application filtering του TMG 2010, χαρακτηριστικό το οποίο επιτρέπει την επιπλέον θωράκιση από επιθέσεις των δικών μας name servers. Θεωρήστε την τεχνική της DMZ παλαιά και ξεπερασμένη, σε αντίθεση με το secure publishing το οποίο αποτελεί το νέο hotness.





    Η διαδικασία αυτή είναι πάρα πολύ εύκολη στην υλοποίηση της. Οι μόνες προϋποθέσεις που απαιτούνται είναι η ύπαρξη external ip address για τον TMG 2010, καθώς επίσης ότι το εξωτερικό Firewall (external firewall), είναι ρυθμισμένο να επιτρέπει το UDP 53 inbound από το Internet.

    Κάνουμε Log In στον TMG server, και εν συνεχεία τρέχουμε την Forefront TMG management
    console.

    Κάνουμε στο Right-click Firewall Policy, και επιλέγουμε New, Non-Web Server Protocol
    Publishing Rule…
     
     

    Καταχωρούμε ένα όνομα (Name) για τον κανόνα publishing rule external dns, και εν συνεχεία κάνουμε κλικ στο Next.

     

    Εισάγουμε την εσωτερική IP διεύθυνση (internal ip.addr) του δικού μας BIND server,και εν συνεχεία κάνουμε κλικ στο Next.


     

    Από την εμφανιζόμενη drop down list, επιλέγουμε το DNS Server protocol. Μπορούμε να κάνουμε κλικ στο Properties, μετά στο Parameters έτσι ώστε να είμαστε σίγουροι ότι αυτό επιτρέπει το TCP 53
    Inbound, και το UDP 53 στο Receive και Send. Θα πρέπει να επιτρέπουμε πρόσβαση μόνονσ το UDP 53
    από το Internet. Όπως γίνεται αντιληπτό αυτό είναι σωστό. Εν συνεχεία κάνουμε κλικ στο Next.
    Σκοπός μας είναι να επιτρέψουμε την πρόσβαση στην πόρτα TCP 53 εφόσον θα χρειαστούμε να κάνουμε τα οποιαδήποτε zone transfers πάνω από το Internet… Οι κανόνες του TMG υποθέτουν πως αυτή η διαδικασία θα χρειαστεί. Μπορούμε να καθορίσουμε ένα νέο φίλτρο για τον DNS, αλλά κατά την άποψή μου αυτό στην παρούσα φάση δεν είναι απαραίτητο, εάν ποτέ χρειαστούμε να εγκαταστήσουμε έναν επιπλέον DNS server ο οποίος κάνει transfer πάνω από το Internet, διαδικασία την οποία μπορούμε να ελέγξουμε από το perimeter firewall χωρίς να χρειαστούμε να κάνουμε την οποιαδήποτε αλλαγή στον TMG.


    Επιλέγουμε την external address η οποία πρόκειται να χρησιμοποιηθεί για το DNS
    publishing.
     
     

    Κάνουμε κλικ στο Next, και αμέσως μετά κάνουμε κλικ στο Finish, εν συνεχεία κάνουμε access στα properties του συγκεκριμένου κανόνα (publishing
    rule). Εκτός και αν ο δικός μας TMG server αποτελεί την default gateway, τότε το ρυθμίζουμε με τέτοιο τρόπο έτσι ώστε τα
    requests να φαίνονται ότι έρχονται από τον TMG server.

     

    Σκοπός μας είναι να βελτιστοποιήσουμε τα default DNS application filter settings*. Για να το πραγματοποιήσουμε αυτό, επιλέγουμε το Intrusion Prevention, εν συνεχεία επιλέγουμε το Behavioural Intrusion
    Detection, μετά κάνουμε κλικ στο Configure Detection Settings for Common Network
    Attacks, και αμέσως μετά κάνουμε κλικ στο DNS Attacks tab. Κάνουμε Check στο κουτάκι του "DNS zone
    transfer" με σκοπό την επιπλέον προστασία εναντίον κακόβουλων επιθέσεων. (Στα Αγγλικά : to further protect against bad guys trying to pull your
    entire zone)
     
    Εάν για τον οποιοδήποτε λόγο χρειαστούμε έναν ακόμη DNS server ο οποίος θα κάνει "pull zone transfers over the Internet",
    θα χρειαστεί να αποεπιλέξουμε αυτή την επιλογή.


    Από το top της συγκεκριμένης κονσόλας, κάνουμε κλικ στο Apply, εισάγουμε την αλλαγή στην περιγραφή του configuration, και αμέσως μετά κάνουμε κλικ στο Apply για να ολοκληρώσουμε.

     

    *Αναγνώριση των επιθέσεων DNS (Detection of DNS attacks)

    Η πληροφορία η οποία προέρχεται αυτούσια από το TechNet, μας δίνει την δυαντότητα να αντιληφθούμε από τι επιθέσεις προστατεύει ο TMG
    τους DNS servers. Για τον λόγο αυτό παραθέτω το κείμενο στην Αγγλική γλώσσα.


    The DNS Filter, which is installed with Forefront TMG, intercepts and
    analyzes all inbound DNS traffic destined for the Internal network and
    other protected networks. If DNS attack detection is enabled, you can
    specify that the DNS Filter will check for the following types of
    suspicious activity.

    DNS host name overflow. A DNS response for a host
    name exceeds a certain fixed limit (255 bytes). Applications that do not
    check the length of the host names may overflow internal buffers when
    copying this host name, allowing a remote attacker to execute arbitrary
    commands on a targeted computer. DNS length overflow. A DNS response for an IP
    address exceeds the specified length of 4 bytes. By crafting a DNS
    response with a longer value, some applications executing DNS lookups
    will overflow internal buffers, allowing a remote attacker to execute
    arbitrary commands on a targeted computer. Forefront TMG also checks
    that the value of RDLength does not exceed the size of the rest of the
    DNS response. DNS zone transfer. A client system uses a DNS
    client application to transfer zones from an internal DNS server.
    Όταν αναγνωρίζονται offending packets, τότε αυτά απορρίπτονται, και αυτομάτως δημιουργείται ένα event
    το οποίο μας ενημερώνει ότι υπάρχει ένα DNS Intrusion alert. Μπορούμε να ρυθμίσουμε έτσι ώστε τα alerts τα εγείρονται γι' αυτά τα events, να μας ενημερώνουν άμεσα ότι αναγνωρίστηκε μια επίθεση (Attack Detection). Αντιστοίχως όταν δημιουργείται ένα DNS Intrusion event πέντε φορές κατά την διάρκεια ενός δευτερολέπτου και αφορά DNS zone transfer, τότε εγείρεται ένα DNS Zone Transfer
    Intrusion alert. Από την αρχική ρύθμιση του TMG (By default), όταν εγείρονται applicable
    predefined alerts, δεν πρόκειται να εμφανιστούν ξανά μέχρι να γίνουν reset χειροκίνητα. Είναι στην διακριτική μας ευχέρεια να ρυθμίσουμε το συγκεκριμένο alert να μας αποστέλει ένα email, ή να ενεργοποιεί μια συγκεκριμένη ενέργεια εφόσον το απαιτούμαι, ή απλά μπορούμε να χρησιμοποιούμε το logging για να κρατούμε ένα ιστορικό για το δίκτυο μας.

    Για λόγους σύνδεσης με την προηγούμενη έκδοση του TMG-2010, η διαδικασία ρύθμισης του ISA 2006 είναι σχεδόν ταυτόσιμη, με μόνη διαφοροποίηση ότι το Intrusion Detection βρίσκεται κάτω από το Configuration, στο General
    section.
  20. Jordan_Tsafaridis
    ΣΕ
    ΔΙΑΓΩΝΙΣΜΟ ΠΟΥ ΕΓΙΝΕ ΕΔΕΙΞΑΝ ΟΤΙ ΔΕΝ ΠΡΟΣΤΑΤΕΥΟΥΝ ΟΣΟ ΥΠΟΣΧΟΝΤΑΙ

    Τα
    προγράμματα κατά των ιών δεν είναι και τόσο αποτελεσματικά
     

    ΔΗΜΟΣΙΕΥΘΗΚΕ: Σάββατο 15 Μαΐου 2010
    Σ΄ έναν διαγωνισμό που οργανώθηκε το περασμένο Σαββατοκύριακο στο Παρίσι, 15 προγράμματα κατά των ιών των ηλεκτρονικών υπολογιστών υποβλήθηκαν σε επτά
    επιθέσεις οργανωμένες από φοιτητές και ειδικούς σε θέματα ασφάλειας των Η/Υ.
    Κανένα λογισμικό δεν κατάφερε να εμποδίσει περισσότερες από δύο.
     
    Ο
    διαγωνισμός «ΡWΝ2ΚΙLL» έδειξε ότι πρέπει να αμφιβάλλουμε για την
    αποτελεσματικότητα των προγραμμάτων κατά των ηλεκτρονικών που διαφημίζουν οι
    κατασκευαστές τους. Κανένα από τα 15 αντιιικά προγράμματα που κυκλοφορούν στην
    αγορά δεν μπόρεσε να εμποδίσει περισσότερες από δύο στις επτά επιθέσεις που
    έγιναν σε υπολογιστές εφοδιασμένους με Windows 7. Επτά υποψήφιοι, οι
    περισσότεροι από τους οποίους ήταν φοιτητές της Πληροφορικής, διέθεταν
    συνηθισμένα ΡC στα οποία είχαν συνδεθεί 15 εικονικά ΡC, καθένα από τα οποία ήταν
    εφοδιασμένο μ΄ ένα διαφορετικό λογισμικό ασφαλείας από αυτά της αγοράς. Τα
    «κακόβουλα» προγράμματα, οι ιοί που δημιουργήθηκαν από τον κάθε υποψήφιο,
    αντιγράφηκαν σε κάθε εικονική συσκευή. Από τους επτά υποψηφίους, μόνον ένας είδε
    τον ιό του να μπλοκάρεται από όλα τα αντιιικά προγράμματα (τα πλήρη αποτελέσματα
    δημοσιεύονται στη διεύθυνση : http://www.esiea-recherche.eu/data/iawacs2010/pwn2kill/pwn2killdebrief.pdf ).
     
    Εκτός μάχης. Για τον Ερίκ Φιλιόλ,
    διευθυντή έρευνας της ΕSΙΕΑ (Ανώτερη Σχολή Πληροφορικής, Ηλεκτρονικής και
    Αυτοματισμού), «όλα τα προγράμματα κατά των ιών είναι εξίσου αναποτελεσματικά.
    Τα αποτελέσματα του διαγωνισμού αποδεικνύουν πως ο εντοπισμός της «υπογραφής»
    του ιού δεν είναι πλέον αρκετή. Το πιο ανησυχητικό είναι πως, σε μια κλίμακα από
    το 1 ώς το 10, το μέσο τεχνικό επίπεδο των επιθέσεων βρισκόταν περίπου στο 4. Αν
    οι επιθέσεις ήταν ακόμη πιο περίπλοκες, το αποτέλεσμα θα ήταν ακόμη πιο
    καταστροφικό. Και υπήρξε άλλη μια ανησυχητική διαπίστωση: μία από τις επιθέσεις
    βασιζόταν σ΄ έναν ιό των τριών γραμμών, ο οποίος εμφανίστηκε πριν από 10 χρόνια
    και υπάρχει στο ΥouΤube. Ομως έθεσε εκτός μάχης όλα τα αντιιικά προγράμματα!».
     
     
    Παρά τον πολύ αρνητικό αυτό απολογισμό, η εγκατάσταση προγράμματος κατά
    των ιών παραμένει αναγκαία.
     
     
     
  21. Jordan_Tsafaridis
    Εισαγωγή

    Όταν κάνουμε εγκατάσταση της τεχνολογίας Hyper-V στο data center στο οποίο εργαζόμαστε, ή δημιουργούμε εργαστηριακά περιβάλλοντα εργασίας, είναι απαραίτητο να έχουμε και μια λύση για την δημιουργία αντιγράφων ασφαλείας τόσο για τις virtual machines όσο και για τους Hyper-V servers. Για τον λόγο αυτό η Microsoft πρόσφατα έδωσε στην κυκλοφορία την τελευταία έκδοση του δικού της enterprise
    backup and disaster recovery λογισμικού το οποίο είναι ο Data Protection Manager 2010. Το συγκεκριμένο άρθρο αποτελεί το πρώτο μιας σειράς άρθρων η οποία σκοπό έχει να εξηγήσει το πως κάνουμε install, configure, και χρησιμοποιούμε τον DPM 2010 έτσι ώστε να πραγματοπούμε backup και restore σε virtual machines και Hyper-V servers.
    Απαιτήσεις για την Εγκατάσταση


    Πριν ξεκινήσουμε την εγκατάσταση του DPM 2010 θα πρέπει να είμαστε σίγουροι ότι ο server στον οποίο θα λάβει χώρα η εγκατάσταση θα πρέπει πληρεί ορισμένες προδιαγραφές. Στην συγκεκριμένη περίπτωση, η εγκατάσταση του DPM 2010 θα γίνει σε έναν server με λειτουργικό σύστημα Windows Server 2008 R2
    Standard ή Enterprise Edition (Η έκδοση Datacenter επίσης υποστηρίζεται).

    Απαιτήσεις Συστήματος (System Requirements)

    Για την εγκατάσταση του DPM 2010 απαιτούνται τα παρακάτω :

    64-bit version of Windows Server 2008 or 2008 R2
    4GB RAM (recommended)
    2.3 GHz quad core CPU
    System drive installation space of 3GB for installing1.  
    DPM installation files
    2.   Database files
    3.   SQL 2008

    PowerShell 2.0
    .Net Framework 3.5.1
    Single Instance Store (SIS)
    Windows Installer 4.5
    Οι ελάχιστες προδιαγραφές για τον server στον οποίο πρόκειται να εγκατασταθεί ο DPM 2010 είναι υπεραρκετές για την πλειοψηφία των εταιριών. Εν τούτοις ο DPM 2010 έχει υψηλές απαιτήσεις τόσο σε χωρητικότητα δίσκων όσο και σε disk I/O performance, όταν πρόκειται να εγκατασταθεί σε απαιτητικά περιβάλλοντα εργασίας.
     

    Ο DPM 2010 απαιτεί μια εγκατάσταση ενός dedicated SQL server για την αποθήκευση των πληροφοριών του backup. Η εγκατάσταση της SQL μπορεί να βρίσκεται σε κάποιο άλλο σύστημα ή τοπικά στον ίδιο server στον οποίο θα εγκατασταθεί και ο DPM 2010, η δε έκδοση της SQL θα πρέπει να είναι SQL 2008
    (Standard ή Enterprise). Είναι χαρακτηριστικό να αναφέρουμε ότι στις περισσότερες εταιρίες υπάρχει εγκατεστημένη μια βάση SQL η οποία συνήθως βρίσκεται σε dedicated servers. Για να καλύψουμε όλες τις περιπτώσεις στο συγκεκριμένο άρθρο θα αναφερθούμε στην εγκατάσταση του DPM 2010 τόσο με remote όσο και με local instance του SQL 2008. Συστήνεται επίσης η χρήση της SQL 2008 64-bit η οποία είναι εγκατεστημένη σε ένα remote
    instance όταν πρόκειται για ένα βεβαρημένο περιβάλλον εργασίας για τον DPM 210 server.

    Απαιτήσεις για Active Directory


    Ο DPM 2010 απαιτεί έναν περιβάλλον Windows 2008 Active Directory για την εγκατάστασή του. Ο server στον οποίο ο DPM πρόκειται να εγκατασταθεί θα πρέπει να είναι member ενός Active Directory domain, καθώς επίσης και το account το οποίο θα χρησιμοποιήσουμε για να εγκαταστήσουμε τον
    DPM θα πρέπει να είναι ένα domain user account το οποίο έχει local administrator
    privileges. Θα πρέπει να τονίσουμε ότι μετά την εγκατάσταση θα πρεπει να είμαστε ένας χρήστης domain με local
    administrative access για να μπορούμε να τρέξουμε την DPM 2010 console.

    Έτσι λοιπόν είναι δυνατό το backup και το restore σε servers οι οποίοι βρίσκονται στο ίδιο
    forest ή σε ομάδα από forests. Στην περίπτωση του backup ή restore across forests θα πρέπει να έχουμε forest level trusts, και το forest level θα πρέπει να είναι σε Windows 2008
    forest mode.

    Περιορισμοί στην Εγκατάσταση


    Ο DPM έχει επίσης και ορισμένους περιορισμούς για την εγκατάστασή τουσε συνδυασμό με τις απαιτήσεις για την εγκατάσταση. Ο DPM 2010 έχει σχεδιαστεί να τρέχει σε έναν dedicated
    server. Επίσης ο DPM 2010 δεν μπορεί να εγκατασταθεί στους παρακάτω τύπους servers :

    Domain Controller
    Cluster Services cannot be installed
    System Center Operations Manager
    Exchange Server
    Εγκατάσταση Remote Instance του SQL 2008


    Εάν θέλουμε να χρησιμοποιήσουμε ένα remote instance του SQL 2008, τότε αυτό θα πρέπει να ικανοποιεί τις παρακάτω απαιτήσεις κατά την εγκατάσταση.

    Νέα εγκατάσταση του SQL 2008
    Απαιτούμενα χαρακτηριστικά1.   Database services (and all
    subsections)
    2.   Reporting Services
    3.   Management tools –
    complete
    4.   SQL Client Connectivity SDK

    Windows Authentication
    Εγκατάσταση Single Instance Store


    Ο DPM 2010 απαιτεί την υπηρεσία Single Instance Store (SIS) service έτσι ώστε να περιορίσει δραστικά το storage overhead όταν αποθηκεύονται duplicate files. Είναι δε προτιμότερο να επανεγκαταστήσουμε την υπηρεσία Single Instance Store πριν από την εγκατάσταση του DPM
    2010. Εάν δεν εγκαταστήσουμε εκ των προτέρων την υπηρεσία SIS τότε ο DPM θα την εγκαταστήσει για μας, κατά το βήμα της εγκατάστασης με την χαρακτηριστική ονομασία prerequisite installation step, αλλά θα απαιτήσει μετά την εγκατάσταση της συγκεκριμένης υπηρεσίας την επανεκκίνηση του συτήματος, με αποτέλεσμα να είμαστε υποχρεωμένοι να ξεκινήσουμε την εγκατάσταση του DPM από την αρχή.
     

    Για να εγκαταστήσουμε την υπηρεσία SIS, χρησιμοποιούμε την παρακάτω command line:

    OCSetup.exe SIS-Limited /quiet

    Η παραπάνω εντολή θα εγκαταστήσει την υπηρεσία SIS και εν συνεχεία θα επανεκκινήσει τον υπολογιστή. Εάν επιθυμούμε να έχουμε τον έλεγχο όσον αφορά την επανεκκίνηση του συστήματος τότε δεν έχουμε παρά να προσθέσουμε την επιλογή /Norestart command line χάρις την οποία η επανεκκίνηση θα γίνει χειροκίνητα από εμάς.

    Εγκατάσταση του DPM 2010 με τοπική SQL 2008


    Ακολουθούμε τα παρακάτω βήματα για την εγκατάσταση του DPM 2010 σε συνδυασμό με τοπικό instance του SQL
    2008. Σημειώστε ότι δεν είναι απαραίτητη η επανεγκατάσταση του SQL 2008 διότι η εγκατάσταση του DPM
    2010 περιλαμβάνει και την εγκατάσταση του SQL 2008.

    Κάνουμε logon στον server και εγκαταστούμε τον DPM 2010 κάνοντας χρήση ενός domain account ο οποίος έχει local administrative privileges
    Εισαγάγουμε το DPM 2010 DVD
    Στην DPM 2010 Splash screen, κάνουμε κλικ στο Install Data Protection Manager


    Figure 1

    Στην σελίδα Microsoft License Terms, διαβάζουμε το κείμενο της συμφωνίας (agreement), επιλέγουμε I accept the license terms and conditions, και εν συνεχεία κάνουμε κλικ στο OK.


    Figure 2

    Ορισμένα προαπαιτούμενα χαρακτηριστικά (prerequisites) θα εγκατασταθούν πρώτα, και μετά θα ξεκινήσει η εγκατάσταση.
     

    Στην σελίδα Welcome, κάνουμε κλικ στο Next

    Figure 3

    Στην σελίδα Prerequisites Check, ο εγκαταστάτης του DPM θα εγκαταστήσει τα basic components και θα αξιολογήσει (validate) το hardware στο οποίο γίνεται η εγκατάσταση. Επιπροσθέτως θα προχωρήσει σε έλεγχο έτσι ώστε να διαπιστωθεί εάν είναι εγκατεστημένα το .Net Framework 3.5.1, το PowerShell 2.0 και το Single Instance Store (SIS). Στην περίπτωση κατά την οποία τα παραπάνω δεν είναι εγκατεστημένα τότε θα τα εγκαταστήσει ως μέρος της εγκατάστασης του DPM 2010.
    Εάν η υπηρεσία SIS δεν είναι εγκατεστημένη, τότε η εγκατάσταση του DPM θα απαιτήσει την επανεκκίνηση του συστήματος μετά την ολοκλήρωση της εγκατάστασης της υπηρεσίας SIS.


    Figure 4

    Κάνετε κλικ στο Next για να συνεχίσει η εγκατάσταση.
    Στην σελίδα Product Registration, εισάγουμε το Username και το όνομα της εταιρίας-Company που επιθυμούμε και κάνουμε κλικ στο Next.

    Figure 5

    Στην σελίδα Installation Settings, επιλέγουμε τον τύπο εγκατάστασης του SQL (dedicated or existing) και μετά κάνουμε κλικ στο Next.

    Figure 6

    Για την συγκεκριμένη εγκατάσταση θα χρησιμοποιήσουμε την επιλογή dedicated SQL installation.
    Σας παρακαλώ να ανατρέξετε στα εγχειρίδια χρήσης του DPM 2010 για τις επιλογές οι οποίες υπάρχουν στην περίπτωση κατά την οποία θέλουμε να χρησιμοποιήσουμε μια ήδη υπάρχουσα εγκατάσταση βάσης δεδομένων SQL.

    Στην σελίδα Security Settings, εισάγουμε το password για την τοπική βάση δεδομένων SQL server service acct την οποία ο DPM πρόκειται να δημιουργήσει, και εν συνεχεία κάνουμε κλικ στο Next

    Figure 7

    Στην σελίδα Microsoft Update Opt-In, επιλέγουμε εφόσον θέλουμε να γίνεται ή να μην γίνεται έλεγχος για security updates του DPM και μετά κάνουμε κλικ στο Next.

    Figure 8

    Στην σελίδα Customer Experience, επιλέγουμε εάν θέλουμε να συμμετάσχουμε ή όχι στο Microsoft Customer Experience program, και μετά κάνουμε κλικ στο Next.

    Figure 9

    Στην σελίδα Summary of settings, παρουσιάζεται ένας συνοπτικός πίνακας των ρυθμίσεων-επιλογών για την εγκατάσταση του DPM και εν συνεχεία κάνουμε κλικ στο Install για να ξεκινήσει η εγκατάσταση.

    Figure 10

    Η εγκατάσταση ξεκινά.


    Figure 11

    Έτσι τώρα έχουμε πλέον εγκαταστήσει τον DPM 2010.


    Figure 12

    Συμπέρασμα


    Ολοκληρώνοντας, με το συγκεκριμένο άρθρο καταδείξαμε ότι η εγκατάσταση του DPM 2010 με σκοπό να προστατεύσουμε Hyper-V R2
    servers και virtual machines είναι απλή και εύκολη διαδικασία. Στο επόμενο άρθρο το οποίο θα αφορά τον DPM 2010, θα παρουσιάσουμε τις ρυθμίσεις οι οποίες απαιτούνται έτσι ώστε να κάνουμε backup και recovery σε Hyper-V R2 servers και virtual
    machines.
  22. Jordan_Tsafaridis
    Γιά όσους ασχολούνται με συμόρφωση σύμφωνα με διεθνή πρότυπα (κανονιστικές αρχές - Sarbanes Oxley Act (SOX), Basel II, Solvency κ.τ.λ.), η Microsoft προσφέρει για download ένα πάρα πολύ χρήσιμο και δωρεάν εργαλείο γι'αυτόν το σκοπό το οποίο ονομάζεται Security Compliance Manager.
     
    Μπορείτε να το κατεβάσετε από το παρακάτω link :
     
    http://www.microsoft.com/downloads/details.aspx?FamilyID=5534bee1-3cad-4bf0-b92b-a8e545573a3e&displaylang=en
     
    Ελπίζω ότι θα σας φανεί χρήσιμο.
     




    Κύρια Χαρακτηριστικά και Δυνατότητες
    Centralized
    Management and Baseline Portfolio: Η κεντρική κονσόλα διαχείρισης του Microsoft Security Compliance Manager παρέχει στον χρήστη του συγκεκριμένου λογισμικού μια ενοποιημένη επιφάνεια εργασίας διαμέσου της οποίας είμαστε σε θέση να σχεδιάζουμε, να παραμετροποιημούμε και να εξάγουμε κανόνες ασφαλείας σύμφωνα με τις ανάγκες του οργανισμού, όπως αυτές καθορίζονται από το κανονιστικό πλαίσιο το οποίο έχουμε επιλέξει προς συμόρφωση.Το συγκεκριμένο εργαλείο μας παρέχει πρόσβαση σε όλο το φάσμα του λογισμικού της Microsoft.
    Security Baseline Customization: Η παραμετροποίηση, η σύγκριση, η συνένωση, ο έλεγχος αξιοπιστίας και η διαχείριση των κανόνων αλλά και της πολιτικής ασφάλειας ενός οργανισμούς γίνεται με τον πλέον φιλικό προς τον χρήστη τρόπο.
    Multiple Export
    Capabilities: Επιτρέπει την εξαγωγή των κανόνων ασφαλείας σε μορφή αρχείου XLS, Group Policy objects
    (GPOs), Desired Configuration Management (DCM) packs, ή Security
    Content Automation Protocol (SCAP).

    Παρακάτω σας παρουσιάζω την εγκατάσταση του συγκεκριμένου λογισμικού βήμα προς βήμα :
     

    Απαιτεί την ύπαρξη του Microsoft SQL Server διαφορετικά εγκαταστεί αυτόματα τον Microsoft SQL Server Express :
     

    Μετά την ολοκλήρωση της εγκατάστασης γίνεται αυτόματη ενημέρωση με τα τελευταία updates τα οποία είναι διαθέσιμα:
     

    Ακολουθεί η εισαγωγή των βασικών
    ρυθμίσεων ασφαλείας επιλέγοντας από μια σειρά τυπικών ρόλων.


    Και, τέλος, το πρώτο συμπέρασμα είναι ότι για να
    εξοικειωθεί κάποιος με τις δυνατότητες του λογισμικού αυτού χρειάζεται ένα ελεύθερο απόγευμα:
     
     
  23. Jordan_Tsafaridis
    Ημερομηνία Δημοσίευσης : Τρίτη 30 Μαρτίου 2010
     
    This bulletin summary lists security bulletins released for March 2010.
     
    The full version of the Microsoft Security Bulletin Summary for March 2010 can be found at http://www.microsoft.com/technet/security/bulletin/ms10-mar.mspx.
     
    With the release of the out-of-band security bulletin on March 30, 2010, this revised bulletin summary replaces the out-of-band bulletin advance notification originally issued on March 29, 2010.
     
    The revised bulletin summary Web page includes the out-of-band security bulletin as well as the security bulletins already released on March 9, 2010.
     
    For more information about the bulletin advance notification service, see http://www.microsoft.com/technet/security/Bulletin/advance.mspx.
     
    To receive automatic notifications whenever Microsoft Security Bulletins are issued, subscribe to Microsoft Technical Security Notifications on http://www.microsoft.com/technet/security/bulletin/notify.mspx.
     
    Microsoft will host a webcast to address customer questions on the out-of-band security bulletin on Tuesday, March 30, 2010, at 1:00 PM Pacific Time (US & Canada). Register for the Security Bulletin Webcast at http://www.microsoft.com/technet/security/bulletin/summary.mspx.
     
    Microsoft also provides information to help customers prioritize monthly security updates with any non-security, high-priority updates that are being released on the same day as the monthly security updates. Please see the section, Other Information.
     
     
    Critical Security Bulletins
    ===========================
     
    Microsoft Security Bulletin MS10-018
     
      - Affected Software:
      - Affected Software:
        - Internet Explorer 5.01 Service Pack 4 when installed on
          Microsoft Windows 2000 Service Pack 4
        - Internet Explorer 6 Service Pack 1 when installed on
          Microsoft Windows 2000 Service Pack 4
        - Internet Explorer 6 for
          Windows XP Service Pack 2 and
          Windows XP Service Pack 3
        - Internet Explorer 6 for
          Windows XP Professional x64 Edition Service Pack 2
        - Internet Explorer 6 for
          Windows Server 2003 Service Pack 2
        - Internet Explorer 6 for
          Windows Server 2003 x64 Edition Service Pack 2
        - Internet Explorer 6 for
          Windows Server 2003 with SP2 for Itanium-based Systems
        - Internet Explorer 7 for
          Windows XP Service Pack 2 and
          Windows XP Service Pack 3
        - Internet Explorer 7 for
          Windows XP Professional x64 Edition Service Pack 2
        - Internet Explorer 7 for
          Windows Server 2003 Service Pack 2
        - Internet Explorer 7 for
          Windows Server 2003 x64 Edition Service Pack 2
        - Internet Explorer 7 for
          Windows Server 2003 with SP2 for Itanium-based Systems
        - Internet Explorer 7 in
          Windows Vista,
          Windows Vista Service Pack 1, and
          Windows Vista Service Pack 2
        - Internet Explorer 7 in
          Windows Vista x64 Edition,
          Windows Vista x64 Edition Service Pack 1, and
          Windows Vista x64 Edition Service Pack 2
        - Internet Explorer 7 in
          Windows Server 2008 for 32-bit Systems and
          Windows Server 2008 for 32-bit Systems Service Pack 2
          (Windows Server 2008 Server Core installation not affected)
        - Internet Explorer 7 in
          Windows Server 2008 for x64-based Systems and
          Windows Server 2008 for x64-based Systems Service Pack 2
          (Windows Server 2008 Server Core installation not affected)
        - Internet Explorer 7 in
          Windows Server 2008 for Itanium-based Systems and
          Windows Server 2008 for Itanium-based Systems Service Pack 2
        - Internet Explorer 8 for
          Windows XP Service Pack 2 and
          Windows XP Service Pack 3
        - Internet Explorer 8 for
          Windows XP Professional x64 Edition Service Pack 2
        - Internet Explorer 8 for
          Windows Server 2003 Service Pack 2
        - Internet Explorer 8 for
          Windows Server 2003 x64 Edition Service Pack 2
        - Internet Explorer 8 in
          Windows Vista,
          Windows Vista Service Pack 1, and
          Windows Vista Service Pack 2
        - Internet Explorer 8 in
          Windows Vista x64 Edition,
          Windows Vista x64 Edition Service Pack 1, and
          Windows Vista x64 Edition Service Pack 2
        - Internet Explorer 8 in
          Windows Server 2008 for 32-bit Systems and
          Windows Server 2008 for 32-bit Systems Service Pack 2
          (Windows Server 2008 Server Core installation not affected)
        - Internet Explorer 8 in
          Windows Server 2008 for x64-based Systems and
          Windows Server 2008 for x64-based Systems Service Pack 2
          (Windows Server 2008 Server Core installation not affected)
        - Internet Explorer 8 in
          Windows 7 for 32-bit Systems
        - Internet Explorer 8 in
          Windows 7 for x64-based Systems
        - Internet Explorer 8 in
          Windows Server 2008 R2 for x64-based Systems
          (Windows Server 2008 Server Core installation not affected)
        - Internet Explorer 8 in
          Windows Server 2008 R2 for Itanium-based Systems
     
        - Impact: Remote Code Execution
        - Version Number: 1.0
  24. Jordan_Tsafaridis
    Με τον Forefront Identity Manager και σε συνδυασμό με το Active Directory, έχουμε μια  πλήρη λύση όσον αφορά την διαχείριση της ταυτότητας και της πρόσβασης των χρηστών σε ένα εταιρικό ή άλλης μορφής δίκτυο.
     
    Με τον ForeFront Identity Manager ο οποίος είναι ο διάδοχος του Identity Lifecycle Manager 2007 η Microsoft και πάλι πρωτοπορεί.
     
    περισσότερες πληροφορίες στο παρακάτω link :
     
    http://www.microsoft.com/forefront/identitymanager/en/us/default.aspx
     
  25. Jordan_Tsafaridis
    Εισαγωγή
    Ο σκοπός αυτού του άρθρου ειναι να παρουσιάσουμε το πως μπορούμε να χρησιμοποιήσουμε τα Microsoft Forefront TMG network templates, καθώς επίσης και τον τρόπο με τον οποίο μπορούμε να δημιουργήσουμε επιπλέον δίκτυα (additional networks). Τέλος θα παρουσιάσουμε και την μεθοδολογία με την οποία μπορούμε να παραμετροποιήσουμε τις ρυθμίσεις δικτύου του Forefront TMG (Customizing TMG network settings). 

    Ας Ξεκινήσουμε
    Ο Forefront TMG χρησιμοποιεί το πρότυπο του πολλαπλού δικτύου (concept of multi networking). Για να καθορίσουμε την τοπολογία δικτύου μπορούμε να δημιουργήσουμε δίκτυα μέσα στον Forefront TMG. Εφόσον όλα τα απαραίτητα δίκτυα έχουν δημιουργηθεί, τότε είναι δυνατόν χρησιμοποιώντας δύο τύπων κανόνες δικτύου (Networking Rules) να φέρουμε σε επικοινωνία - συσχετισμό τα δημιουργηθέντα δίκτυα μεταξύ τους. Ο Forefront TMG υποστηρίζει τους παρακάτω δύο τύπους κανόνων δικτύου :
     

    Route – Ο δικτυακός κανόνας του τύπου Route καθορίζει – εφαρμόζει μια δικτυακή σύνδεση διπλής κατεύθυνσης (bidirectional network connection) μεταξύ δύο δικτύων η οποία επιτρέπει την διαμεταγωγή δεδομένων χρησιμοποιώντας τις αυθεντικές διευθύνσεις IP μεταξύ αυτών των δικτύων. NAT - Ο δικτυακός κανόνας του τύπου NAT (Network Address Translation) εφαρμόζει μια δικτυακή σύνδεση μονής κατεύθυνσης μεταξύ δύο δικτύων, ο οποίος εφαρμόζει μάσκες στις διευθύνσεις IP από το τμήμα δικτύου με τη διεύθυνση IP του προσαρμογέα δικτύου που αντιστοιχεί Forefront TMG. Αφότου τα Δίκτυα και οι Κανόνες δικτύου έχει δημιουργηθεί, θα πρέπει να δημιουργήσουμε τους κανόνες Firewall οι οποίοι επιτρέπουν ή δεν επιτρέπουν την κυκλοφορία δεδομένων δικτύου (network traffic) μεταξύ των συνδεδεμένων δικτύων.
    Network templates
    Για να διευκολυνθεί η διαμόρφωση του Forefront TMG, ο TMG προβλέπει την δημιουργία δικτυακών προτύπων τα οποία επιτρέπουν τη δημιουργία τυπικών σεναρίων Firewall. Βεβαίως είναι δυνατόν να αλλάξει ο σχεδιασμός του δικτύου αναπάσα στιγμή μετά την αρχική εγκατάσταση. Το μόνο που έχετε να κάνετε είναι να ξεκινήσει η Getting Started Wizard στο TMG κονσόλα διαχείρισης. Το παρακάτω screenshot δείχνει την εκκίνηση Ξεκινώντας θέση οδηγού. 
     
    Εικόνα 1: Forefront TMG Getting Started Wizard
     

    Διαμορφώσετε τις ρυθμίσεις δικτύου
    Με την εκκίνηση του οδηγού - Getting Started Wizard – ο TMG μας επιτρέπει να επιλέξουμε το απαιτούμενο δικτυακό πρότυπο. Ο Forefront TMG έρχεται με 4 templates δικτύου : 

        Edge Firewall     3-Leg perimeter     Back firewall     Single network Adapter
    Edge Firewall
    Το πρότυπο (Template) δικτύου Edge Firewall είναι ένα κλασικό πρότυπο δικτύου και συνδέει το εσωτερικό δίκτυο με το Διαδίκτυο, τα οποία προστατεύονται από τον Forefront TMG. Χαρακτηριστικό του προτύπου Edge Firewall είναι ότι απαιτεί τουλάχιστον δύο προσαρμογείς δικτύου για την Forefront TMG Server.
    3-Leg Perimeter
    Το πρότυπο (Template)  δικτύου 3-Leg Perimeter Firewall αποτελεί έναν Forefront TMG Server με τρεις ή περισσότερους προσαρμογείς δικτύου. Ένας προσαρμογέας δικτύου συνδέει το εσωτερικό δίκτυο, ένας προσαρμογέας δικτύου που συνδέεται με το εξωτερικό δίκτυο, και ένας προσαρμογέας δικτύου που συνδέεται με την DMZ (αποστρατικοποιημένη ζώνη), που ονομάζεται επίσης και περιμετρικό δίκτυο. Το Περιμετρικό δίκτυο περιλαμβάνει υπηρεσίες, οι οποίες θα πρέπει να είναι προσβάσιμες από το Internet, αλλά ταυτόχρονα προστατεύεται από τον Forefront TMG. Τυπικές υπηρεσίες στην DMZ είναι Web Servers, DNS Servers ή WLAN δικτύων. Το πρότυπο 3-Leg Perimeter Firewall επίσης συχνά ονομάζεται "Firewall του φτωχού", επειδή δεν είναι μια "πραγματική" DMZ. Μια αληθινή DMZ είναι η ζώνη μεταξύ δύο διαφορετικών εμπορικών σημάτων Firewall (π.χ. Cisco, FortiNet).
    Backfirewall
    Το πρότυπο (Template)  δικτύου Back Firewall  μπορεί να χρησιμοποιηθεί από τον Administrator  του Forefront TMG, όταν ο ForeFront TMG βρίσκεται πίσω από ένα Front Firewall. Το Back Firewall προστατεύει το εσωτερικό δίκτυο από την πρόσβαση από την DMZ και το εξωτερικό δίκτυο καθώς επίσης ελέγχει την κίνηση στο δίκτυο η οποία επιτρέπεται από τους DMZ hosts και από τον Front Firewall. Σημείωση :
    Ο Forefront TMG δεν περιλαμβάνει κανενός είδους πρότυπο δικτύου (network template) Front Firewall.

    Single Network Adapter
    Το πρότυπο (Template)  δικτύου Single Network Adapter έχει κάποιους περιορισμούς, επειδή αποτελεί έναν Forefront TMG server με μια και μόνη διεπαφή δικτύου, και δεν μπορεί να χρησιμοποιηθεί ως ένα πραγματικό τείχος προστασίας, με συνέπεια πολλές υπηρεσίες δεν είναι διαθέσιμες. Μόνο τα ακόλουθα χαρακτηριστικά είναι διαθέσιμα:
    Προωθώντας  Web Proxy αιτήματα μεσολάβησης που χρησιμοποιούν HTTP, Secure HTTP (HTTPS), ή File Transfer Protocol (FTP) για downloads Cache περιεχόμενο στον Παγκόσμιο Ιστό (Cache Web content) για χρήση από τους πελάτες σχετικά με το εταιρικό δίκτυο Web Publishing με σκοπό να συμβάλει στην προστασία δημοσιευμένων Web ή FTP servers Microsoft Outlook Web Access, το ActiveSync, και κλήση απομακρυσμένης διαδικασίας (RPC) μέσω HTTP εκδόσεων (που ονομάζεται επίσης Outlook Anywhere στον Exchange Server 2007 και άνω)   Εικόνα 2: Επιλογή δικτυακού προτύπου
     
    Ως επόμενο βήμα, επιλέξτε το προσαρμογείς δικτύου που θα πρέπει να χρησιμοποιούνται για το δίκτυο αυτό το πρότυπο. Για αυτό το παράδειγμα χρησιμοποιείται το Edge Firewall πρότυπο κι επομένως θα πρέπει να επιλέξετε τον προσαρμογέα δικτύου που συνδέεται με το LAN και τον προσαρμογέα δικτύου που συνδέεται με το εξωτερικό (μη αξιόπιστο) δίκτυο.
     
     
    Εικόνα 3: Επιλογή προσαρμογέα δικτύου
     
    Στον Forefront TMG είναι πλέον δυνατόν να καθορίσετε πρόσθετες γραμμές του δικτύου με το UI. Δεν χρειάζεται να χρησιμοποιήσετε την εντολή Route add από τη γραμμή εντολών. Το παρακάτω screenshot δείχνει την προεπιλογή των δικτύων που δημιουργούνται από την εγκατάσταση του Microsoft Forefront TMG. Μόνο το εσωτερικό δίκτυο έχει τη δυνατότητα να ρυθμίσει τις περιοχές διευθύνσεων IP.
     
     
    Εικόνα 4: Forefront TMG δίκτυα
     
    Ο Forefront TMG έρχεται με ενσωματωμένους ορισμένους κανόνες δικτύου που καθορίζουν τις σχέσεις μεταξύ των δικτύων.
     

    Εικόνα 5: Forefront TMG – Δικτυακοί κανόνες
     
    Επίσης, νέο στοιχείο στον Microsoft Forefront TMG είναι η ενσωματωμένη δυνατότητα να καθορίζει ο χρήστης κάποιες βασικές ρυθμίσεις του προσαρμογέα δικτύου, όπως οι διευθύνσεις IP, Default Gateways και περισσότερο.
     

    Εικόνα 6: Forefront TMG – Προσαρμογείς δικτύου
     
    Το παρακάτω screenshot δείχνει τις επιλογές διαμόρφωσης για τους προσαρμογείς δικτύου του TMG.
     

    Εικόνα 7: Forefront TMG – Ιδιότητες διευθύνσεων IP.
     
    Με τον Forefront TMG είναι πλέον δυνατόν να δημιουργηθούν νέες γραμμές δικτύου (new network routes), κάνοντας χρήση της κονσόλα διαχείρισης του TMG.
     

    Εικόνα 8: Forefront TMG Network routes
     
    Το παρακάτω screenshot δείχνει ένα παράδειγμα δημιουργίας μιας νέας διαδρομής  στην υπάρχουσα τοπολογία δικτύου και η λειτουργία αυτή γίνεται στο παράθυρο διαλόγου με τίτλο : Network Topology Route.
     

    Εικόνα 9: Forefront TMG – Δημιουργία νέας διαδρομής  στην υπάρχουσα τοπολογία δικτύου.
     

    Νέα δίκτυα στον TMG
    Είναι δυνατόν να δημιουργηθούν επιπλέον δίκτυα στον Forefront TMG. Ο Forefront TMG έρχεται με ενσωματωμένο οδηγό για τη δημιουργία νέων δικτύων.  

    Εικόνα 10: Forefront TMG – Νέο όνομα δικτύου
     
    Νέα δίκτυα μπορούν να δημιουργηθούν για διάφορους τομείς. Για παράδειγμα, είναι δυνατόν να δημιουργηθεί ένα νέο δίκτυο για επιπλέον DMZ στον Microsoft Forefront TMG.
     

    Εικόνα 11: Forefront TMG – Καθορισμός τύπου δικτύου
     
    Προσδιορίστε το εύρος διευθύνσεων IP για το νέο δίκτυο.
     

    Εικόνα 12: Forefront TMG – Εύρος διευθύνσεων IP
     
    Αφότου το νέο δίκτυο έχει δημιουργηθεί, θα πρέπει να συνδέσουμε το νέο δίκτυο με έναν υπάρχον κανόνα δικτύου ή αντίστοιχα είναι δυνατόν να δημιουργήσουμε έναν νέο σχεσιακό κανόνα δικτύου τύπου Route ή NAT.
     

    Εξάγωγή και εισαγωγή ρυθμίσεων δικτύου
    Είναι δυνατόν να εξάγουμε όλες τις ρυθμίσεις του Forefront TMG (Forefront TMG networks and network settings) σε ένα αρχείο XML με τις ενσωματωμένες δυνατότητες εισαγωγής και εξαγωγής του Forefront TMG.  

    Εικόνα 13: Forefront TMG – Εξαγωγή και εισαγωγή ρυθμίσεων δικτύου
     

    Συμπέρασμα
    Σε αυτό το άρθρο, προσπάθησα να σας δώσω μια γενική εικόνα σχετικά με τον τρόπο χρήσης των δικτύων, των προτύπων δικτύων και των κανόνων δικτύου του Forefront TMG με σκοπό να δημιουργήσετε την δική σας τοπολογία δικτύου με τον TMG. Όπως έχετε δει σε αυτό το άρθρο είναι πολύ εύκολο να δημιουργήσετε μια τοπολογία του δικτύου με τη βοήθεια των προτύπων δικτύου. Ο Forefront TMG έχει μερικές χρήσιμες βελτιώσεις που σχετίζονται με τη διαμόρφωση του δικτύου. Είναι ένα καλό χαρακτηριστικό γνώρισμα ότι είναι πλέον δυνατόν για τους διαχειριστές του TMG να δημιουργούν διαδρομές δικτύου με την κονσόλα διαχείρισης του TMG και ότι επίσης είναι δυνατόν να ρυθμίσετε μερικές βασικές ρυθμίσεις των διευθύνσεων IP με την κονσόλα του TMG. Οι περισσότερες από τις υπόλοιπες ρυθμίσεις παρέμειναν αμετάβλητες σε σύγκριση με τον Microsoft ISA Server 2006. 
     
×
×
  • Create New...