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
    Εισαγωγή
    Ο ISA Firewall ήταν διαθέσιμος στην αγορά πληροφορικής για ένα αρκετά μεγάλο χρονικό διάστημα. Αρκετοί ISA Firewall Administrators, τον χρησιμοποίησαν σε πλήρη παραγωγική χρήση ήδη από την beta phase του
    ISA 2000, όταν ήταν γνωστός με την κωδική ονομασία “Comet” πίσω στο έτος 2000. Για τα επόμενα δέκα έτη, χιλιάδες ISA firewall admins υιοθέτησαν και εργάστηκαν με τον ISA firewall και προχώρησαν στην επόμενη έκδοσή του. Μετά τον ISA 2000 παρουσιάστηκε ο ISA 2004 και δύο χρόνια αργότερα παρουσιάστηκε ο ISA 2006. Ο ISA 2004 αποτέλεσε μια ριζική ανανέωση σε σχέση με τον ISA 2000 firewall, γεγονός το οποίο καθιέρωσε τον ISA 2004 στην αγορά πληροφορικής αντάξιο όλων των enterprise network firewalls. Ο ISA 2006 αποτέλεσε θα μπορούσε να πει κανείς μια “R2” release, περιλαμβάνοντας κυρίως βελτιώσεις των web proxy components του firewall.

    Το 2010, η καινούρια έκδοση του ISA Firewall όχι μόνον περιλάμβανε σημαντικά - επαναστατικά νέα χαρακτηριστικά και δυνατότητες, αλλά συνάμα και την μετονομασία του πλέον σε TMG – the Threat Management Gateway 2010. Σύμφωνα δε την Microsoft όπως προκύπτει από τα στοιχεία πωλήσεων του συγκεκριμένου προϊόντος, εξαιρετικό ενδιαφέρον έχει το γεγονός ότι μετά την έναρξη κυκλοφορίας του TMG firewall, υπάρχουν πολλοί νέοι TMG firewall admins οι οποίοι στο παρελθόν ουδέποτε είχαν χρησιμοποιήσει τον ISA firewall. Οι περισσότεροι από αυτούς τους admins απαξιώνουν τα παλαιά
    “hardware” firewalls διότι πολύ απλά το κόστος συντήρησής του είναι εξαιρετικά υψηλό με αποτέλεσμα να μην λειτουργεί προς όφελος της επιχείρησης ιδιαίτερα δε σε συνθήκες οικονομικής κρίσης. Ακόμη περισσότερο ενδιαφέρον παρουσιάζει επίσης το γεγονός της μετακίνησης στον TMG Firewall, διότι λόγω της συσσωρευμένης εμπειρίας ετών την οποία έχουν αποκτήσει οι Firewall Admins σε σχέση με το παρελθόν, διαπιστώνουν ότι τα επονομαζόμενα hardware firewalls σε πολλές περιπτώσεις, είναι υποδεέστερα σε ασφάλεια σε σύγκριση με τον TMG firewall. Αυτό αποτελεί μια σημαντική εξέλιξη, η οποία υποδειλώνει την αλλαγή στη νοοτροπία της Microsoft, ενώ ταυτόχρονα είναι μια απόδειξη για την αποτελεσματικότητα του Microsoft’s
    Security Development Lifecycle, στοιχείο το οποίο άλλαξε εντελώς τον τρόπο με τον οποίο η Microsoft δημιούργησε το λογισμικό επικεντρώνοντας στην ασφάλεια σε κάθε φάση της ανάπτυξης
    του λογισμικού.

    Αν και υπάρχει σημαντικός όγκος αρθρογραφίας στο διαδίκτυο σχετικά με τον ISA, TMG Firewall, όπου παρουσιάζονται διεξοδικά περίπλοκες εγκατστάσεις, παρόλα αυτά γι' συτόν που ασχολείται συστηματικά με το συγκεκριμένο λογισμικό υπάρχει απαίτηση για αναλυτική παρουσίαση των βασικών χαρακτηριστικών από administrators οι οποίοι θέλουν να χρησιμοποιήσουν τον TMG Firewall.
     

    Είναι χαρακτηριστικό να αναφέρουμε ότι υπάρχει πρόβλημα όσον αφορά την αρθρογραφία σχετικά με το outbound access. Πάρα πολλοί νέοι TMG firewall admins έχουν εστιάσει την προσοχή τους στο
    inbound access control (π.χ., control access του Exchange και του
    SharePoint). Τώρα όμως θέλουν να αποκτήσουν τεχνογνωσία όσον αφορά το control access των outbound connections. Αυτό θα είναι και το θέμα του συγκεκριμένου άρθρου πάνω στα Access
    Rules.

    Κατανοώντας τα Access Rules

    Τα Access Rules χρησιμοποιούνται για τον έλεγχο του control outbound access σε ένα δίκτυο το οποίο προστατεύεται από τον TMG
    firewall. Όταν θέλουμε να επιτρέψουμε σε έναν Η/Υ πίσω από τον TMG firewall να έχει πρόσβαση σε ένα άλλο δίκτυο (συμπεριλαμβανομένου και του Internet), τότε είναι απαραίτητο να δημιουργήσουμε ένα Access Rule έτσι ώστε να επιτραπείο αυτή η σύνδεση. Εξ ορισμού, δεν υπάρχει κανένας
    Access Rules τα οποία επιτρέπουν συνδέσεις διαμέσου του firewall. Αυτή η εξ ορισμού κλειστή κατάσταση αποτελεί την βέλτιστη από πλευράς ασφάλειας ρύθμιση (configuration), αλλά ταυτόχρονα σημαίνει ότι εφόσον θέλουμε να επιτρέψουμε κίνηση (traffic) διαμέσου του TMG firewall, θα πρέπει να κατανοήσουμε πλήρως πως δουλεύουν τα Access
    Rules και πως τα δημιουργούμε.

    Δημιουργώντας έναν Outbound Access Rule
    Για να ξεκινήσουμε, θα δημιουργήσουμε έναν απλό outbound access rule, ο οποίος επιτρέπει σε όλους τους χρήστες να έχουν outbound access στο Internet χρησιμοποιώντας όλα τα πρωτόκολα επικοινωνίας. Στο επόμενο άρθρο θα παρουσιάσουμε με λεπτομέρεια τα
    Access Rules και θα παρουσιάσουμε ποιες είναι οι εξαρτήσεις (dependencies) των Access Rules και τον τρόπο με τον οποίο μπορούμε να τις διαχειριστούμε.

    Ας ξεκινήσουμε εκιννώντας την TMG firewall console. Εν συνεχεία κάνουμε κλικ στο Firewall Policy node στην αριστερή πλευρά της console, όπως παρουσιάζεται στην παρακάτω εικόνα 1.


    Εικόνα 1

    Αφού κάνουμε κλικ στο Firewall Policy, κάνουμε κλικ στο Tasks
    Tab στο δεξιό μέρος της console. Εδώ υπάρχει μια σειρά επιλογών (options), οι περισσότερες των οποίων σχετίζονται με την δημιουργία διαφόρων firewall rules. Στο συγκεκριμένο παράδειγμα, θέλουμε να δημιουργήσουμε ένα Access Rule το οποίο θα επιτρέπει το outbound
    access διαμέσου του TMG firewall. Για τον λόγο αυτό κάνουμε κλικ στο Create Access Rule link για να ξεκινήσει το Access Rule wizard, όπως αυτό παρουσιάζεται στην εικόνα 2 παρακάτω.


    Εικόνα 2

    Στην σελίδα Welcome to the New Access Rule Wizard, εισάγουμε ένα χαρακτηριστικό όνομα στο Access Rule name
    text box. Μιλώντας γενικά, θα πρέπει να χρησιμοποιούμε ένα σύστημα βάση του οποίου όλα τα Access Rules θα έχουν ονόματα τα οποία θα υποδηλώνουν τι κάνουν, έτσι ανά πάσα στιγμή να είμαστε σε θέση να γνωρίζουμε σε μια firewall policy ποιος είναι ο σκοπός του κάθε κανόνα. Σε αυτό το παράδειγμα, θα ονοματήσουμε τον κανόνα ως All Open 1.
    Σαφέστατα σε ένα παραγωγικό περιβάλλον, δεν θα θέλαμε να δημιουργήσουμε έναν κανόνα της μορφής αυτής διότι πολύ απλά ο κανόνας αυτός θα επιτρέψει σε όλους ανεξαιρέτως τους χρήστες και τους υπολογιστές να έχουν outbound
    access στο internet και είναι πολύ πιθανόν να μην αυτό το οποίο επιθυμούμε για ένα παραγωγικό περιβάλλον.


    Εικόνα 3

    Στην σελίδα Rule Action, μας παρέχεται η δυνατότητα ορίσουμε τον κανόνα ως Allow ή Deny
    rule. Σημειώστε ότι εξ ορισμού δημιουργούμε έναν Deny rule, στοιχείο το οποίο αποτελεί καλή ιδέα κάτω από το πρίσμα της ασφάλειας. Συνεπώς θα αλλάξουμε την κατάσταση από Deny σε Allow πριν κάνουμε κλικ στο Next έτσι ώστε να γίνει ο κανόνας μας ένας Allow rule.


    Εικόνα 4

    Στην σελίδα των Protocols, επιλέγουμε τα πρωτόκολα στα οποία ο κανόνας αυτός πόκειται να εφαρμοστεί. Στο This rule applies to drop down box, έχουμε τις παρακάτω τρεις επιλογές :

    All outbound traffic - Χρησιμοποιούμε αυτήν την επιλογή εφόσον θέλουμε ο κανόνας μας να έχει εφαρμογή σε όλα τα πρωτόκολα.
    Selected protocols - Χρησιμοποιούμε αυτήν την επιλογή εφόσον θέλουμε να επιλέξουμε συγκεκριμένα πρωτόκολα, στα οποία πρόκειται να εφαρμοστεί ο κανόνας μας. All outbound traffic except selected - Χρησιμοποιούμε αυτήν την επιλογή εφόσον θέλουμε επιτρέπουμε ή να μην επιτρέπουμε (to allow or deny) όλα τα πρωτόκολα εκτός από ένα υποσύνολο αυτών τα οποία επιλέγουμε στην συγκεκριμένη σελίδα.

    Εικόνα 5

    Εάν επιλέξουμε την δεύτερη ή την τρίτη επιλογή, τότε κάνουμε κλικ στο Add button για να επιλέξουμε τα πρωτόκολα στα οποία θέλουμε ο κανόνας αυτός να έχει εφαρμογή. Αφού κάνουμε κλικ στο Add button, θα μας έρθει στο προσκήνιο το πλαίσο διαλόγου Add Protocols. Όταν κάνουμε κλικ σε έναν φάκελο σε αυτό το πλαίσιο διαλόγου, ο φάκελος ανοίγει παρουσιάζοντας μια λίστα των πρωτοκόλων. Η ομάδα ανάπτυξης του TMG firewall για να διευκολύνει το έργο μας διαχώρισε τα πρωτόκολα σε νοηματικές ομάδες (meaningful groups) έτσι ώστε να είναι ευκολότερο για εμάς να βρίσκουμε το-α συγκεκριμένο-α πρωτόκολο-α που μας ενδιαφέρει. Κάνουμε διπλό κλικ στα πρωτόκολα στα οποία θέλουμε να επιτρέψουμε την πρόσβαση και αυτά θα εμφανιστούν στην σελίδα Protocols στο Protocols list.


    Εικόνα 6

    Υπάρχει μια ακόμη επιλογή στην οποία έχουμε πρόσβαση στην σελίδα αυτή, και εμφανίζεται εάν κάνουμε κλικ στο Source Ports button. Αυτό εμφανίζει στο προσκήνιο το Source Ports dialog box. Εδώ μας δίνεται η δυνατότητα ελέγχου των επιτρεπόμενων source ports οι οποίες αναφέρονται στις συνδέσεις του συγκεκριμένου κανόνα. Εξ ορισμού είναι επιλεγμένο το Allow traffic from any allowed source port , αλλά εάν θέλουμε να κάνουμε κλείδωμα (lock down) στα source ports, μπορούμε να επιλέξουμε το Limit access to traffic from this range of source ports και εν συνεχεία εισάγουμε τιμές (values) στα From και To text boxes για να υποδηλώσουμε αυτά τα source ports.


    Εικόνα 7

    Στην συγκεκριμένη χρονική στιγμη δεν θα επιλέξουμε καμία ειδικά specific source ports.  Θα επιλέξουμε την επιλογή All outbound traffic και εν συνεχεία κάνουμε κλικ στο Next.

    Η επόμενη σελίδα είναι η σελίδα Access Rule Sources. Εδώ μπορούμε να επιλέξουμε την τοποθεσία (location) στην οποία βρίσκονται οι υπολογιστές πίσω από τον TMG firewall στους οποίους θέλουμε αυτός ο κανόνας να εφαρμοστεί. Κάνουμε κλικ στο Add button και εν συνεχελια θα εμφανιστεί το Add Network Entities
    dialog box. Κάνουμε κλικ στον φάκελο ο οποίος περιέχει  το network element το οποίο υποδηλώνει την πηγαία τοποθεσία (source location) των υπολογιστών στους οποίους θέλουμε αυτός ο κανόνας να εφαρμοστεί. Στο παράδειγμα αυτό, θα ρυθμίσουμε τον κανόνα αυτό να έχει εφαρμογή σε όλους τους υπολογιστές οι οποίοι βρίσκονται στο εσωτερικό δίκτυο (Internal Network), κάνοντας κλικ στο φάκελο
    Networks και εν συνεχεία κάνουμε διπλό κλικ στο Internal Network.


    Εικόνα 8

    Αφού επιλέξουμε το source Network ως το εξ ορισμού Internal Network κάνοντας κλικ στο Next, θα εμφανιστεί η επόμενη σελίδα, η οποία είναι η Access Rule Destinations. Εδώ καθορίζουμε τον-ους προορισμό-ούς (destinations) στους οποίους θέλουμε οι υπολογιστές από την πηγαία τοποθεσία (source location), τους οποίους είχαμε επιλέξει προηγουμένως να έχουν πρόσβαση διαμέσου του συγκεκριμένου κανόνα. Η σελίδα Access Rule Destinations λειτουργεί όπως και η προηγούμενη σελίδα, όπου κάνουμε κλικ στο Add button και εν συνεχεία στο εμφανιζόμενο Add Network Entities
    dialog box, κάνουμε κλικ στον φάκελο και αμέσως μετά διπλό κλικ στο στοιχείο του δικτύου (network
    element) για το οποίο θέλουμε να επιτρέψουμε την πρόσβαση χρησιμοποιώντας αυτόν τον κανόνα. Στο παράδειγμά μας θα επιλέξουμε το εξ ορισμού επιλεγμένο External network.


    Εικόνα 9

    Η επόμενη σελίδα του wizard είναι η σελίδα User Sets. Σε αυτήν την σελίδα καθορίζουμε τους χρήστες στους οποίους πρόκειται να εφαρμόσουμε αυτόν τον κανόνα. Εξ ορισμού τα Access Rules εφαρμόζονται σε όλους τους χρήστες. Τώρα ο ορισμός “all users” μπορεί να μην αντιστοιχεί σε αυτό το οποίο επιθυμούμε, σε σχέση με αυτό το οποίο καθορίζει ο TMG firewall ως όλοι οι χρήστες (all users). Το λογικό είναι ότι αναφερόμαστε με τον όρο “all users”, ο οποίος θα εφαρμοστεί σε όλους τους λογαριασμούς των χρηστών στον οργανισμό / επιχείριση στον οποίο εργαζόμαστε. Δυστυχώς είναι ΛΑΘΟΣ!!! Ο όρος “All users”
    όσον αφορά τον TMG firewall’s αναφέρεται στους ανώνυμους χρήστες (anonymous users) – με άλλα λόγια είναι μη εξουσιοδοτημένοι χρήστες, και επακριβώς αναφερόμαστε στα unauthenticated connections. Εάν κάνουμε κλικ στο Add button, μπορούμε να επιλέξουμε διαφορετικούς χρήστες, όπως οι All Authenticated Users ή το System and Network Service.
    Μπορούμε επίσης να δημιουργήσουμε custom user sets βασισμένα σε λογαριασμούς Active Directory ή
    RADIUS αντίστοιχα. Θα αναφερθούμε σε αυτό στο επόμενο άρθρο. Στο παράδειγμα αυτό θα επιλέξουμε την επιλογή All Users και εν συνεχεία κάνουμε κλικ στο Next για να συνεχίσουμε στην επόμενη σελίδα.


    Εικόνα 10

    Η τελευταία σελίδα του wizard είναι η σελίδα Completing the New Access Rule Wizard. Εδώ κάνουμε επισκόπηση των ρυθμίσεών μας και κάνουμε κλικ στο Finish.


    Εικόνα 11

    Αμέσως μετά την δημιουργία του κανόνα, αυτός δεν εφαρμόζεται παρά μόνον αφότου κάνουμε κλικ στο Apply button στην κορυφή του μεσαίου pane της TMG firewall console. Έτσι θα κάνουμε κλικ αμέσως στο Apply button.


    Εικόνα 12

    Επιπρόσθετες Επιλογές

    Αφότου κάνουμε κλικ στο Apply, τότε ενφανίζεται το Configuration Change Description
    dialog box. Στο σημείο μας παρέχεται η δυνατότητα προσθήκης περιγραφής της αλλαγής η οποία έλαβε χώρα όσον αφορά το firewall policy με συνέπεια αυτή να εμφανιστεί στο change log. το
    change log είναι εξαιρετικά χρήσιμο ιδαιτέρως όταν πρόκειται να ανατρέξουμε σε παλαιότερες ενέργειες οι οποίες πραγματοποιήθηκαν από κάποιον άλλον administrator και άλλαξαν το firewall policy με αποτέλεσμα το σύστημα να μην λειτουργεί όπως θα θέλαμε.

    Σημεώστε επίσης ότι έχουμε την επιλογή του back up του firewall policy κάνοντας κλικ στο Export
    button σε αυτό το σημείο. Αυτή η διαδικασία μας επιτρέπει να έχουμε πάντοτε διαθέσιμο ένα αντίγραφο ασφαλείας των ρυθμίσεων (backup of the
    configuration), έτσι ώστε να μπορούμε εύκολα να επιστρέψουμε πίσω στο σημείο που ήταν το σύστημα πριν από τις αλλαγές. Επιπροσθέτως έχουμε την επιλογή να μην εμφανιστεί το prompt ξανά στο μέλλον, κάτι το οποίο δεν το συνιστώ, διότι πολύ απλά θα διαπιστώσετε την χρησιμότητα αυτού του dialog box συνεχώς στο μέλον. Έτσι λοιπό κάνουμε κλικ στο Apply.


    Εικόνα 13

    Το Saving Configuration Changes dialog box εμφανίζεται αμέσως και μας κοινοποιεί ότι τα firewall policy settings αποθηκεύτηκαν στο configuration
    storage. Σημειώστε εδώ ότι την παρατήρηση που εμφανίζεται και λέει ότι Existing client connections will be
    reevaluated according to the new configuration. Client connections not
    matching the newly enforced policy will be dropped. Αυτό αποτελεί ένα καινούριο χαρακτηριστικό του TMG firewall. Με το ISA firewall, κάθε καινούρια firewall policy εφαρμόζεταισε νέες συνδέσεις και σε ήδη υπάρχουσες. Αυτό το στοιχείο από μόνο του αποτελεί σημαντική βελτίωση και αποτελεί από μόνο του λόγο για τον οποίο θα πρέπει να προχωρήσουμε στην αναβάθμιση από τον ISA firewall στον TMG firewall.


    Εικόνα 14

    Ο καινούριος κανόνας πλέον εμφανίζεται στο firewall policy list, όπως αυτό παρουσιάζεται στην παρακάτω εικόνα. Η θέση του στην λίστα εξαρτάται από το σημείο στο οποίο κάναμε κλικ όταν ξεκινησαμε τον wizard. Παρόλα αυτά, όπως θα σας παρουσιάσω στο επόμενο άρθρο μπορούμε να μετακινησουμε έναν κανονα πάνω ή κάτω στην λίστα αλλάζοντάς του την θέση του.


    Εικόνα 15

    Συμπέρασμα
    Ολοκληρώνοντας, σε αυτό το άρθρο σκοπός μου ήταν η παρουσιάση των βασικών χαρακτηριστικών των Access Rules για έναν νέο firewall admin. Οι Access Rules χρησιμοποιούνται για να ελέγχουν το traffic moving το οποίο εξέρχεται (outbound) από ένα προστατευμένο δίκτυο από τον TMG σε κάποιο άλλο δίκτυο. Εξ ορισμού δεν υπάρχουν Access Rules και κανένα traffic δεν διακινείται διαμέσου του TMG firewall. Ένας An Access Rule πρέπει να δημιουργηθεί για να επιτρέψει το outbound traffic. Οι Access Rules μας επιτρέπουν τον έλεγχο του traffic, βασιζόμενοι σε μια σειρά παραγόντων, όπως οι source location, destination location, οι χρήστες (users), και τα πρωτόκολα τα οποία χρησιμοποιούνται. Οπωσδήποτε υπάρχουν και άλλες επιλογές οι οποίες θα παρουσιαστούν στο επόμενο άρθρο.
  2. Jordan_Tsafaridis
    Εισαγωγή
    Στο πρώτο μέρος αυτής της σειράς τεχνικών άρθρων τα οποία αναφέρονται στα Access Rules, παρουσιάσα τον σκοπό και τις διαδικασίες για την δημιουργία ενός Access Rule καθώς και τον τρόπο χρήσης του Access Rule wizard για την δημιουργία ενός κανόνα.
    Στο δεύτερο αυτό μέρος θα δώσουμε έμφαση στις λεπτομέριες των Access Rules αφότου αυτοί έχουν δημιουργηθεί από τον wizard. Ο λόγος για τον οποίο θέλουμε να το κάνουμε αυτό είναι υπάρχει μια σειρά ρυθμίσεων η οποία δεν εμφανίζεται κατά την διάρκεια χρήσης του Access
    Rule wizard.

    Εάν κάνουμε διπλό κλικ σε ένα access rule αμέσως μετά την δημιουργία του, θα εμφανιστεί το Properties dialog box του συγκεκριμένου κανόνα. Το πρώτο tab το οποίο θα παρουσιαστεί είναι το General
    tab. Σε αυτό το σημείο μπορούμε να αλλάξουμε το όνομα του κανόνα (rule) και να συμπληρώσουμε επίσης και μια σύντομη περιγραφή του κανόνα. Θα ανακαλύψετε όπως και εγώ ότι το description box αποτελεί μια πραγματική βοήθεια, διότι σε αυτό μπορούμε να καταγράψουμε τον λόγο για τον οποίο δημιουργήσαμε τον συγκεκριμένο κανόνα, ποιος δημιουργήσε τον κανόνα, πότε δημιουργήθηκε ο κανόνας, αλλά επίσης και τον λόγο για τον οποίο δημιουργήσαμε τον κανόνα, όπως για παράδειγμα ποιος απαίτησε την δημιουργία του κανόνα ή ποιο επιχειρησιακό πρόβλημα ο κανόνας αυτός επιλύει.

    Σημειώστε ότι το Evaluation order περιλαμβάνεται σε αυτό το tab.
    Παρόλα αυτά, θα πρέπει να είμαστε προσεκτικοί διότι αυτό το evaluation order για την λίστα των firewall rules βρίσκεται εκτός (outside) από τα System Policy rules. Τα System Policy rules πάντοτε αξιολογούντε (evaluated) πριν την αξιολόγηση των firewall policy rules. Εδώ μπορούμε να ενεργοποιήσουμε ή να απενεργοποιήσουμε τον κανόνα χρησιμοποιώντας το Enable checkbox.


    Εικόνα 1

    Στο Action tab, έχουμε την παρακάτω σειρά επιλογών:

    Allow - Όταν επιλέγουμε αυτήν την επιλογή, τότε ο κανόνας μετατρέπεται σε έναν allow rule με συνέπεια όταν το connection attempt πιστοποιεί (matches) τις συγκεκριμένες ρυθμίσεις σε αυτόν τον κανόνα, τότε η σύνδεση είναι επιτρεπτή. (Τhe connection will be allowed)
    Deny - Όταν επιλέγουμε αυτήν την επιλογή, τότε ο κανόνας μετατρέπεται σε έναν κανόνα άρνησης (deny rule) με συνέπεια όταν το connection attempt πιστοποιεί (matches) τις συγκεκριμένες ρυθμίσεις σε αυτόν τον κανόνα, τότε η σύνδεση είναι
    μη επιτρεπτή. (Τηε connection will be denied)

    Display denial notification to user - Εάν ο κανόνας είναι ένας κανόνας HTTP, και επιλέξουμε αυτήν την επιλογή, έχουμε την δυνατότητα να εισάγουμε ένα κείμενο το οποίο θα κοινοποιείται στον χρήστη ενημερώνοντάς τον ότι η σύνδεση την οποία προσπάθησε να πραγματοποιήσει δεν επιτρέπεται. Η πληροφορία αυτή θα εμφανίζεται σε ένα browser window. Χρησιμοποιώντας αυτό το χαρακτηριστικό ο χρήστης θα είναι σε θέση να γνωρίζει γιατί η σύνδεση την οποία πήγε να πραγματοποιήσει δεν επιτράπηκε.
    Add denied request category to notification - Η επιλογή αυτή είναι διαθέσιμη όταν το URL filtering είναι ενεργοποιημένο εφόσον εάν έχουμε ενεργοποιήσει το URL filtering στον TMG firewall, έχοντας την δυνατότητα να ενημερώσουμε τον χρήστη, πότε το request δεν έγινε αποδεκτό, καθώς επίσης και σε ποια κατηγορία απαγορευμένων ιστοσελίδων προσπάθησε να μπει ο συγκεκριμένος χρήστης. Κατά γενική ομολογία οι χρήστες δεν ενδιαφέρονται γι' αυτήν την πληροφορία, αλλά εάν έχουμε κανόνες οι οποίοι απευθύνονται σε admins ή power users,
    τότε είναι πιθανόν γι' αυτούς τους χρήστες η πληροφορία αυτή να είναι ιδιαίτερα χρήσιμη έτσι ώστε να προχωρήσουν σε επανακατηγοριοποίηση των ιστοσελίδων.

    Redirect web client to the following URL - Εάν για κάποιο λόγο δεν επιθυμούμε να εμφανίσουμε μια ιστοσελίδα στην οποία να εξηγούμε στον χρήστη γιατί δεν επιτράπηκε η σύνδεσή του, εδώ έχουμε την επιλογή να ανακατευθύνουμε τον χρήστη (redirect the user) σε μια ιστοσελίδα της αρεσκείας μας.
    Τέτοια ιστοσελίδα μπορεί να είναι μια ιστοσελίδα στην οποία περιγράφονται οι κανονισμοί πρόσβασης και χρήσης του διαδικτύου στην συγκεκριμένη επιχείρηση στην οποία εργαζόμαστε.

    Log requests matching this rule - Αυτή η επιλογή είναι εξ ορισμού ενεργοποιημένη και επιτρέπει συνδέσεις οι οποίες είναι εναρμονισμένες με τον συγκεκριμένο κανόνα να γίνονται logged στα TMG firewall logs. Βεβαίως υπάρχουν και περιπτώσεις για τις οποίες δεν είναι απαραίτητη η καταγραφή πληροφορίας όπως τα επονομαζόμενα garbage traffic (NetBIOS broadcasts, LLMNR broadcasts, κ.τ.λ.). Αυτή η κίνηση θα έχει ως άμεση συνέπεια την σημαντική μείωση του όγκου των log files
    και θα μετατρέψει τα logs σε καθαρότερη και εύκολότερα αναγνώσιμη μορφή.


    Εικόνα 2

    Στην σελίδα Protocols, έχουμε επιλογές οι οποίες είναι παρόμοιες με αυτές οι οποίες περιλαμβάνονται στον Access Rule wizard. Το This rule applies to drop down box παρέχει τις ίδιες επιλογές, και μπορούμε να χρησιμοποιήσουμε τα Add, Edit και Remove buttons για να προσθέσουμε, να επεξεργαστούμε ή να αφαιρέσουμε protocols τα οποία θα βρίσκουν εφαρμογή σε αυτόν τον κανόνα. Επιπροσθέτως έχουμε το Ports option το οποίο ήταν διαθέσιμο. Το Filtering button, όταν ενεργοποιηθεί, μας επιτρέπει να ρυθμίσουμε το HTTP Policy
    γι'αυτόν τον κανόνα (Εάν αυτός είναι ένας κανόνας HTTP). Αυτό το χαρακτηστικό περιλαμβανόταν και σε παλαιότερες εκδόσεις του ISA firewall, το οποίο ήυαν ευρέως γνωστό ως HTTP Security Filter. Άλλα φίλτρα μπορούν να είναι διαθέσιμα - αναλόγως των πρωτόκολων τα οποία χρησιμοποιούμε – εφόσον αυτά βρίσκουν εφαρμογή σε πρωτόκολα outbound. Η πλειοψηφία των protocol filters τα οποία είναι διαθέσιμα στον TMG είναι σχεδιασμένα για το inbound protection, αλλά υπάρχουν ορισμένα τα οποία έχουν εφαρμογή σε πρωτόκολα outbound.


    Εικόνα 3

    Στο From tab, μπορούμε να καθορίσουμε τα source locations στα οποία αυτός ο κανόνας θα βρίσκει εφαρμογή. Με άλλα λόγια είναι οι clients οι οποίοι βρίσκονται σε ένα δίκτυο το οποίο προστατεύεται από τον TMG. Η επιλογή αυτή είναι όμοια με αυτήν την οποία είδαμε και στον Access Rule
    wizard. Όταν κάνουμε κλικ στο Add, εμφανίζεται το Add Network Entities
    dialog box και μπορούμε να επιλέξουμε από έναν μεγάλο αριθμό από network entities ή να δημιουργήσουμε καινούριες. Μια επιλογή η οποία είναι διαθέσιμη σε αυτό το tab, η οποία δεν εμφανίζεται στον Access Rule wizard, είναι ο τομέας των Exceptions.
    Εδώ είμαστε σε θέση να καθορίσουμε τα sources στα οποία επιθυμούμε αυτός ο κανόνας να εφαρμόζεται, αλλά εάν υπάρχει ένα υποσύνολο μέσα σε αυτήν την ομάδα (group) στο οποίο ο κανόνας δεν πρέπει να εφαρμοστεί,
    τότε μπορούμε να το τοποθετήσουμε μέσα στον τομέα των Exceptions. Αυτό αποτελεί μια πανίσχυρη επιλογή και θα πρέπει πάντοτε να το λαμβάνουμε υπόψην μας όταν σχεδιάζουμε Access Rules.


    Εικόνα 4

    Το To tab είναι όμοιο με το From tab, όπου καθορίζουμε τον προορισμό (destination) με τον θέλουμε να συμπίπτει ο κανόνας. Όταν κάνουμε κλικ στο Add, ανοίγει αυτόματα το Add Network Entities
    dialog box στο οποίο μας δίνετε η δυνατότητα να επιλέξουμε την θέση προορισμού (destination location) από την λίστα η οποία παρουσιάζεται,
    ή μπορούμε να δημιουργήσουμε μια καινούρια θέση προορισμού. Όσον αφορά το From tab, έχουμε επίσης την δυνατότητα δημιουργίας Exceptions.


    Εικόνα 5

    Στο Users tab, μπορούμε να καθορίσουμε σε ποιους χρήστες ο συγκεκριμένος κανόνας θα έχει εφαρμογή. Εξ ορισμού, το σετ χρηστών All Users χρησιμοποιείται για όλα τα Access Rules. Βεβαίως στο σημείο αυτό θα πρέπει να λάβουμε υπόψην μας ότι όταν αναφερόμαστε στο All Users δεν σημαίνει στην πραγματικότητα ότι συμπεριλαμβάνονται όλοι οι χρήστες (all
    users), αλλά αντιθέτως αντιπροσωπεύει ανώνυμες συνδέσεις και επικυρωμένες συνδέσεις (anonymous connections and authenticated
    connections). Εάν επιθυμούμε να εξαναγκάσουμε τους χρήστες να επικυρώσουν την σύνδεσή τους (authenticate), θα πρέπει να χρησιμοποιήσουμε κάποιο άλλο σετ χρηστών και να διαγράψουμε το All Users user set.

    Εάν κάνουμε κλικ στο Add, μπορούμε να επιλέξουμε το All Authenticated Users
    και τότε μόνον στους χρήστες οι οποίοι έχουν επικυρώσει την σύνδεσή τους με τον TMG firewall θα έχουν πρόσβαση διαμέσου του συγκεκριμένου κανόνα. Η επικύρωση του χρήστη μπορεί να πραγματοποιηθεί του web proxy client configuration ή του Firewall client (TMG client)
    configuration. Εάν θέλουμε να δημιουργήσουμε το δικό μας σετ χρηστών, απλά κάνουμε κλικ στο κουμπί New.


    Εικόνα 6

    Όταν κάνουμε κλικ στο New, εμφανίζεται ο Welcome to the New User Set
    wizard. Στην πρώτη σελίδα του wizard, εισάγουμε το όνομα του σετ χρηστών.
    Σε αυτό το παράδειγμα θα δημιουργήσουμε ένα σετ χρηστών το οποίο θα περιλαμβάνει το Domain
    Admins Active Directory group, και συνεπώς θα ονομάσουμε τον καινούριο κανόνα ως Administrators και εν συνεχεία κάνουμε κλικ στο Next.


    Εικόνα 7

    Στην σελίδα Users, όταν κάνουμε κλικ στο Add, εμφανίζεται ένα μενού τύπου fly out. Αυτό το fly out μενού περιλαμβάνει τις ακόλουθες πηγές πιστοποίησης:

    Windows users and groups - Αυτοί είναι οι χρήστες και οι ομάδες (users & groups) που περιλαμβάνονται στο Active Directory domain ή σε αξιόπιστο τομέα στον οποίο ο TMG Firewall ανήκει.
    LDAP - Αυτοί είναι οι χρήστες και οι ομάδες (users & groups) που περιλαμβάνονται στο Active Directory και μπορούμε να τους χρησιμοποιήσουμε όταν ο TMG firewall δεν είναι μέλος ενός τομέα (domain). Λάβετε υπόψην σας ότι ο TMG δεν υποστηρίζει LDAP authentication σε Access Rules.

    RADIUS - Αυτοί είναι οι χρήστες οι οποίοι είναι προσβάσιμοι διαμέσου του RADIUS. Σημειώστε ότι ο RADIUS δεν υποστηρίζει Group Membership, ασχέτως αν μας επιτρέπεται να δημιουργήσουμε έναν χρήστη ό οποίος εμπεριέχει πολλαπλούς λογαριασμούς - (multiple accounts) - οι οποίοι είναι προσβάσιμοι διαμέσου του RADIUS, γεγονός το οποίο έχει ως αποτέλεσμα ένα ad hoc group στον
    TMG firewall. Ο RADIUS υποστηρίζεται σε outbound web connections διαμέσου του TMG firewall.

    SecurID - Αυτοί είναι οι χρήστες καθορίζονται από το SecurID. Το SecurID δεν υποστηρίζεται στα outbound connections διαμέσου του TMG firewall και των αντίστοιχων Access Rules.
    Στο παράδειγμα αυτό, ο TMG firewall έχει συνδεθεί (joined) στο Active Directory domain, και για τον λόγο αυτό θα επιλέξουμε το Windows users and groups.


    Εικόνα 8

    Η προηγούμενη επιλογή φέρνει στο προσκήνι0 το Select Users or Groups dialog box. Στο σημείο αυτό εισαγάγουμε τους Domain Admins στο Enter the object names to select text box και εν συνεχεία κάνουμε κλικ στο Check Names και αμέσως μετά κάνουμε κλικ στο OK έτσι ώστε να συμπεριλάβουμε αυτό το Active Directory group στο σετ χρηστών.


    Εικόνα 9

    Σε αυτό το σημείο βλέπουμε τον νέο χρήστη στην σελίδα Users. Μπορούμε να προσθέσουμε περισσότερους χρήστες σε αυτό το σετ χρηστών εφόσον το επιθυμούμε. Στο παράδειγμα αυτό θα κάνουμε κλικ στο Next και δεν θα προσθέσουμε κανέναν άλλο χρήστη σε αυτό το σετ χρηστών.


    Εικόνα 10

    Στην σελίδα Completing the New User Set Wizard, κάνουμε κλικ στο Finish για να δημιουργήσουμε το καινούριο σετ χρηστών.


    Εικόνα 11

    Τώρα μπορούμε να δούμε το Administrators group στο Add Users dialog box και μπορούμε να χρησιμοποιήσουμε αυτό το group στα Access Rules και στα publishing rules.


    εικόνα 12

    Στο Schedule tab, μπορούμε να καθορίσουμε ένα χρονοδιάγραμμ για τον κανόνα ο οποίος καθορίζει με την σειρά του τις ώρες κατά τις οποίες ο κανόνας αυτός θα εφαρμόζεται. Σημειώστε ότι όταν ορίζουμε ένα χρονοδιάγραμμα, το χρονοδιάγραμμα εφαρμόζεται μόνον στις καινούριες συνδέσεις και συνεπώς για ήδη συνδεδεμένους χρήστες πριν από την εφαρμογή του κανόνα ο κανόνας αυτός δεν θα σταματήσει τις συνδέσεις τους. Ωστόσο, αν μια νέα προσπάθεια σύνδεσης που ταιριάζει με τον κανόνα είναι έξω από το χρονοδιάγραμμα, τότε η σύνδεση θα αρνηθεί. Το εξ ορισμού χρονοδιάγραμμα (schedule) είναι το Always, αλλά υπάρχουν επίσης αλλα δύο ενσωματωμένα χρονοδιαγράμματα που είναι : το  Weekends και το Work hours. Εάν παρόλα αυτά δεν μας αρέσει κανένα από τα παραπάνω ενσωματωμένα χρονοδιαγράμματα τότε κάνουμε κλικ στο New button και δημιουργούμε το δικό μας χρονοδιάγραμμα.


    Εικόνα 13

    Το Malware Inspection tab είναι καινούριο και είναι διαθέσιμο μόνον στον TMG firewall. Υπάρχει μια σειρά επιλογών σε αυτό το tab οι οποίες δεν εμφανίζονται στον Access Rule wizard:

    Inspect content downloaded from web servers to clients - Όταν ενεργοποιούμε αυτήν την επιλογή, όλο το περιεχόμενο το οποίο γίνεται downloaded από web servers θα ελέγχονται για κακόβουλο λογισμικό χρησιμοποιώντας την Microsoft AV μηχανή η οποία χρησιμοποιείται από τον TMG firewall.

    Force full content requests (remove HTTP Range header) - Αυτό αναγκάζει το firewall να ζητήσει το πλήρες περιεχόμενο, έτσι ώστε το περιεχόμενο να μπορεί να αξιολογηθεί στο σύνολό του. Εάν μόνο σειρές αξιολογήθηκαν, ενδεχόμενες απειλές ενδέχεται να έχουν παραληφθεί.

    Use rule specific settings for malware inspection - Μπορούμε να προσαρμόσουμε τις ρυθμίσεις του anti-malware για τον συγκεκριμένο κανόνα, όταν κάνουμε αυτήν την επιλογή. Συνεπώς εάν επιλέξουμε αυτή την επιλογή, θα πρέπει να κάνουμε κλικ στο
    Rule Settings button για να ολοκληρώσουμε την προσαρμοσμένη ρύθμιση των παραμέτρων μας.

    Εικόνα 14

    Στην σελίδα Edit Rule Malware Inspection Settings, υπάρχει ένας αριθμός επιλογών. Η παρακάτω εικόνα δείχνει τις εξ ορισμού ρυθμίσεις:

    Attempt to clean the infected files - Όταν αυτή η ενότητα είναι ενεργοποιημένη, το firewall TMG θα προσπαθήσει να καθαρίσει το αρχείο πριν το διαβιβάσει στο χρήστη. Εάν το αρχείο δεν μπορεί να καθαριστεί, θα διαγραφεί.
    Block files with low and medium severity threats (higher level threats are blocked automatically) - Ο TMG firewall δεν θα μπλοκάρει εξ ορισμού αρχεία με απειλές μεσαίου και χαμηλού κινδύνου, χρησμοποιώντας το Microsoft AM engine classification system.
    Block suspicious files - Ο TMG firewall χρησιμοποιεί τα heuristics για να καθορίσει πότε ένα αρχείο εάν ένα αρχείο είναι πιθανώς κακόβουλο. Όταν αυτή η επιλογή είναι επιλεγμένη, τότε το αρχείο θα μπλοκαριστεί εάν τα heuristics καθορίσουν ότι το αρχείο είναι πιθανώς malware.
    Block corrupted files - Όταν αυτή η επιλογή είναι ενεργοποιημένη, τα αρχεία που έχουν καθοριστεί ότι είναι κατεστραμμένα, θα μπλοκαριστούν. Block files that cannot be scanned - Όταν αυτή η επιλογή είναι ενεργοποιημένη, η Microsoft AV engine δεν μπορεί να σαρώσει το αρχείο, και το αρχείο θα μπλοκαριστεί.
    Block encrypted files - Εάν το αρχείο είναι κρυπτογραφημένο, η Microsoft AV engine δεν είναι σε θέση να αξιολογήσει το αρχείο και εάν αυτή η επιλογή αυτή είναι ενεργοποιημένη το αρχείο θα μπλοκαριστεί.
    Block files if scanning time exceeds (seconds) - Όταν αυτή η επιλογή είναι ενεργοποιημένη, περιορίζει τον χρόνο κατά τον οποίο η Microsoft AV engine μπορεί να χρησιμοποιήσει για να αξιολογήσει το αρχείο πριν το ελευθερώσει ή το μπλοκάρει. Η προεπιλεγμένη τιμή είναι 5 λεπτά.
    Block files if archive level depth exceeds - Όταν αυτή η επιλογή είναι ενεργοποιημένη, η AV engine μπλοκάρει εκείνα τα αρχεία τα οποία έχουν υπερβεί το archive depth το οποίο έχει καθοριστεί εδώ. Η προεπιλεγμένη τιμή είναι 20 επίπεδα (levels).

    Block files larger than (MB) - Όταν αυτή η επιλογή είναι ενεργοποιημένη, θα μπλοκάρει αρχεία τα οποία είναι μεγαλύτερα από την αξία η οποία παρουσιάζεται στο text box, με την εξ ορισμού τιμή να είναι 1000 MB (1 GB). Αυτή η επιλογή μπορεί να χρησιμοποιηθεί για να βελτιώσουμε την απόδοση του TMG firewall, αλλά θα πρέπει να είμαστε ιδιαίτερα προσεκτικοί να μην μπλοκάρουμε αρχεία τα οποία χρειάζονται οι χρήστες μιας και οι χρήστες μπορεί να εργάζονται με μεγάλα σε μέγεθος αρχεία.

    Block archive files if unpacked content is large than (MB) - Αυτή η επιλογή καθορίζει το μέγιστο μέγεθος ενός αποσυμπιεσμένου αρχείου. Αυτή η τιμή χρησιμοποιείται για να συντηρήσει τη μνήμη (preserve memory) στον TMG firewall.

    Εικόνα 15

    Συμπέρασμα

    Σε αυτό το άρθρο ασχοληθήκαμε με τις λεπτομέρειες των Access Rules. Ενώ οι περισσότερες επιλογές τις οποίες θέλουμε να ρυθμίσουμε είναι προσβάσιμες από τον Access Rule Wizard, εντούτοις υπάρχουν κάποιες σημαντικές επιλογές οι οποίες είναι προσβάσιμες μόνον αφότου έχουμε δημιουργήσει τον κανόνα πηγαίνοντας στο Properties dialog box του συγκεκριμένου κανόνα. ελπίζω ότι θα βρειτε το συγκεκριμένο άρθρο ιδιαιτέρως χρήσιμο για σας οι οποίοι χρησιμοποιείται τον TMG firewall.
  3. Jordan_Tsafaridis
    Όταν ξεκινούμε
    την διαδικασία ενεργοποίησης (activate) των Windows Server 2008R2 ενδεχομένως να γίνουμε παραλήπτες του παρακάτω
    μηνύματος :
     

    A problem occurred when Windows tried to activate. Error
    Code 0x8004FE2F
     


     

    ή…
     

    A problem occurred when Windows tried to activate. Error
    Code 0xC004FC03
     


     

    Επίσης εάν προσπαθήσετε
    να ενεργοποιήσετε τα Windows από το command line χρησιμοποιώντας την εντολή slmgr.vbs -ato μπορεί να σας παρουσιαστεί ένα από τα παρακάτω
    μηνύματα λάθους:
     

    Activating Window Server®, ServerEnterprise
    edition {GUID}...
     

    On a computer running Microsoft Windows non-core
    edition, run 'slui.exe
     

    0x2a 0x8004FE2F' to display
    the error text.
     

    Error:
    0x8004FE2F
     


     

    ή…
     

    Activating Window Server®, ServerEnterprise
    edition {GUID}...
     

    On a computer running Microsoft Windows non-core
    edition, run 'slui.exe
     

    0x2a 0x80072EE2' to display
    the error text.
     

    Error:
    0x80072EE2
     


     

    Το πρόβλημα αυτό
    μπορεί να προκύψει σε συστήματα τα οποία βρίσκονται εντός ενός δικτύου το οποίο
    προστατεύεται από τον Forefront TMG 2010 firewall, σε συνδυασμό με τον κανόνα
    πρόσβασης (access rule) ο οποίος επιτρέπει κίνηση (traffic) το οποίο απαιτεί authentication. Η διαδικασία ενεργοποίσης των Windows βασίζεται στο WinHTTP και εξ ορισμού το WinHTTP communication αποστέλεται ως  SecureNAT client traffic. Δυστυχώς οι SecureNAT clients δεν μπορούν να γίνουν authenticated, με αποτέλεσμα το αίτημα να
    αποτυγχάνει.
     

    Υπάρχουν δύο
    τρόποι για να επιλύσουμε το συγκεκριμένο πρόβλημα. Ο πρώτος τρόπος είναι να ρυθμίσουμε
    (configure) το WinHTTP στο  Windows system το οποίο προσπαθούμε να ενεργοποιήσουμε να
    χρησιμοποιήσει ένα διακομιστή
    μεσολάβησης ρητά (use a proxy server explicitly). Συνεπώς ανοίγουμε ένα παράθυρο command prompt και εκτελούμε την ακόλουθη εντολή:
     

    netsh winhttp set proxy <name
    or IP address of proxy server>:<port>
     

    Παράδειγμα:
     

    netsh winhttp set proxy tmg.tjordan.net:8080
     

    Αντί όμως να
    κάνουμε αυτήν την αλλαγή σε κάθε σύστημα το οποίο θλελουμε να ενεργοποιήσουμε ο
    εναλλακτικός τρόπος για να το επιτύχουμε είναι η δημιουργία ενός ανώνυμης πρόσβασης
    κανόνα  - (create an anonymous access rule) – στον Forefront TMG 2010 firewall ο οποίος θα επιτρέπει το HTTP και το HTTPS traffic σε αυτούς τους προορισμούς (destinations) οι οποίοι απαιτούνται για την
    ενεργοποίηση των Windows. Χρησιμοποιώντας την  Forefront TMG 2010 management console, δημιουργούμε έναν κανόνα πρόσβασης
    ο οποίος επιτρέπει την πρόσβαση στα πρωτόκολα HTTP και HTTPS από το εσωτερικό δίκτυο (Internal network) σε ένα Domain Name Set το οποίο περιλαμβάνει τους ακόλουθους προορισμούς για
    όλους τους χρήστες:
     

    activation.sls.microsoft.com.nsatc.net
     

    go.microsoft.com
     

    *.sls.microsoft.com
     

    Θα πρέπει να
    βεβαιωθείτε ότι ο συγκεκριμένος κανόνας να τοποθετηθεί πριν από κάθε άλλο κανόνα
    για πρωτόκολα HTTP ή HTTPS τα οποία απαιτούν authentication.
     


     

    Από την στιγμή κατά την οποία ο κανόνας ρυθμιστεί και τεθεί σε λειτουργία, η ενεργοποίηση των Windows θα δουλέψει χωρίς κανένα πρόβλημα.
     


     


     

    Ελπίζω ότι θα
    σας φανεί ιδαίτερα χρήσιμο.
  4. Jordan_Tsafaridis
    Σε μια εταιρική εγκατάσταση χρησιμοποιώ τον Forefront TMG 2010 ως proxy server καθώς επίσης και για να κάνει publishe μια ομάδα υπηρεσιών στο διαδίκτυο.
    Το πρόβλημα το οποίο αντιμετώπισα ήταν ότι για να διαχειρστώ τον TMG αυτό έπρεπε να γίνει διαμέσου του console viewer στον HyperV,
    διότι πολύ απλά κατά την εγκατάσταση του Microsoft ForeFront TMG 2010 είναι κλειδωμένη η χρήση του Remote Desktop (RDP). Για τον λόγο αυτό έψαξα στο διαδίκτυο για πληροφορίες σχετικά με το πως κάνουμε το setup για να ενεργοποιήσουμε το internal RDP
    access έτσι ώστε να είναι δυνατή η χρήση του remote desktop. Οι ενέργειες τις οποίες πρέπει να κάνουμε είναι οι εξής παρακάτω :

    Πρώτα απ' όλα ανοίγουμε το Forefront TMG Management console και στο αριστερό pane κάνουμε κλικ στο Firewall Policy.

    Στο δεξιό pane, κάνουμε κλικ στο Toolbox και αναζητούμε (drill down) μέσα στο Computer Sets να βρούμε το Enterprise Remote Management.



    Εν συνεχεία κάνουμε διπλό κλικ στο Enterprise Remote Management για να ανοίξουμε το συγκεκριμένο set και αμέσως μετά χρησιμοποιούμε το Add button για να επιβεβαιώσουμε ότι το εσωτερικό μας δίκτυο περιλαμβάνεται στην συγκεκριμένη λίστα.



    Εν συνεχεία επιστρέφουμε στο αριστερό pane και κάνουμε δεξί κλικ στο Firewall Policy και δημιουργούμε έναν καινούριο access rule:



    Εδώ θα πρέπει να ονοματίσουμε τον συγκεκριμένο κανόνα (Access Rule) με ένα χαρακτηριστικό όνομα το οποίο θα υποδηλώνει την λειτουργία του, π.χ. TMG RDP Management
    και εν συνεχεία κάνουμε setup στον κανόνα έτσι ώστε να επιτρέπει το RDP (Terminal Services) traffic από το εσωτερικό δίκτυο προς τον Local Host.



    Στο σημείο αυτό αποθηκεύουμε το καινούριο μας configuration και πλέον έχουμε την δυνατότητα διαχείρισης του TMG 2010 διαμέσου του RDP από το εσωτερικό δίκτυό μας.
  5. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι της κοινότητας ο σκοπός του
    συγκεκριμένου άρθρου είναι να παρουσιάσω τον τρόπο με τον οποίο μπορούμε να
    επαναφέρουμε (restore) μια
    εγκατάσταση Windows
    Server 2008
    R2 από αντίγραφο
    ασφαλείας (back-up) σε ένα καινούριο σύστημα το οποίο δεν
    έχει λειτουργικό σύστημα εγκατεστημένο (bare metal restore).
     

    Εισαγωγή
     

    Θα συμφωνήσετε
    μαζί μου ότι ένα επιτυχές disaster recovery είναι
    άμεσα συνδεδεμένο με την προετοιμασία η οποία θα πρέπει να λάβει χώρα πριν από
    την εμφάνιση μιας δυσάρεστης κατάστασης, μιας και όπως έλεγαν και οι αρχαίοι “ενός
    κακού μύρια έπονται”. Υπάρχουν αρκετοί διαφορετικοί τρόποι με τους οποίους μπορούμε
    να επαναφέρουμε έναν Windows server
    όταν το system
    drive τεθεί εκτός λειτουργίας. Η
    διαδικασία την οποία πρόκειται να ακολουθήσουμε είναι πολύ απλή και διακριτή : απλά
    θα αντικαστήσουμε τον χαλασμένο σκληρό δίσκο, εν συνεχεία θα κάνουμε boot
    τον server
    από το Windows
    installation media,
    και τέλος θα εκκινήσουμε την διαδικασία του restore. Βεβαίως
    υπάρχουν ορισμένα θέματα τα οποία θα πρέπει να λάβουμε υπόψην μας τα οποία θα τα
    παρουσιάσω στην συνέχεια του συγκεκριμένου άρθρου.
     

    Περιβάλλον δοκιμής
     

    Για λόγους απλότητας
    το περιβάλλον δοκιμής δεν είναι παρά ένα εικονικό περιβάλλον βασισμένο στον Microsoft Hyper-V. Ο
    server στον οποίο θα κάνουμε restore
    είναι μια
    εικονική μηχανή με όνομα SEA-FS1
    μέλος του contoso.com domain. Το
    backup θα αποθηκευθεί σε έναν μοιραζόμενο φάκελο ο οποίος
    βρίσκεται στον Hyper-V
    host και στον οποίο αυτή η εικονική μηχανή τρέχει. Αντιστοίχως
    το "bare metal system"
    στο οποίο θα γίνει το restore του backup
    είναι επίσης
    μια άλλη εικονική μηχανή στην οποία δεν είναι εγκατεστημένο το λειτουργικό σύστημα. Σε
    αυτό το σημείο είναι σημαντικό να αναφέρουμε ότι τα βήματα τα οποία θα ακολουθήσουμε
    είναι ακριβώς τα ίδια με αυτά τα οποία θα κάναμε εάν πρόκειται για το back
    ενός
    φυσικού server και αντιστοίχως για το restore
    σε επίπεδο bare metal.
     

    Δημιουργία
    αντιγράφου ασφαλείας του
    Server 

    Ας
    ξεκινήσουμε λοιπόν. Στην παρακάτω Εικόνα
    1 εμφανίζεται ο file server
    πριν από
    την “καταστροφή” και κρίνεται απαραίτητο να γίνει restore. Το
    όνομα του server και το domain
    εμφανίζονται
    μέσα στον κόκκινο κύκλο καθώς επίσης και στο title
    bar του παραθύρου Virtual
    Machine Connection :
     






















     
    Εικόνα 1:
    Ο server πριν την καταστροφή (crashed)
     

    Θα κάνουμε εν
    συνεχεία αντιστοίχιση (map) σε ένα drive
    letter τον μοιραζόμενο φάκελο (shared
    folder) με όνομα Backups στον Hyper-V
    host έτσι ώστε να είμαστε σε θέση να αποθηκεύσουμε
    το backup στο "δίκτυο - on
    the network" όταν θα το
    δημιουργήσουμε:
     




     
    Εικόνα 2:
    Προετοιμασία για back up
    του server
     

    Εισάγουμε τα
    credentials για να μας δοθεί πρόσβαση στον μοιραζόμενο
    φάκελο στον host:
     




     
    Εικόνα 3:
    Προετοιμασία για back up
    του server
     

    Όπως θα παρατηρήσετε
    την δεδομένη χρονική στιγμή δεν υπάρχουν backup
    sets εντός του συγκεκριμένου μοιραζόμενου φάκελου:
     




     
    Εικόνα 4:
    Ο φάκελος είναι κενός και δεν υπάρχουν backup
    sets.
     

    Αμέσως μετά πληκτρολογούμε
    "backup" στο Start menu
    search box για να ενεργοποιήσουμε
    το Windows Server Backup
    feature (το οποίο βέβαια θα πρέπει να έχει ήδη
    εγκατασταθεί στον server πριν το
    χρησιμοποιήσουμε):
     




     
    Εικόνα 5:
    Βήμα 1 της διαδικασίας του back up
    του server
     

    Όταν το παράθυρο
    Windows Server Backup
    ανοίγει,
    κάνουμε κλικ στο Backup Once
    όπως αυτό
    απεικονίζεται στην παρακάτω εικόνα:
     




     
    Εικόνα 6:
    Βήμα 2 της διαδικασίας του back up
    του server
     

    Στην σελίδα Backup
    Options του wizard, βεβαιωθείτε ότι έχετε
    επιλέξει την επιλογή Different Options:
     




     
    Εικόνα 7:
    Βήμα 3 της διαδικασίας του back up
    του server
     

    Στην σελίδα Select Backup Configuration, επιλέγουμε Custom:
     




     
    Εικόνα 8:
    Βήμα 4 της διαδικασίας του back up
    του server
     

    Στην σελίδα Select Items For Backup, κάνουμε κλικ στο Add Items button:
     




     
    Εικόνα 9:
    Βήμα 5 της διαδικασίας του back up
    του server
     

    Στο πλαίσο διαλόγου
    Select Items, επιλέγουμε το checkbox με
    την ονομασία Bar Metal Recovery.
    Εφαρμόζοντας αυτή την επιλογή θα γίνει αυτόματη επιλογή και όλων των υπολοίπων checkboxes επίσης:
     




     
    Εικόνα 10:
    Βήμα 6 της διαδικασίας του back up
    του server
     

    Κάνοντας κλικ
    στο OK μας επιστρέφει στην σελίδα Select
    Items For Backup. Κάνουμε
    κλικ στο Next στην σελίδα αυτή:
     




     
    Εικόνα 11:
    Βήμα 7 της διαδικασίας του back up
    του server
     

    Στην σελίδα Specify Destination Type, επιλέγουμε το Remote Shared Folder:
     




     
    Εικόνα 12:
    Βήμα 8 της διαδικασίας του back up
    του server
     

    Στην σελίδα Specify
    Remote Folder, πληκτρολογούμε το UNC
    path του μοιραζόμενου φακέλου στο "δίκτυο"
    όπου εκεί πρόκειται να αποθηκεύσουμε τα backups.
    Το path το οποίο καθορίζουμε είναι το \\HV-1\Backups
    και αφήνουμε
    όλες τις άλλες επιλογές στην σελίδα στις default
    ρυθμίσεις:
     




     
    Εικόνα 13:
    Βήμα 9 της διαδικασίας του back up
    του server
     

    Στο credential prompt, καθορίζουμε τα credentials για
    την πρόσβαση στον μοιραζόμενο φάκελο στον host:
     




     
    Εικόνα 14:
    Βήμα 10 της διαδικασίας του back up
    του server
     

    Μετά από την
    επισκόπηση της σελίδας Confirmation, κάνουμε κλικ στο Backup
    για να ξεκινήσει το back up
    του server:
     




     
    Εικόνα 15:
    Βήμα 11 της διαδικασίας του back up
    του server
     

    Ο server
    γίνεται
    πλέον back up:
     




     
    Εικόνα 16: Βήμα
    12 της διαδικασίας του back up
    του server
     

    Το Backup έχει ολοκληρωθεί:
     




     
    Εικόνα 17:
    Ο server έχει γίνει back
    up
     

    Ανοίγουμε εν
    συνεχεία το mapped drive στον Explorer για
    να επιβεβαίωσουμε ότι το backup set
    βρίσκεται
    αποθηκευμένο εκεί:
     




     
    Εικόνα 18:
    Ο server πράγματι έχει γίνει back
    up
     

    Σε αυτό το σημείο
    κάνουμε shut down τον file
    server και κλείνουμε την εικονική μηχανή. Τώρα
    είμαστε για την διαδικασία του restore σε επίπεδο bare
    metal!
     

    Επαναφορά του Server (Restoring the Server to Bare Metal)
     

    Στην εικόνα 19
    όπως αυτή απεικονίζεται παρακάτω, εμφανίζεται μια εικονική μηχανή η οποία
    ονομάζεται Bare Metal System.
    Όπως θα παρατηρήσετε όταν δοκιμάζουμε να κάνουμε boot
    στο system
    το boot
    αποτυγχάνει
    διότι πολύ απλά δεν υπάρχει εγκατεστημένο λειτουργικό σύστημα στην συγκεκριμένη
    μηχανή:
     




     
    Εικόνα
    19:
    Η εικονική μηχανή bare metal
    system δεν έχει εγκατεστημένο λειτουργικό σύστημα
     

    Για να εκκινήσουμε
    την διαδικασία του recovery, χρειάζεται για να
    κάνουμε boot το bare metal
    system να χρησιμοποιήσουμε το Windows
    media. Λόγω του ότι το σύστημά
    μας είναι μια εικονική μηχανή, κάνουμε attach
    μια εικόνα
    .iso των Windows Server
    2008 R2 installation media
    στα settings της
    εικονικής μηχανής και αμέσως μετά κάνουμε restart
    την εικονική
    μηχανή. Σε λίδα δευτερόλεπτα εμφανίζεται το πλαίσιο διαλόγου Install
    Windows dialog:
     




     
    Εικόνα
    20:
    Βήμα 1 της διαδικασίας επαναφοράς (restore) του server
    σε
    επίπεδο bare metal
     

    Αμέσως μετά κάνουμε
    κλικ στο Next στην προηγούμενη εικόνα, και εν συνεχεία επιλέγουμε
    την επιλογή Repair Your Computer η
    οποία απεικονίζεται κάτω αριστερά όπως αυτόαπεικονίζεται στην παρακάτω εικόνα:
     




     
    Εικόνα
    21:
    Βήμα 2 της διαδικασίας επαναφοράς (restore) του server
    σε
    επίπεδο bare metal
     

    Στο πλαίσο διαλόγου System Recovery Options, επιλέγουμε την επιλογή "Restore your computer using a system image that
    you created earlier":
     




     
    Εικόνα
    22:
    Βήμα 3 της διαδικασίας επαναφοράς (restore) του server
    σε
    επίπεδο bare metal
     

    Όταν το πλαίσο
    διαλόγου Re-image Your
    Computer εμφανιστεί, κάνουμε κλικ στο Cancel:
     




     
    Εικόνα
    23:
    Βήμα 4 της διαδικασίας επαναφοράς (restore) του server
    σε
    επίπεδο bare metal
     

    Σημειώση:
     
    Εάν το
    backup το οποίο κάνουμε restore
    βρίσκεται
    σε ένα σκληρό δίσκο ο οποίος είναι συνδεδεμένος στο σύστημα (για παράδειγμα ένα
    εξωτερικό USB drive) το πλαίσο διαλόγου Re-image
    Your Computer δεν πρόκειται να
    εμφανιστεί. Αντιθέτως θα κατευθυνθείτε απευθείας στην επόμενη οθόνη η
    οποία απεικονίζεται παρακάτω και στην οποία θα πρέπει να επιλέξετε την πρώτη επιλογή
    "Use the latest
    available system
    image (recommended)" για να
    προχωρήσει η διαδικασία του restore.
     

    Στην σελίδα Select
    A System Image
    Backup, βεβαιωθείτε ότι έχετε επιλέξει την επιλογή Select
    A System Image
    και αμέσως
    μετά κάνουμε κλικ στο Next:
     




     
    Εικόνα
    24:
    Βήμα 5 της διαδικασίας επαναφοράς (restore) του server
    σε
    επίπεδο bare metal
     

    Στην επόμενη
    σελίδα δεν θα πρέπει να εμφανιστούν backups. Ο
    λόγος είναι ότι τα back up
    του server
    βρίσκονται
    στο δίκτυο (σε ένα μοιραζόμενο φάκελο στον host)
    και όχι σε ένα τοπικό δίσκο στο σύστημά μας ή σε ένα συνδεδεμένο USB
    drive. Εάν το back
    up είναι σε τοπικό δίσκο και όχι στο δίκτυο, θα μπορέσπυμε
    να συνεχίσουμε την διαδικασία του restore ξεκινώντας από την
    Εικόνα 30 παρακάτω.
     

    Στην σελίδα η
    οποία απεικονίζεται παρακάτω, κάνουμε κλικ στο Advanced:
     




     
    Εικόνα
    25:
    Βήμα 6 της διαδικασίας επαναφοράς (restore) του server
    σε
    επίπεδο bare metal
     

    Στο πλαίσο διαλόγου
    το οποίο εμφανίζεται, επιλέγουμε την επιλογή "Search
    for a system
    image on the
    network" όπως αυτή εμφανίζεται παρακάτω:
     




     
    Εικόνα
    26:
    Βήμα 7 της διαδικασίας επαναφοράς (restore) του server
    σε
    επίπεδο bare metal
     

    Σημείωση:
     
    Στο συγκεκριμένο
    περιβάλλον δοκιμής θα πρέπει να γνωρίζετε ότι υπάρχει εν λειτουργία ένας DHCP
    server και για τούτο τον λόγο το Windows
    Recovery Environment είναι σε θέση να
    συνδεθεί στον μοιραζόμενο δικτυακό φάκελο (network
    share) όπου το backup set
    είναι
    αποθηκευμένο.
     

    Στο πλαίσιο διαλόγου
    Are You Sure
    το οποίο
    εμφανίζεται αμέσως μετά κάνουμε κλικ στο Yes:

     




     
    Εικόνα
    27:
    Βήμα 8 της διαδικασίας επαναφοράς (restore) του server
    σε
    επίπεδο bare metal
     

    Σημείωση:
     
    Όπως
    μας προειδοποιεί το παραπάνω πλαίσιο διαλόγου, η διαδικασία restore
    ενός συστήματος
    από ένα backup το οποίο είναι αποθηκευμένο στο δίκτυο δεν είναι
    τόσο ασφαλές όσο από ένα back up
    το οποίο
    είναι αποθηκευμένο σε έναν τοπικό δίσκο. Συνεπώς θα πρέπει να λάβετε σοβαρά υπόψην
    την παρατήρηση αυτή όταν σχεδιάζετε μια υποδομή disaster recover για τους δικούς σας servers!
     

    Πληκτρολογείστε
    το UNC path στο οποίο βρίσκεται αποθηκευμένο
    το backup στο δίκτυο:
     




     
    Εικόνα
    28:
    Βήμα 9 της διαδικασίας επαναφοράς (restore) του server
    σε
    επίπεδο bare metal
     

    Εισάγουμε τα
    απαραίτητα credentials για να αποκτήσουμε πρόσβαση στον δικτυακό
    φάκελο:
     




     
    Εικόνα
    29:
    Βήμα 10 της διαδικασίας επαναφοράς (restore) του server
    σε
    επίπεδο bare metal
     

    Μόλις το Windows
    Recovery Environment έχει συνδεθεί στον δικτυακά
    μοιραζόμενο φάκελο θα πρέπει αυτομάτως να έχετε διαθέσιμη μία λίστα με τα
    διαθέσιμα backup στον μοιραζόμενο δικτυακό φάκελο. Επιλέγουμε
    αυτό το οποίο επιθυμούμε και αμέσως μετά κάνουμε κλικ στο Next
    όπως
    απεικονίζεται στην παρακάτω εικόνα:
     




     
    Εικόνα
    30:
    Βήμα 11 της διαδικασίας επαναφοράς (restore) του server
    σε
    επίπεδο bare metal
     

    Τώρα
    επιλέγουμε το backup set από το οποίο θέλουμε
    να κάνουμε restore:
     




     
    Εικόνα
    31: Βήμα
    12 της διαδικασίας επαναφοράς (restore) του server
    σε
    επίπεδο bare metal
     

    Κάνοντας κλικ
    στο Next έχει ως αποτέλεσμα την αυτόματη εμφάνιση της
    σελίδας Choose Additional Restore
    Options:
     




     
    Εικόνα
    32:
    Βήμα 13 της διαδικασίας επαναφοράς (restore) του server
    σε
    επίπεδο bare metal
     

    Εάν κάνουμε κλικ
    στο Advanced, μπορούμε να δούμε ότι το σύστημα θα κάνει αυτόματα
    restart αμέσως μόλις η διαδικασία του restore
    ολοκληρωθεί
    σε συνδυασμό με έλεγχο στον δίσκο για τυχόν λάθη. Θα
    αφήσουμε και τις δύο αυτές επιλογές να παραμείνουν επιλεγμένες:
     




     
    Εικόνα
    33:
    Βήμα 14 της διαδικασίας επαναφοράς (restore) του server
    σε
    επίπεδο bare metal
     

    Κάνοντας κλικ
    στο Next ερωτόμαστε να επιβεβαιώσουμε τις επιλογές μας:
     




     
    Εικόνα
    34:
    Βήμα 15 της διαδικασίας επαναφοράς (restore) του server
    σε
    επίπεδο bare metal
     

    Κάνουμε κλικ στο Yes για να επιβεβαιώσουμε το YES I DEFINITELY WANT TO RESTORE FROM BACKUP:
     




     
    Εικόνα
    35:
    Βήμα 16 της διαδικασίας επαναφοράς (restore) του server
    σε
    επίπεδο bare metal
     

    Αμέσως μετά
    λαμβάνουμε το παρακάτω μήνυμα λάθους:
     




     
    Εικόνα
    36: Το restore απέτυχε!
     

    Δυστυχώς κάτι
    πήγε λάθος αλλά τί? Ας ξεκινήσουμε την όλη διαδικασία του restore
    από την αρχή με
    σημείο εκκίνησης την εικόνα 19 again...
     

    Αλλά και πάλι
    λαμβάνουμε ένα διαφορετικό αλλά και πιο σοβαρό μήνυμα λάθους:
     




     
    Εικόνα
    37:
    Το restore απέτυχε ξανά!!
     

    Κάνουμε κλικ
    στο Details link στο παραπάνω πλαίσιο διαλόγου
    και μας εμφανίζεται η παρακάτω απάντηση:
     




     
    Εικόνα
    38:
    Ευχαριστώ για την συμβουλή
     

    Τελικά τι
    μπορεί να οδήγησε την διαδικασία στην δημιουργία αυτού του λάθους? Ψάχνοντας λίγο
    στο διαδίκτυο και συγκεκριμένα μετά από αναζήτηση σε αυτό thread
    από τα Microsoft TechNet
    Forums μας δίδεται η απάντηση.
     

    Η απάντηση η
    οποία δίδεται στα Microsoft TechNet
    Forums από τον συγκεκριμένο τεχνικό είναι ότι το πρόβλημα
    οφείλεται στο γεγονός όπως και στην περίπτωσή μας ότι στα settings της
    εικονικής μηχανής Bare Metal
    System στον Hyper-V
    Manager, το virtual
    hard drive αυτής της μηχανής
    στην πράξη είναι σε μέγεθος μικρότερο από το μέγεθος του αρχείου VHD
    του πρωτότυπου
    συστήματος SEA-FS1.
     

    Δίδαγμα : Βεβαιωθείτε ότι ο σκληρός δίσκος του bare
    metal system στον οποίο πρόκειται να
    γίνει restore έχει χωρητικότητα ίση ή μεγαλύτερη από την
    χωρητικότητα του σκληρού δίσκου του συστήματος το οποίο έχει τεθεί εκτός
    λειτουργίας.
     

    Για να το διορθώσουμε αυτό το σφάλμα, αποσυνδέουμε το VHD file από την Bare
    Metal System VM, δημιουργούμε ένα καινούριο VHD με μέγεθος ίσο με αυτό του συνδεδεμένου στην SEA-FS1 VM, και επανεκκινούμε την διαδικασία του restore ξεκινώντας ξανά από την Εικόνα 19, και όπως είναι φυσικό επακκόλουθο η διαδικασία του restore πλέον λειτουργεί κανονικά:
     




     
    Εικόνα
    39:
    Το restore τώρα δουλεύει σωστά. Τι ανακούφιση!!
     

    Αφότου ολοκληρωθεί
    η διαδικασία του restore σε επίπεδο bare
    metal επιτυχώς και η εικονική μηχανή κάνει reboot,
    κάνουμε log on για να διαπιστώσουμε ότι
    ο  ανακτημένος (recovered)
    server έχει το ίδιο όνομα όπως και ο πρωτότυπος server
    (συγκρίνετε την εικόνα παρακάτω με την εικόνα 1 στην αρχή του συγκεκριμένου άρθρου):
     




     
    Εικόνα
    40: Tο restore ολοκληρώθηκε.
    Ελπίζω ότι το συγκεκριμένο άρθρο να το αξιολογήσετε ώς ιδιαίτερα χρήσιμο.

  6. 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)
    Ελπίζω ότι θα το βρείτε εξαιρετικά ενδιαφέρον.
  7. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι της κοινότητας για όλους εσάς που δεν σας δόθηκε η ευκαιρία να παρακολουθήσετε από κοντά το Microsoft TechEd North America 2012, παρακάτω κάνοντας κλικ επάνω στην εικόνα θα οδηγηθείτε στην παρουσίαση με τίτλο “Demystifying Microsoft Forefront Edge Security Solutions: TMG and UAG” την οποία πραγματοποίησε ο αγαπητός φίλος και συνάδελφος Richard Hicks (Director of Sales Engineering for security appliance vendor Celestix Networks).


    Ελπίζω ότι θα συμφωνήσετε μαζί μου ότι η συγκεκριμένη παρουσίαση είναι εξαιρετική.

  8. Jordan_Tsafaridis
    Σε αυτόν τον οδηγό των 46 σελίδων, γίνεται μια εισαγωγή στο λειτουργικό σύστημα των Windows 7 και στο τι καινούριο έχει να προσφέρει στον τελικό χρήστη. Επίσης αυτός ο οδηγός αναφέρεται σε θέματα τα οποία σχετίζονται με software
    compatibility. Επιπροσθέτως, μας παρέχει λεπτομερείς πληροφορίες για την καινούρια taskbar, πως να χρησιμοποιούμε και να παραμετροποιούμε το Windows Aero, τι ακριβώς είναι τελικά τα Windows 7 Libraries, τι λογισμικό περιλαμβάνεται στα Windows 7, και τέλος πόσο εύκολη είναι η ρύθμιση του networking στα
    Windows 7 μαζί με ορισμένα άλλα χαρακτηριστικά.



    Κάνετε κλικ εδώ για να κατεβάσετε τον οδηγό “The Windows 7 Guide: From newbies to Pros”
  9. 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
     
  10. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι της κοινότητας σήμερα ο Windows Server 2008 R2 Hyper-V έλαβε την επιβράβευση - πιστοποίηση κατά το BSI EAL 4+ Security Certification. Διαβάστε παρακάτω την ανακοίνωση στην Αγγλική γλώσσα.
     
    Windows Server 2008 R2 Hyper-V has just achieved EAL 4+ security certification from the Federal Office for Information Security (Bundesamtes für Sicherheit in der Informationstechnik – BSI) in Germany. 
     
    According to Wikipedia: EAL4 is the highest level at which it is likely to be economically
    feasible to retrofit to an existing product line. EAL4 is therefore
    applicable in those circumstances where developers or users require a
    moderate to high level of independently assured security in conventional
    commodity TOEs and are prepared to incur additional security-specific
    engineering costs.
  11. Jordan_Tsafaridis
    Η επικράτεια των χάκερς διευρύνεται με ανησυχητικό τρόπο, ξεφεύγοντας
    για τα καλά από το πεδίο των ηλεκτρονικών υπολογιστών και των κινητών
    τηλεφώνων, καθώς η εξειδικευμένη εταιρία κυβερνο-ασφάλειας και
    λογισμικού κατά των ιών McAfee, σε νέα έκθεσή της, προειδοποιεί ότι στο
    μέλλον είναι δυνατό να τεθεί σε κίνδυνο η ίδια η ζωή των οδηγών
    αυτοκινήτων.
     
     
     
    Καθώς τα οχήματα αποκτούν όλο και περισσότερους κομπιούτερ και άλλα
    ηλεκτρονικά συστήματα και, παράλληλα, διασυνδέονται ασύρματα στο
    διαδίκτυο, κακόβουλοι χάκερ θα μπορούσαν να πάρουν εξ αποστάσεως τον
    έλεγχο του αυτοκινήτου, ακόμα και να σβήσουν τον κινητήρα, ενώ ο οδηγός
    κινείται στο δρόμο.
     
     
     
    Η εταιρία προειδοποιεί ότι υπάρχει πια τόσο πολύ ενσωματωμένο λογισμικό
    σε ένα αυτοκίνητο, από τους αερόσακους και τα ραδιόφωνα έως τα καθίσματα
    και τα συστήματα ελέγχου πλοήγησης, που οι χάκερ θα μπορούσαν να
    προκαλέσουν πολλαπλά και, εν δυνάμει, επικίνδυνα προβλήματα.
     
     
     
    Νωρίτερα φέτος, ερευνητές έδειξαν στην πράξη -όχι θεωρητικά- και μάλιστα
    με διάφορα μοντέλα αυτοκινήτων ότι είναι δυνατό ένας χάκερ από απόσταση
    να ανοίξει τις πόρτες του οχήματος ή να ξεκινήσει την μηχανή,
    χρησιμοποιώντας απλά γραπτά μηνύματα.
     
     
     
    Οι δυνητικές κυβερνο-επιθέσεις κατά αυτοκινήτων περιλαμβάνουν, σύμφωνα
    με τη βρετανική «Ντέιλι Μέιλ», την εξ αποστάσεως απενεργοποίηση του
    οχήματος, το κλείδωμα και ξεκλείδωμα του κινητήρα μέσω κινητού
    τηλεφώνου, τον εντοπισμό της ακριβούς γεωγραφικής θέσης του αυτοκινήτου,
    την κλοπή προσωπικών δεδομένων μέσω συστήματος Bluetooth, την
    παρεμπόδιση της πλοήγησης μέσω δορυφορικών συστημάτων κ.α.
     
     
     
    «Όσο ολοένα περισσότερες λειτουργίες ενσωματώνονται στην ψηφιακή
    τεχνολογία των αυτοκινήτων, η απειλή μιας επίθεσης και κακόβουλης
    χειραγώγησης αυξάνει», αναφέρει η έκθεση.
     
     
     
    Η McAfee επισημαίνει ότι η τάση των καταναλωτών-οδηγών είναι να
    επιθυμούν όλο και περισσότερες διασύνδεσης του οχήματός τους, ώστε να
    αποτελεί προέκταση του υπολογιστή και του «έξυπνου» τηλεφώνου τους, όμως
    προειδοποιεί τις αυτοκινητοβιομηχανίες ότι δεν πρέπει καθόλου να
    υποτιμήσουν τους κινδύνους από τυχόν κακόβουλο λογισμικό.
     
     
     
    Πηγή: ΑΠΕ- ΜΠΕ, Π. Δρακόπουλος
  12. Jordan_Tsafaridis
    Η εγκληματικότητα στον κυβερνοχώρο στοίχισε περίπου 114 δισεκατομμύρια δολάρια, και έπληξε 431 εκατομμύρια ανθρώπους σε όλον τον κόσμο το 2010, σύμφωνα με μελέτη που δημοσιεύθηκε από μια εταιρία που κατασκευάζει λογισμικό προστασίας από ιούς των υπολογιστών.
     
     
     
    Σύμφωνα με την έκθεση της εταιρείας Symantec, 74 εκατομμύρια Αμερικανοί έπεσαν πέρυσι θύματα του εγκλήματος στον κυβερνοχώρο, το οποίο τους προκάλεσε συνολικά 32 δισ. δολάρια άμεσες οικονομικές ζημιές.
     
     
     
    Στην Κίνα, το κόστος εκτιμάται ότι ανήλθε σε 25 δισεκατομμύρια δολάρια, στη Βραζιλία σε 15 δισ., και στην Ινδία σε 4 δισ. δολάρια.
     
     
     
    Σύμφωνα με την έρευνα, το 69% των ερωτηθέντων ενηλίκων χρηστών του
    Διαδικτύου έχουν πέσει στη ζωή τους θύματα εγκλήματος στον κυβερνοχώρο,
    ένα ποσοστό που αυξάνεται έως και σε 85% στην Κίνα και σε 84% στη Νότια
    Αφρική.
     
     
     
    Η μελέτη υπογραμμίζει επίσης την αυξανόμενη ανάπτυξη των εγκλημάτων του
    είδους στα κινητά τηλέφωνα. "Η εγκληματικότητα στον κυβερνοχώρο είναι
    πολύ πιο ανεπτυγμένη από όσο φαντάζονται οι άνθρωποι", δήλωσε ο Άνταμ Πάλμερ, σύμβουλος Διαδικτυακής ασφάλειας στην εταιρεία.
     
     
     
    "Κατά τους τελευταίους δώδεκα μήνες, ο αριθμός των ενηλίκων που
    ερωτήθηκαν για τη μελέτη για τα θύματα εγκληματικών πράξεων στον
    κυβερνοχώρο, είναι τρεις φορές μεγαλύτερος από αυτόν των θυμάτων
    εγκληματικών πράξεων στην πραγματική ζωή", τόνισε.
     
     
     
    "Και όμως, λιγότεροι από το ένα τρίτο των ερωτηθέντων πιστεύουν ότι
    είναι πιο πιθανό να πέσουν θύματα ενός εγκλήματος στον κυβερνοχώρο, από
    ό,τι ενός εγκλήματος στη φυσική ζωή", πρόσθεσε ο Πάλμερ.
     
     
     
    Η μελέτη, που έγινε σε δείγμα 20.000 ανθρώπων σε 24 χώρες, διεξήχθη τον Φεβρουάριο και το Μάρτιο του 2011 και καλύπτει τους προηγούμενους δώδεκα μήνες.
     
    Πηγή : www.nooz.gr
     
  13. 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.
     
  14. Jordan_Tsafaridis
    OCS ADVISORY NUMBER:
     
    2012-006

    DATE(S) ISSUED:
     
     
    02/03/2012
     
     

    SUBJECT:
     
    Multiple Vulnerabilities in Apple Mac OS X Could Allow Remote Code Execution
     
    OVERVIEW:
     

    Multiple vulnerabilities have been discovered in Apple's OS X and
    OS X Server that could allow remote code execution. OS X is a desktop
    operating system for the Apple Mac. OS X Server is a server operating
    system for the Apple Mac.

    These vulnerabilities can be exploited if a user visits or is
    redirected to a specially crafted webpage or opens a specially crafted
    file, including an e-mail attachment, while using a vulnerable version
    of OS X. Successful exploitation could result in an attacker gaining
    the same privileges as the logged on user. Depending on the privileges
    associated with the user, an attacker could then install programs;
    view, change, or delete data; or create new accounts with full user
    rights.

    SYSTEMS AFFECTED:


    OS X Lion 10.7 through 10.7.2
    OS X Lion Server 10.7 through 10.7.2
    Mac OS X 10.6.8
    Mac OS X Server 10.6.8

    RISK:
     
    Government:


    Large and medium government entities: High
    Small government entities: High

    Businesses:


    Large and medium business entities: High
    Small business entities: High

    Home users: High

    DESCRIPTION:
     
    Multiple vulnerabilities have been discovered in Apple's OS X that
    could allow both remote and local code execution. These
    vulnerabilities can be exploited if a user visits or is redirected to a
    specially crafted webpage or opens a specially crafted file, including
    an e-mail attachment, while using a vulnerable version of OS X.

    Apple has identified the following vulnerabilities:

    A vulnerability exists in the Address Book application in OS X
    Lion v10.7.2 or earlier. This issue exists because the application will
    attempt an unencrypted connection to obtain CardDAV data if an
    encrypted connection fails. Attackers can exploit this issue by
    performing a man in the middle attack or by intercepting the
    unencrypted data at strategic network locations. Successful
    exploitation could result in the theft of address book contact
    information. This issue affects OS X Lion v10.7 to v10.7.2, OS X Lion
    Server v10.7 to v10.7.2 (CVE-2011-3444)

    An unspecified memory management issue exists in the Font Book
    application due the improper handling of certain data-font files. To
    exploit this issue, an attacker creates a specially crafted data-font
    file and distributes that file to unsuspecting users. When the user
    opens the file with Font Book, the exploit is triggered. Successful
    exploitation could result in remote code execution. This issue affects
    Mac OS X v10.6.8, Mac OS X Server v10.6.8, OS X Lion v10.7 to v10.7.2,
    OS X Lion Server v10.7 to v10.7.2. (CVE-2011-3446)

    An issue exists in the CFNetwork’s handling of malformed URLs
    which could lead to information disclosure. When accessing a
    maliciously crafted URL, CFNetworkcould send the request to an
    incorrect origin server. To exploit this issue, an attacker distributes
    a specially crafted URL to unsuspecting users. When a user visits the
    URL, certain information could be relayed to the attacker. Successful
    exploitation could result in information disclosure which could be used
    to aid additional attacks. This issue affects OS X Lion v10.7 to
    v10.7.2, OS X Lion Server v10.7 to v10.7.2 (CVE-2011-3246)

    An integer overflow vulnerability exists due to the way CFNetwork
    handles certain images with embedded ColorSynch information. To
    exploit this issue, an attacker distributes a specially crafted image
    file to unsuspecting users. When the file is executed, the exploit
    triggers. Successful exploitation could result in remote code
    execution. This issue affects OS X Lion v10.7 to v10.7.2, OS X Lion
    Server v10.7 to v10.7.2  (CVE-2011-3447) and Mac OS X v10.6.8, Mac OS X
    Server v10.6.8 (CVE-2011-0200)

    A buffer overflow vulnerability exists in a CoreAudio component
    of Mac OS X v10.6.8 and Mac OS X Server v10.6.8 due to the improper
    handling of certain encoded audio streams. The specifics of how this
    vulnerability can be exploited are unclear. However, successful
    exploitation does in involve the execution of a specially crafted audio
    content and could result in remote code execution. (CVE-2011-3252)
     
      
     
    A heap buffer overflow exists in a CoreMedia component of OS X due
    to the improper handling on H.264 encoded movie files. To exploit this
    issue, an attacker distributes a specially crafted movie file to
    unsuspecting users. When the file is executed, the exploit is
    triggered. Successful exploitation could result in remote code
    execution. This issue affects Mac OS X v10.6.8, Mac OS X Serverv10.6.8,
    OS X Lion v10.7 to v10.7.2, OS X Lion Server v10.7 to v10.7.2.
    (CVE-2011-3448)

    An unspecified after free issue exists in the handling of certain
    font files. To exploit this issue, an attacker creates and distributes
    a specially crafted file that uses the vulnerable fonts. When the file
    is execution the exploit occurs. Successful exploitation could result
    in remote code execution. This issue affects Mac OS X v10.6.8, Mac OS X
    Server v10.6.8, OS X Lion v10.7 tov10.7.2, OS X Lion Server v10.7 to
    v10.7.2 (CVE-2011-3449)

    An unbounded stack allocation issue exists in CoreUI’s handling
    of long URLs. To exploit this issue, an attacker creates and
    distributes a specially crafted website designed to leverage the issue.
    When a user visits the website the exploit is triggered. Successful
    exploitation could result in remote code execution. This issue affects
    OS X Lion v10.7 to v10.7.2, OS X Lion Server v10.7 to v10.7.2
    (CVE-2011-3450)

    An unspecified buffer overflow vulnerability exists in the
    “uncompress� command line tool. To exploit this issue, an attacker
    distributes a specially crafted compressed file. When the file is
    uncompressed via command line, the exploit is triggered. Successful
    exploitation could result in remote code execution. This issue affects
    Mac OS X v10.6.8, Mac OS X Server v10.6.8, OS X Lion v10.7 tov10.7.2,
    OS X Lion Server v10.7 to v10.7.2 (CVE-2011-0241)

    A buffer overflow exists in libtiff's handling of ThunderScan
    encoded TIFF image files and libpng v1.5.4’s handling of certain PNG
    files. To exploit this issue, an attacker distributes a specially
    crafted TIFF file or PNG file. When the file is executed, the exploit
    is triggered. Successful exploitation could result in code execution.
    This issue affects Mac OS X v10.6.8, Mac OS X Server v10.6.8, OS X Lion
    v10.7 to v10.7.2, OS X Lion Server v10.7 to v10.7.2 (CVE-2011-1167,
    CVE-2011-3328)

    An unspecified issue exists in Libinfo's handling of hostname
    lookup requests. Libinfo could return incorrect results for a specially
    crafted hostname. To exploit this issue, an attacker creates a
    specially crafted website and distributes a link to unsuspecting users.
    When a user visits the site, the exploit is triggered. Successful
    exploitation could result in remote code execution. This issue affects
    OS X Lion v10.7 to v10.7.2, OS X Lion Server v10.7 to v10.7.2
    (CVE-2011-3441)

    An unspecified integer overflow exists in the parsing of certain
    DNS resource records. The details of how this vulnerability can be
    exploited are unavailable. Successful exploitation could allow remote
    code execution. This issue affects Mac OS X v10.6.8, Mac OS X Server
    v10.6.8, OS X Lion v10.7 tov10.7.2, OS X Lion Server v10.7 to v10.7.2
    (CVE-2011-3453)

    Multiple memory corruption issues exist in OpenGL™s handling of
    GLSL compilation. The details of how this vulnerability can be
    exploited are unclear. However, successful exploitation could result in
    arbitrary code execution. This issue affects Mac OS X v10.6.8, Mac OS X
    Server v10.6.8, OS X Lion v10.7 to v10.7.2, OS X Lion Server v10.7 to
    v10.7.2 (CVE-2011-3457)

    Multiple buffer overflow and memory corruption vulnerabilities
    exist in QuickTime which could allow remote code execution. To exploit
    these vulnerabilities, an attacker distributes a specially crafted
    movie or image file to unsuspecting users. When the file is executed
    the exploit is triggered. Successful exploitation could result in
    arbitrary code execution. This issue affects Mac OS X v10.6.8, Mac OS X
    Server v10.6.8, OS X Lion v10.7 to v10.7.2, OS X Lion Server v10.7 to
    v10.7.2 (CVE-2011-3458, CVE-2011-3248, CVE-2011-3459, CVE-2011-3250,
    CVE-2011-3460,CVE-2011-3249)

    An issue exists in the Time Machine application that could allow
    attackers to gain unauthorized access to system backups. The user may
    designate a remote AFP volume or Time Capsule to be used for Time
    Machine backups. Time Machine did not verify that the same device was
    being used for subsequent backup operations. An attacker who is able to
    spoof the remote volume could gain access to new backups created by
    the user's system. This issue affects OS XLion v10.7 to v10.7.2, OS X
    Lion Server v10.7 to v10.7.2. (CVE-2011-3462)

    An issue exists in WebDAV Sharing's handling of user
    authentication. A user with a valid account on the server or one of its
    bound directories could cause the execution of arbitrary code with
    system privileges. The details of how this vulnerability can be
    exploited are unavailable. This issue affects OS X Lion Server v10.7 to
    v10.7.2 (CVE-2011-3463)

    A memory corruption issue existed in FreeType's handling of Type 1
    fonts. To exploit this issue, an attacker distributes a specially
    crafted PDF file which utilizes the vulnerable font. When a user opens
    the file, the exploit is triggered. Successful exploitation could
    result in remote code execution. This issue affects Mac OS X v10.6.8,
    Mac OS X Server v10.6.8, OS X Lion v10.7 to v10.7.2, OS X Lion Server
    v10.7 to v10.7.2 (CVE-2011-3256)

    Successful exploitation of these vulnerabilities could result in
    an attacker gaining the same privileges as the logged on user.
    Depending on the privileges associated with the user, an attacker could
    then install programs; view, change, or delete data; or create new
    accounts with full user rights.  Failed attempts could result in a
    denial-of-service.

    RECOMMENDATIONS:
     
    We recommend the following actions be taken:


    Apply appropriate patches provided by Apple to affected systems immediately after appropriate testing.
    Remind users not to download or open files from un-trusted websites.
    Remind users not to open e-mail attachments from unknown users or suspicious e-mails from trusted sources.
    Remind users not to visit un-trusted websites or follow links provided by unknown or un-trusted sources.
    Run all software as a non-privileged user (one without administrative privileges) to diminish the effects of a
    successful attack.

    Permit local access for trusted individuals only. Where possible, use restricted environments and restricted shells. 

    REFERENCES:
     
    Apple:
     
    http://support.apple.com/kb/HT5130

    Security Focus:
     
    http://www.securityfocus.com/advisories/23952
     
    http://www.securityfocus.com/bid/51807
     
    http://www.securityfocus.com/bid/51808
     
    http://www.securityfocus.com/bid/51809
     
    http://www.securityfocus.com/bid/51810
     
    http://www.securityfocus.com/bid/51811
     
    http://www.securityfocus.com/bid/51812
     
    http://www.securityfocus.com/bid/51813
     
    http://www.securityfocus.com/bid/51814
     
    http://www.securityfocus.com/bid/51815
     
    http://www.securityfocus.com/bid/51816
     
    http://www.securityfocus.com/bid/51817
     
    http://www.securityfocus.com/bid/51818

    CVE:
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3444
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3446
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3246
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3447
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0200
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3252
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3448
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3449
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3459
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0241
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3328
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1167
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3441
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3453
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3457
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3249
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3460
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3250
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3459
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3248
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3458
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3462
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3463
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3256
     
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3450
  15. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι της κοινότητας σκοπός του συγκεκριμένου άρθρου είναι
    να καταδείξω τον τρόπο με τον οποίο είναι δυνατόν να συλλέξουμε προηγμένες (advanced) πληροφορίες από
    τον Forefront TMG 2010 οι
    οποίες πρόκειται να χρησιμοποιηθούν για τεκμηρίωση και εντοπισμό σφαλμάτων (documentation and debugging purposes).

     

    Εισαγωγή
     

    Εξ ορισμού, ο Microsoft Forefront TMG δημιουργεί μια σημαντικά μεγάλη ποσότητα δεδομένων logging από τα Web proxy και Firewall services και τα αποθηκεύει σε μια τοπική Microsoft SQL 2008 SP1
    Server Express βάση δεδομένων. Αυτά τα αρχεία log έχουν σαν αποστολή
    να βοηθούν τους Firewall Administrators ώστε να δημιουργούν αποτελεσματικούς Firewall policy rules καθώς επίσης να διερευνήσουν γιατί κάποια νόμιμη κίνηση
    δεν επιτρέπεται ή και το αντίστροφο.
    Για γενική πληροφόρηση όσον αφορά την κατάσταση (health)
    του Forefront TMG Server μπορούμε να
    χρησιμοποιήσουμε το Forefront TMG dashboard σε συνδυασμό
    με τα Windows event logs. Παρόλα αυτά, όταν επιζητούμε κάποια πιο εξεζητημένη πληροφορία (advanced logging) μπορούμε να χρησιμοποιήσουμε το built in Diagnostic logging του Forefront TMG το οποίο συλλέγει
    περισσότερες χρήσιμες
    πληροφορίες. Εάν και πάλι αυτή η πληροφορία δεν είναι αρκετή τότε μπορούμε να
    χρησιμοποιήσουμε κάποια πιο προηγμένα εργαλεία (more advanced tools)
    τα οποία αποτελούν μέρος του γνωστού σε όλους μας Microsoft Forefront Best Practices Analyser tool.
     

    Το TMG BPA έρχεται μετα παρακάτω
    εργαλεία (περιλαμβάνει και κάποια επιπλέον εργαλεία):
     


    TMG Data packager
    Isainfo
    ISAtrace
    TMGBPApack
     

    Σε αυτό το άρθρο θα παρουσιάσω μια υψηλού
    επιπέδου επισκόπηση –(high level
    overview)- αυτών των εργαλείων και πως να τα
    χρησιμοποιείτε, αλλά επιτρέψτε μου να ξεκινήσω πρωτίστως με το built in
    Diagnostic Logging
    του Forefront TMG.
     

    Το διαγνωστικό logging
     

    Μπορούμε να ξεκινήσουμε
    με το Forefront TMG Diagnostic logging χαρακτηριστικό από το Troubleshooting node μέσα από την Forefront TMG Management console όπως αυτό παρουσιάζεται στην εικόνα 1.
     























    Εικόνα 1: Το Forefront TMG Diagnostic Logging
     

    Κάνουμε κλικ στο
    Enable Diagnostic Logging για να ξεκινήσει
    η διαδικασία συλλογής πληροφοριών.
     

    Ο Forefront TMG αμέσως ξεκινά να συλλέγει πληροφορίες
    από τον ΤMG Server.
    Θα πρέπει να αδρανοποιήσουμε (disable) το Diagnostic Logging από το να εμφανίζει
    την πληροφορία, αφότου έχουμε αποφασίσει ότι η διαδικασία συλλογής πληροφοριών
    έχει συγκεντρώσει αρκετά δεδομένα.
     

    Όπως παρουσιάζεται
    στην εικόνα 2, η διαδικασία Diagnostic logging έχει ήδη συλλέξει περισσότερη πληροφορία απ’ότι χρειάζεται για να
    μας βοηθήσει να καθορίσουμε την αιτία ενός προβλήματος το οποίο έχει εμφανιστεί
    στον Forefront TMG.
     





    Εικόνα 2: Ανάλυση του Forefront TMG Diagnostic Logging
     

    Ο Forefront TMG Data Packager
     

    Εφόσον οι πληροφορίες οι οποίες παρέχονται από τον built in Diagnostic logging του Forefront TMG δεν είναι αρκετές, μπορούμε να χρησιμοποιήσουμε τον Forefront TMG Data
    Packager ο οποίος αποτελεί μέρος του Forefront TMG Best
    Practices Analyzer. Θα βρείτε τον TMG Data Packager μέσα στο installation directory του TMG BPA. Εν συνεχεία επιλέγουμε την πληροφρία την οποία θέλουμε να
    συλλέξουμε. Ξεκινώντας θα συλλέξουμε στατική πληροφορία (static information). Βεβαίως θα σας
    παρουσιάσω ένα μέρος της πληροφορίας από το repro mode αργότερα σε
    αυτό το άρθρο διαμέσου του TMGBPAPack.
     





    Εικόνα 3: Ο Forefront TMG Data
    Packager
     

    Επίσης καθίσταται
    δυνατό να παραμετροποιήσουμε τι είδους πληροφορία θα πρέπει να συλλέξει ο TMG Data Packager.
     





    Εικόνα
    4: Forefront TMG Data Packager – Καθορισμός πληροφορίας προς συλλογή
     

    Για να ξεκινήσει
    η διαδικασία Data collection απαιτείται κάποιο χρονικό διάστημα μέχρι ο TMG Data Packager να ολοκληρώσει την συλλογή του συνόλου των πληροφοριών.
     





    Εικόνα
    5: Forefront TMG Data Packager – Συλλογή δεδομένων
     

    Οταν η διαδικασία
    συλλογής (collection process) ολοκληρωθεί θα βρούμε ένα αρχείο .cab με το σύνολο της πληροφορίας η οποία συλλέχθηκε στην διαδρομή
    δίσκου (directory) την οποία ορίσαμε προηγουμένως. Το
    συγκεκριμένο αρχείο .cab βρίσκεται στην
    διάθεσή μας για την αποθήκευση της εμπεριεχόμενης πληροφορίας (archive the information) ή για να το αποστείλουμε στο Microsoft Product Support. Επιπροσθέτως, εάν θέλουμε να αναλύσουμε περαιτέρω την πληροφορία
    η οποία έχει συλλεχθεί θα πρέπει να χρησιμοποιήσουμε ένα εργαλείο το οποίο
    αποσυμπιέζει την πληροφορία η οποία βρίσκεται συμπιεσμένη εντός του αρχείου .cab.
     





    Εικόνα 6: Forefront TMG Data package
     

    Όπως παρουσιάζεται
    και στην εικόνα 7, μπορείτε να λάβετε γνώση για το αποσυμπιεσμένο περιεχόμενο
    του αρχείου cab. Για τον λόγο αυτό θα σας παραθέσω ορισμένα παραδείγματα σχετικά με
    το περιεχόμενο του αρχείου cab στις εικόνες
    οι οποίες ακολουθούν.
     





    Εικόνα
    7: Περιεχόμενο
    του Forefront TMG Data Packager
     

    Ο TMG Data Packager συλλέγει πληροφορίες σχετικές με Forefront TMG Change tracking feature το οποίο περιλαμβάνει όλη εκείνη την πληροφορία η οποία σχετίζεται
    με τις αλλαγές οι οποίες έχουν πραγματοποιηθεί στο Forefront TMG configuration.
     





    Εικόνα
    8: Το
    Forefront TMG Change tracking αποσυμπιεσμένο από τον TMG Data Packager
     

    Ο TMG Data Packager επίσης συλλέγει πληροφορίες log από το Webproxy και το Firewall Service αντίστοιχα
    του Forefront TMG.
     





    Εικόνα 9: Ο Forefront TMG Data
    Packager και το Firewall and Webproxy log
     

    Ο ISAInfo
     

    Το επόμενο εργαλείο είναι ο ISAInfo. Ενδεχομένως ορισμένοι από εσάς να μην έχετε υπόψην σας το συγκεκριμένο
    εργαλείο και για τον λόγο αυτό μπορείτε να το καυεβάσετε από την ιστοσελίδα www.isatools.org. Η συγκεκριμένη ιστοσελίδα ανήκει (hosted) στον Jim Harrison. Το εργαλείο ISAInfo μέσα από τα ISA Server times ήταν ένα ιδιαίτερα χρήσιμο εργαλείο για την συλλογή πληροφοριών σχετικά με συστήματα ISA Server. Ως άμεσο αποτέλεσμα η Microsoft το συμπεριέλαβε στο Forefront TMG Best
    Practices Analyzer tool.
     





    Εικόνα
    10: Forefront TMG
    – Ο ISAInfo συλλέγει
    δεδομένα
     

    Σε αυτό το σημείο
    θα πρέπει να γνωρίζετε ότι το συγκεκριμένο εργαλείο δεν αναπτύχθηκε εξ αρχής (not to be completely redesigned) για να συνεργάζεται σωστά με τον Forefront TMG με αποτέλεσμα
    να λαμβάνετε ορισμένα αναδυόμενα μηνύματα λάθους (error message popups)
    καθόσον η διαδικασία συλλογής πληροφοριών του ISAInfo βρίσκεται εν λειτουργία (running) τα οποία
    όμως σε κάθε περίπτωση μπορείτε να τα αγνοήσετε.
     





    Εικόνα
    11: Forefront TMG ISAInfo. Αγνοείστε τα μηνύματα λάθους
     

    Ο ISAInfo δημιουργεί δύο αρχεία. Ένα αρχείο log με πληροφορίες σχετικές με τα εργαλεία του ISAInfo και ένα αρχείο XML το οποίο
    περιλαμβάνει το σύνολο των πληροφοριών οι οποίες είναι σχετικές με τον
    συγκεκριμένο Forefront TMG Server στον οποίο τρέχει.
     





    Εικόνα 12: Forefront TMG – ISAInfo log αρχείο
     

    Ο ISATRACE
     

    Το επόμενο
    εργαλείο είναι ο ISATRACE. Ξεκινώντας με τον ISA Server 2004 SP2
    (Εάν δεν με απατά η μνήμη μου), η Microsoft ξεκίνησε να συλλέγει
    προηγμένες πληροφορίες του ISA σε ένα αρχείο
    .bin αποθηκευμένο στο τοπικό σύστημα αρχείων (local file system)
    - (ISALOG.BIN).
    Ο Forefront TMG Best Practices Analyzer περιμβάνει ένα
    γραφικό εργαλείο (GUI tool)
    το οποίο μπορούμε να το χρησιμοποιήσουμε για να παραμετροποιήσουμε το μέγεθος
    αλλά και το είδος της πληροφορίας η οποία θα συλλέγετε. Μπορείτε να βρείτε το συγκεκριμένο
    εργαλείο σην διαδρομή δίσκου (directory) η οποία ονομάζεταιTracing μέσα στην διαδρομή εγκατάστασης (installation directory) του TMG BPA.
     

    Το εργαλείο αυτό μας επιτρέπει να επιλέξουμε διαφορετικά Forefront TMG components όπως π.χ. το Firewall service, το Webproxy service, το Firewall Control Channel (client), το User Interface και πολλά άλλα. Επίσης
    είναι δυνατόν να αλλάξουμε την εξ ορισμού διαδρομή δίσκου (default directory) του αρχείου log αλλά και το μέγεθος του αρχείου ISATRACE.
     





    Figure 13: Forefront TMG – “ISA” Release Bits tracking
     

    Ο TMGBPAPack
     

    Ο TMGBPAPack επίσης αποτελεί αναπόσπαστο μέλος του Forefront TMG Best
    Practices Analyzer. Αποτελεί ένα command line tool το οποίο είναι
    παρόμοιο με το TMG Data Packager αλλά με κάποιες
    εξαιρέσεις (η μοναδική διαφορά απ’ότι είμαι σε θέση ναγνωρίζω είναι ότι συλλέγει
    πληροφορίς σχετικά με το network traffic με την βοήθεια του Microsoft Netmon
    3.3). εάν δε ενεργοποιήσουμε το Repro Mode όλο το network traffic θα συλλέγετε εντός των αρχείων trace του Netmon.
     





    Εικόνα
    14: Ο
    Forefront TMG BPA Pack συλλέγει πληροφορίες
     

    Εάν το Microsoft Network Monitor δεν είναι εγκατεστημένο, τότε το TMGBPAPack εγκαθιστά το Microsoft Netmon
    3.3 (Η τελευταία διαθέσιμη έκδοση του Netmon είναι η 3.4).
     

    Μόλις σταματήσουμε
    το Netmon trace,
    ο TMGDATAPack δημιουργεί ένα και μόνο αρχείο .cab στην επιφάνεια γραφείου (Desktop) όπου μπορούμε
    να το αποσυμπιέσουμε επιτόπου και να μελετήσουμε τις πληροφορίες οι οποίες
    έχουν συλλεγεί εντός του επιπροσθέτου directory το οποίο δημιουργείτε
    για τον σκοπό font size=αυτό και ονομάζεται NetworkCaptures και το οποίο
    περιλαμβάνει όλα τα Netmon Capture αρχεία.
     





    Εικόνα 15: Ο Forefront TMG BPA Pack –
    Συνέλεξε τα Netmon traces
     

    Ε’ιμαστε πλέον
    σε θέση να χρησιμοποιήσουμε την εγκατεστημένη έκδοση του Microsoft Network Monitor για την ανάλυση των Netmon capture αρχείων όπως αυτό εμφανίζεται στην εικόνα 16.
     





    Εικόνα 16: Το Microsoft Netmon 3.3
    trace με Forefront TMG traffic από το internal network interface
     

    Συμπέρασμα
     

    Σε αυτό το άρθρο προσπάθησα να σας παρουσιάσω μια σειρά από χρηστικά εργαλεία για τον Forefront TMG και τον TMG Best Practice Analyser για την συλλογή πληροφοριών σχετικά με το Forefront TMG configuration. Επίσης ασχολήθηκα με τα αρχεία log τα οποία δημιουργούνται από τον Forefront TMG ή από το λειτουργικό σύστημα των Windows στο οποίο είναι εγκατεστημένος. Ολοκληρώνονταςμπορείτε να χρησιμοποιήσετε την πληροφορία αυτή για τεκμηρίωση ή για την ανάλυση
    προβλημάτων τα οποία προκύπτουν στο
    TMG configuration. Τα συγκεκριμέναδεδομένα είναι επίσης εξαιρετικά χρήσιμα για την
    Microsoft εάνανοίξετε ένα
    case στο Microsoft product support.    
  16. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι της κοινότητας η λογική του συγκεκριμένου άρθρου είναι να καταδείξει την μέθοδο βήμα προς βήμα την οποία θα πρέπει να ακολουθήσουμε έτσι ώστε να προστατεύσουμε με την χρήση αντιγράφων ασφαλείας τις Exchange databases χρησιμοποιώντας τον DPM 2010.

    A guide for Recovering the databases and contents will be provided.

    Προαπαιτούμενα

    Έχουμε πραγματοποιήσει επιτυχώς την εγκατάσταση του Microsoft Data Protection Manager 2010.



    Ξεκινώντας ελέγχουμε εάν υπάρχει διαθέσιμος χώρος δίσκου με βάση τον όγκο των δεδομένων τα οποία θέλουμε να προστατεύσουμε. Επιπροσθέτως η χωρητικότητα του/των δίσκων οι οποίοι πρόκειται να χρησιμοποιηθούν για την συγκεκριμένη εργασία θα πρέπει να είναι unallocated όπως ακτιβώς παρουσιάζεται στην παρακάτω εικόνα.







     Εκκινούμε (Start up) την “DPM 2010 Administrator Console” και εν συνεχεία πηγαίνουμε στο “Management”, όπου σε πρώτη φάση κάνουμε κλικ στο “Rescan” έτσι ώστε όλοι οι δίσκοι να γίνουν refreshed και αμέσως μετά κάνουμε κλικ στο “Add” button.







     Αυτόματα ο Disk 1 εμφανίζεται, τον επιλέγουμε και κάνουμε κλικ στο “Add” button και αμέσως μετά κάνουμε κλικ στο “OK”.









    Το αποτέλεσμα της προσθήκης του δίσκου εμφανίζεται στην παρακάτω εικόνα όπου ο δίσκος εμφανίζεται κάτω από το Disks tab.







     Κάτω από το “Management”, κάνουμε κλικ στο tab “Agents”. Εν συνεχεία κάνουμε κλικ στο “Install…” button.







     Επιλέγουμε το “Install agents” και αμέσως μετά κάνουμε κλικ στο Next.







     Επιλέγουμε τον Exchange server και κάνουμε κλικ στο “Add”.







     Η επιλογή έχει ολοκληρωθεί, και εν συνεχεία κάνουμε κλικ στο Next.







     Εισάγουμε τα credentials, όπου απαιτείται να είναι ένας λογαριασμός με δικαιώματα administrator στον συγκεκριμένο server. Αμέσως μετά κάνουμε κλικ στο  Νext.







     Λόγω του ότι θα πρέπει να έχουμε εμείς τον έλεγχο του server επιλέγουμε να κάνουμε το restart εμείς χειροκίνητα. Εν συνεχεία κάνουμε κλικ στο Next.







     Εγκατάσταση του Agent και το αντίστοιχο installation process information εμφανίζονται και κάνουμε κλικ στο Close.







     Ο server θα πρέπει να εμφανιστεί κάτω από το Agents tab στην Console.







     Επιλέγουμε το “Protection” από τα menu, και κάνουμε κλικ στο “Create Protection group…”







    Το Information window εμφανίζεται. Αμέσως κάνουμε κλικ στο Next.







    Στην συγκεκριμένη περίπτωση αυτό που θέλουμε να προστατεύσουμε είναι ένας Server, επιλέγουμε το Servers και κάνουμε κλικ στο Next.







     Ανοίγουμε/Ξετυλίγουμε τον Server και επιλέγουμε το “Exchange 2010 Databases”, όπου όλες οι databases είναι επιλεγμένες. Κάνουμε κλικ στο Next.







     Δίνουμε στο Protection group ένα χαρακτηριστικό όνομα, το οποίο στην συγκεκριμένη περίπτωση είναι το “Exchange Protection Group”. Κάνουμε κλικ στο Next.







     Στο σημείο αυτό θέλουμε να χρησιμοποιήσουμε το χαρακτηριστικό του DPM το οποίο ελέγχει την ορθότητα των δεδομένων χρησιμοποιώντας το eseutil, και αμέσως μετά κάνουμε κλικ στο Next.
     
    Το Ese.dll και το Eseutil.exe πρέπει να αντιγραφούν από τον Exchange server και να τοποθετηθούν μέσα στο DPM installation path, και συγκεκριμένα στον φάκελο Bin.







     Κάνουμε κλικ στο Next. (Μιας και το περιβάλλον μας περιλαμβάνει έναν και μόνον server)







     Επιθυμία μας είναι να αποθηκεύουμε τα backups για 7 ημέρες καθώς επίσης το backup να τρέχει κάθε 15 λεπτά της ώρας, και τέλος το Full Backup κάθε μέρα στις 20:00 η ώρα. Αμέσως μετά κάνουμε κλικ στο Next.







     Κάνουμε κλικ στο Next.








    Θέλουμε στο σημείο αυτό να δημιουργήσουμε την δική μας replica άμεσα. Εάν όμως πρόκειται για ένα production environment τότε η συμβουλή μου είναι η διαδικασία αυτή να γίνει όταν ο φόρτος δικτυακός/επεξεργαστικός βρίσκεται σε ένα μέσο επίπεδο.

    Κάνουμε κλικ στο Next.








    Στο σημείο αυτό θα πρέπει να τρέξουμε ένα consistency check στις replicas.
    Κάνουμε κλικ στο Next.








     Αμέσως μετά εμφανίζεται το summary. Κάνουμε κλικ στο Create Group.







     Η δημιουργία των Replicas έχει ξεκινήσει. Κάνουμε κλικ στο Close όταν η διαδικασία αυτή έχει ολοκληρωθεί.









    Απαιτείται κάποιος χρόνος εως ότου η διαδικασία δημιουργίας των replicas ολοκληρωθεί, και είναι κάτι το οποίο εξαρτάται από το μέγεθος των exchange databases.







    Μετά από λίγα λεπτά οι databases θα πρέπει να εμφανιστούν με status ότι είναι προστατευμένες, με άλλα λόγια το status είναι OK.







    Στο σημείο αυτό θα ήθελα να συστήσω την εξερεύνηση του Reporting part έαν θέλουμε να έχουμε κάποιας μορφής reports σχετικά με τα backups.



    Ο Exchange server είναι τώρα προστατευμένος χρησιμοποιώντας τον Microsoft Data Protection Manager 2010.
    Ελπίζω ότι το συγκεκριμένο άρθρο θα σας φανεί ιδιαίτερα χρήσιμο.

  17. 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, έφτασε η ώρα να προσθέσουμε ορισμένα λειτουργικά
    συστήματα σε αυτό. Υπομονή μέχρι την δημοσίευση του δευτέρου μέρους του
    συγκεκριμένου άρθρου.
  18. 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. Υπομονή μέχρι το τρίτο μέρος.
  19. 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.
    Ζητώ την υπομονή σας μέχρι την δημοσίευση του τέταρτου μέρους της σειράς αυτής
    άρθρων.
  20. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι της κοινότητας στο τέταρτο αυτό μέρος
    αυτής της σειράς άρθρων έφτασε πλέον η στιγμή να παρουσιάσουμε την διαδικασία
    εγκατάστασης των Windows
    από
    το deployment
    image το
    οποίο έχουμε προηγουμένως δημιουργήσει.
     

    Εισαγωγή
     

    Στο προηγούμενο
    άρθρο της συγκεκριμένης σειράς σας παρουσίασα τον τρόπο με τον οποίο μπορείτε να
    δημιουργήσετε ένα deployment image
    και εν
    συνεχεία την προσθήκη του στο Windows Deployment Service. Παρότι το image
    το οποίο
    δημιουργήσαμε είναι εκκινήσιμο (bootable) σε αυτό το χρονικό
    σημείο ωστόσο στην πραγματικότητα δεν είναι έτοιμο προς χρήση. Με δεδομένη την πρόθεσή
    μας να δημιουργήσουμε ένα private cloud
    ο αντικειμενικός
    στόχος μας είναι να είμαστε σε θέση να δημιουργήσουμε εικονικές μηχανές “on
    the fly” διαμέσου ενός self-service
    console. Συνεπώς για να είναι δυνατή η επίτευξη αυτού
    του στόχο απαιτείται το κάθε deployment image
    που θα
    υλοποιήσουμε να γίνει normalized.
     

    Όπως όλοι πιθανώς
    γνωρίζετε, κάθε εγκατάσταση των Windows περιλαμβάνει πληροφορίες
    οι οποίες σχετίζονται με το όνομα του υπολογιστή (computer name) καθώς επίσης και
    μια ταυτότητα SID η οποία καθορίζει με μοναδικό τρόπο τον κάθε
    υπολογιστή στο δίκτυο. Συνεπώς, οι εικονικές μηχανές οι οποίες τρέχουν τα Windows
    δεν δύναται
    να αντιγραφούν (cloned) εφόσον τρέχουν μια
    κανονική εγκατάσταση των Windows διότι διαδικασία
    αντιγραφής (Cloning Process) θα οδηγούσε στην
    ύπαρξη διπλών μηχανών (duplicate machines)
    στο δίκτυο. Συνεπώς στην περίπτωσή μας, θα πρέπει να κάνουμε normalize το
    deployment image
    το οποίο
    έχουμε ήδη δημιουργήσει. Κατά την εφαρμογή του Normalizing στο
    image αφαιρείται κάθε μοναδική πληροφορία ταυτοποίησης
    (uniquely identifying information)
    έτσι ώστε η εικονική μηχανή να μπορεί να αναπαραχθεί όσες φορές χρειάζεται.
     

    Έχοντας τα παραπάνω
    υπόψην μας, ας προχωρήσουμε μπροστά δημιουργώντας μια εικονική μηχανή και εν συνεχεία
    κάνοντας normalize στην συγκεκριμένη εικονική μηχανή
    χρησιμοποιώντας το deployment image
    το οποίο
    έχουμε ήδη δημιουργήσει. Η διαδικασία ξεκινά σε έναν server
    ο οποίος
    τρέχει τον Hyper-V στον οποίο
    δημιουργούμε μια καινούρια εικονική μηχανή. Στην πράξη, φορτώνουμε στην μνήμη τον
    Hyper-V Manager
    και εν συνεχεία
    επιλέγουμε την εντολή New | Virtual
    Machine από το Actions
    pane. Όταν ο New Virtual
    Machine Wizard ξεκινά, κάνουμε κλικ
    στο Next για να προσπεράσουμε το Welcome
    screen.
     

    Στα προηγούμενα
    άρθρα της σειράς δημιουργήσαμε deployment images
    για τα Windows
    7 και για τον Windows Server 2008 R2
    αντίστοιχα. Για την συγκεκριμένη παρουσίαση θα χρησιμοποιήσουμε το Windows
    7 deployment image.
    Για τούτο τον λόγο, καθορίζουμε το Windows 7 Image
    ως το
    όνομα της εικονικής μηχανής. Αυτή η οθόνη μας δίνει την δυνατότητα της επιλογής
    αποθήκευσης της εικονικής μηχανής σε διαφορετική διαδρομή δίσκου. Εάν ‘εχουμε καθορίσει
    συγκεκριμένο αποθηκευτικό μέσο για την αποθήκευση των εικονικών μηχανών τότε
    προτείνεται η άμεση χρησιμοποιήσή του.
     

    Κάνουμε κλικ
    στο Next και αυτομάτως ο wizard
    θα μας ρωτήσει
    πόση μνήμη RAM θέλουμε να δεσμεύσουμε για την συγκεκριμένη
    εικονική μηχανή. Προτείνω την δέσμευση τουλάχιστον 1024 MB.
     

    Η επόμενη οθόνη
    μας ερωτά πια κάρτα δικτύου (network adapter)
    θα πρέπει να χρησιμοποιήσει η εικονική μηχανή. Εξ ορισμού οι εικονικές μηχανές είναι
    ρυθμισμένες έτσι ώστε να μην συνδέονται στο δίκτυο. Άρα λοιπόν θα πρέπει να είμαστε
    βέβαιοι ότι έχουμε επιλέξει μια κάρτα δικτύου πριν κάνουμε κλικ στο Next.
     

    Στην αμέσως επόμενη
    οθόνη θα μας ζητηθεί να ορίσουμε το μέγεθος του εικονικού σκληρού δίσκου (virtual
    hard disk) τον οποίο θέλουμε
    να χρησιμοποιήσουμε. Προτείνω την χρήση – δέσμευση κατ’ελάχιστον 50 GB. Θα πρέπει να λάβετε υπόψην σας ότι ο Hyper-V
    χρησιμοποιεί
    την τεχνική του thin provisioning εξ
    ορισμού, στοιχείο το οποίο σημαίνει ότι ακόμη και αν καθορίσετε το μέγιστο μέγεθος
    των 2040 GB στην πράξη το αρχείο του εικονικού δίσκου (actual
    virtual hard disk
    file) θα έχει μέγεθος το οποίο θα αντιστοιχεί στον όγκο των
    δεδομένων τα οποία είναι αποθηκευμένα εντός αυτού.
     

    Στην αμέσως επόμενη
    οθόνη ερωτόμαστε εάν θέλουμε να εγκαταστήσουμε ένα λειτουργικό σύστημα. Θα πρέπει
    να βεβαιθούμε ότι έχουμε επιλέξει την επιλογή εγκατάστασης του λειτουργικού συστήματος
    από το δίκτυο (network based
    installation server),
    όπως αυτό απεικονίζεται στην Εικόνα 1. Αμέσως μετά κάνουμε κλικ στο Finish
    για να
    δημιουργήσουμε την εικονική μηχανή.
     






















     
    Εικόνα 1: Πρέπει
    να παραμετροποιήσουμε την εικονική μηχανή έτσι ώστε να χρησιμοποιεί την εγκατάσταση
    διαμέσου του δικτύου (network based
    installation).
     

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

    Όταν επιστρέψουμε
    πίσω στην κύρια οθόνη του Hyper-V
    Manager κάνουμε διπλό κλικ στην μόλις δημιουργηθήσα εικονική
    μηχανή για κάνουμε επισκόπηση σε αυτήν. Αρχικώς η εικονική μηχανή είναι ανενεργή
    (powered off), γι’αυτό επιλέγουμε
    την εντολή Start από το μενού Action
    για να
    την ενεργοποιήσουμε. Μετά από ένα χρονικό διάστημα ενός ή το πολύ δύο λεπτών της
    ώρας η εικονική μηχανή θα αποκτήσει μια IP
    address από τον DHCP
    server τον οποίο έχουμε εγκατεστημένο. Μόλις αυτό συμβεί θα πρέπει
    ταχύτατα να πιέσουμε το πλήκτρο F12 για να ξεκινήσει η
    διαδικασία του network boot.
    Σε αυτήν την χρονική στιγμή, η εικονική μηχανή φορτώνει στην μνήμη ένα Windows
    pre-boot περιβάλλον, το οποίο
    απεικονίζεται στην Εικόνα 2.
     




     
    Εικόνα 2: Η
    εικονική μηχανή φορτώνει ένα pre-boot
    environment.
     

    Στην παραπάνω
    οθόνη θα πρέπει να είστε σίγουροι ότι έχετε επιλέξει το σωστό keyboard layout και εν συνεχεία
    κάνουμε κλικ στην επιλογή Run the
    Deployment Wizard
    to Install a
    New Operating System
    option. Αμέσως μετά θα σας ζητηθεί να εισάγεται το username,
     το domain
    name, και το password τα οποία θα
    χρησιμοποιηθούν για την σύνδεση στο δικό σας deployment share.
     

    Μετά την
    εισαγωγή των, κάνουμε κλικ στο OK. Εν συνεχεία θα μας ζητηθεί
    να επιλέξουμε το λειτουργικό σύστημα το οποίο θέλουμε να εγκαταστήσουμε, όπως
    αυτό απεικονίζεται στην Εικόνα 3. Οι επιλογές μας είναι αντίστοιχες των deployment images που έχουν καθοριστεί
    προηγουμένως.
     




     
    Εικόνα 3: Επιλέγουμε
    το λειτουργικό σύστημα το οποίο επιθυμούμε να εγκαταστήσουμεl.
     

    Κάνουμε κλικ
    στο Next και αυτομάτως θα μας ζητηθεί να εισάγουμε το
    όνομα του υπολογιστή (computer name).
    Θα πρέπει να τονίσουμε εδώ ότι το όνομα του υπολογιστή μας είναι αδιάφορο διότι
    πολύ απλά πρόκειται να κάνουμε normalize στο image,
    γι’αυτο κάνουμε κλικ στο Next για να αποδεχτούμε το
    εξ ορισμού όνομα (default name).
     

    Η επόμενη οθόνη
    μας ρωτά εάν θέλουμε να συνδεδθούμε σε ένα domain.
    Σε καμία περίπτωση δεν θα πρέπει να συνδεθούμε σε ένα domain
    στην
    συγκεκριμένη χρονική στιγμή. Αντιθέτως θα πρέπει να επιλέξουμε την επιλογή Join
    a Workgroup και αμέσως μετά
    κάνουμε κλικ στο Next.
     

    Στην επόμενη
    οθόνη ερωτόμαστε εάν θέλουμε να κάνουμε επαναφορά των δεδομένων χρήστη (restore
    user data). Επιλέγουμε την επιλογή Do Not Restore User Data and Settings και κάνουμε κλικ στο Next.
     

    Σε αυτό το σημείο κάνουυμε επαλήθευση για την επιλογή της σωστής γλώσσας, χρόνου – νομίσματος και πληκτρολογίου – ( verify that the appropriate language, time and
    currency format, and keyboard layout) – και κάνουμε κλικ στο Next. Τώρα, μπορούμε να επιλέξουμε την χρονική ζώνη
    (time zone) και κάνουμε κλικ
    στο Next.
     

    Η επόμενη οθόνη
    η οποία θα εμφανιστεί είναι εξόχως σημαντική. Θα πρέπει να επιλέξουμε την επιλογή
    Capture an Image
    of this Reference Computer, όπως αυτό απεικονίζεται
    στην Εικόνα 4. Το πεδίο τοποθεσίας (Location field)
    θα πρέπει να παραπέμπει στο δικό σας deployment share
    και θα πρέπει
    να καθορίσουμε ένα μοναδικό όνομα για το το οποίο πρόκειται να δημιουργήσουμε.
     




     
    Εικόνα 4: Yπρέπει
    να δημιουργήσουμε (capture) ένα reference image της συγκεκριμένης
    εικονικής μηχανής.
     

    Αμέσως μετά
    κάνουμε κλικ στο Next το οποίο ακολουθείται
    από το Begin. Το pre-installation environment θα ξεκινήσει την εγκατάσταση
    των Windows 7 όπως απεικονίζεται στην Εικόνα 5.
     




     
    Εικόνα 5: Τα
    Windows 7 εγκαθιστώνται από μια διαδρομή δικτύου (network
    share).
     

    Μετά την ολοκλήρωση
    της βασικής διαδικασίας εγκατάστασης των Windows,
    η εικονική μηχανή απορρίπτει το pre-installation environment και δημιουργεί ένα αρχείο
    image (.WIM), όπως απεικονίζεται
    στην Εικόνα 6.
     




     
    Εικόνα 6: Η
    εικονική μηχανή δημιουργεί ένα αρχείο .WIM
    το οποίο
    βασίζεται στην εγκατάσταση η οποία έχει ολοκληρωθεί πριν από λίγο.
     

    Όπως
    θα θυμάστε,
    το pre-installation environment απαιτεί
    από εμάς να παράσχουμε ένα σύνολο από credentials τα
    οποία θα χρησιμοποιηθούν για την σύνδεση με το deployment share. Ο
    λόγος για τον οποίο θα πρέπει να παράσχουμε αυτά τα credentials είναι γιατί το αρχείο .WIM το
    οποίο δημιουργήθηκε κατά την ολοκλήρωση εγκατάστασης των Windows έχει
    εγγραφεί στο deployment share
    χρησιμοποιώντας την διαδρομή την οποία έχουμε εισάγει.
     

    Συμπέρασμα
     

    Τώρα που έχουμε
    ένα image το οποίο μπορεί να χρησιμοποιηθεί για την ανάπτυξη
    άλλων εικονικών μηχανών βρισκόμαστε στον σωστό δρόμο όσον αφορά την δημιουργία ενός
    private cloud. Οι ίδιες οι εικονικές
    μηχανές τρέχουν επάνω στον Hyper-V.
    Σε συνέχεια των προηγουμένων άρθρων, σας υπενθυμίζω ότι έχουμε δημιουργήσει  ένα Hyper-V
    deployment image
    και αυτό
    το image μπορεί να συνδυαστεί με την τεχνική την οποία
    σας παρουσίασα στο συγκεκριμένο άρθρο για να δημιουργήσετε μια σειρά από Hyper-V
    servers.
     

    Βεβαίως ο Hyper-V
    αποτελεί
    απλά μια πλατφόρμα φιλοξενίας εικονικών μηχανών (virtual
    machine hosting platform).
    Η πραγματική υποδομή private cloud
    θα βασιστεί
    επάνω στον System Center Virtual
    Machine Manager και στην έκδοση 2.0 του
    Self Service Portal.
    Στο επόμενο άρθρο της συγκεκριμένης σειράς θα σας παρουσιάσω τον τρόπο με τον οποίο
    θα δημιουργήσετε μια υποδομή private cloud.
    Αργότερα δε, θα σας παρουσιάσω το τρόπο με τον οποίο χρησιμοποιώντας το image
    το έχουμ
    πριν από λίγο δημιουργήσει για να κάνουμε δυναμική δημιουργία (dynamically generate) εικονικών μηχανών
    μέσα στο private cloud.
     

    Εάν θέλετε να διαβάσετε και τα προηγούμενα άρθρα
    της συγκεκριμένης σειράς δεν έχετε παρά να κάνετε κλικ στους παρακάτω
    διαδικτυακούς συνδέσμους:
     

    Πως μπορούμε χρησιμοποιώντας τον Hyper-V να
    κατασκευάσουμε μια υποδομή Private Cloud (Μέρος 1ο)
     

    Πως μπορούμε χρησιμοποιώντας τον Hyper-V να
    κατασκευάσουμε μια υποδομή Private Cloud (Μέρος 2ο)
     

    Πως μπορούμε χρησιμοποιώντας τον Hyper-V να
    κατασκευάσουμε μια υποδομή Private Cloud (Μέρος 3ο)
    span style=
  21. 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. 
     
  22. Jordan_Tsafaridis
    Όπως και στο προηγούμενο άρθρο μου σχετικά με την ανακάλυψη του νέου Stuxnet-like worm με το όνομα Duqu ενδιαφέρον παρουσιάζει και το άρθρο του Jeff James το οποίο δημοσιεύθηκε στις 19/10/2011 και ώρα 12:14μμ στον ιστότοπο www.windowsitpro.com το οποίο παρουσιάζει επιπλέον πληροφορίες σχετικά με το νέο worm. Ζητώ και πάλι την κατανόησή σας, αλλά πιστεύω ότι το συγκεκριμένο άρθρο δεν προσφέρεται για μετάφραση και για τον λόγο αυτό το παραθέτω αυτούσιο στην Αγγλική γλώσσα.


    In June 2010, security experts, analysts, and software providers were
    warning IT managers about Stuxnet, a new computer worm that was
    spreading rapidly over the internet. Stuxnet was distributed by Windows
    machines, and the intent of the worm wasn't immediately clear. After a
    few months it was revealed that the vast majority of Stuxnet infections
    were in Iran, and Stuxnet seemed to have been specifically targeting the
    Siemens industrial control equipment used in the Iranian nuclear
    program.
    German security expert Ralph Langner was interviewed by NPR reporter Tom Gjelten
    earlier this year about Stuxnet, and Gjelten reported that Langner told
    him that the worm was so complex and sophisticated that it was "almost
    alien in design" and believed that only the United States had the
    resources required to create Stuxnet and orchestrate the attack. As more
    details emerged, it became clear that Stuxnet was likely developed by
    either Israeli or American intelligence agencies in an attempt to impede
    Iran's nuclear program.
    Both Israeli and American security
    officials have sidestepped questions about their involvement, but Gary
    Samore, White House Coordinator for Arms Control and Weapons of Mass
    Destruction, stated at a December 2010 conference on Iran that "we're
    glad they [the Iranians] are having trouble with their centrifuge
    machine and that we – the US and its allies – are doing everything we
    can to make sure that we complicate matters for them." [source: NPR’s Need to Know]
    Now security researchers from Symantec have revealed that they've discovered a new Stuxnet-like worm called W32.Duqu that shares much of the same code with Stuxnet. Symantec's Security Research blog posted details about Duqu yesterday:

    "Duqu
    shares a great deal of code with Stuxnet; however, the payload is
    completely different. Instead of a payload designed to sabotage an
    industrial control system, the payload has been replaced with general
    remote access capabilities. The creators of Duqu had access to the
    source code of Stuxnet, not just the Stuxnet binaries. The attackers
    intend to use this capability to gather intelligence from a private
    entity to aid future attacks on a third party. While suspected, no
    similar precursor files have been recovered that predate the Stuxnet
    attacks.
    According to Symantec, Duqu also functions as a
    keylogger designed to "capture information such as keystrokes and
    system information" but lacks the specific code related to "industrial
    control systems, exploits, or self-replication." Symantec's research
    team believes that Duqu is collecting information for a possible future
    attack, and seem to point the finger at the original creators of
    Stuxnet, since the creators of Duqu seem to have direct access to
    Stuxnet source code:

    The creators of Duqu had access to
    the source code of Stuxnet, not just the Stuxnet binaries. The
    attackers intend to use this capability to gather intelligence from a
    private entity to aid future attacks on a third party. While suspected,
    no similar precursor files have been recovered that predate the Stuxnet
    attacks.
    The arrival of Stuxnet signaled that
    cyberattacks have entered a new phase, with nation states and
    professional, highly-skilled programmers helping elevate cyberwarfare to
    a new, more sophisticated (and dangerous) level. Microsoft Technical
    Fellow Mark Russinovich offers up a fictional account of what can happen
    when terrorist groups turn to cyberwarfare in his novel Zero Day, and it's a chilling preview of what the future of warfare could look like.
    While
    many fingers are pointing at U.S. and Israeli intelligence service for
    creating Stuxnet – and possibly Duqu -- what happens when a hostile
    nation or well-organized terrorists develop the same level of
    cyberwarfare capability? Questions like these are undoubtedly keeping IT
    security professionals and experts at government security agencies
    awake at night.
    For more technical information on the Duqu worm, see Symantec’s W32.Duqu: The Precursor to the Next Stuxnet whitepaper [PDF] and a Symantec post that provides additional Duqu technical details.
    What
    are your thoughts on Stuxnet and Duqu worms? Let me know what you think
    by adding a comment to this blog post or starting up a conversation on Twitter.
    Ελπίζω να το βρείτε ενδιαφέρον. 
  23. Jordan_Tsafaridis
    Το Multi-Tenant Cloud
    Κατά την διάρκεια του Microsoft Build conference το οποίο έλαβε χώρα από τις 13 εως τις 16 Σεπτεμβρίου 2011 στο Anaheim, η Microsoft παρουσιάσε μια πρώτη γεύση των χαρακτηριστικών του Windows Server 8, που περιλαμβάνει όπως είναι αναμενόμενο και τον Hyper-V, ο οποίος θα επιτρέπει σε επιχειρήσεις να υποστηρίζουν εγκαταστάσεις Infrastructure as a Service (IaaS) χρησιμοποιώντας public, private
    και hybrid, καθώς επίσης και αρχιτεκτονικές multitenant cloud. Ένα multi-tenant cloud αποτελεί ένα cloud infrastructure το οποίο έχει την δυαντότητα να φιλοξενεί (hosting) services (workloads) για πολλαπλές επιχειρήσεις (Αγγλικός Όρος : distinct departments within a
    single company in a private cloud, or distinct companies in a public
    cloud) ενώ ταυτόχρονα διασφαλίζει την ασφάλεια των δεδομένων διατηρώντας σε ασφαλή απομόνωση τον φόρτο εργασίας μεταξύ των διαφόρων ενοικιαστών ( 
    tenants
    ).
    Επιπλέον, μια υποδομή  
    multi-tenant cloud είναι σε θέση δυναμικά να διαχειρίζεται και να αναδιανέμει
    tenant workloads
    σε οποιοδήποτε διαθέσιμο host στο cloud χωρίς να γίνεται κανένας συμβιβασμός στην ασφάλεια των δεδομένων λόγω της ασφαλούς απομόνωσης του φόρτου εργασίας. Τέλος, η υποδομή
    multi-tenant cloud
    πρέπει να είναι σε θέση να παρέχει και να εγγυηθεί τις ευδιάκριτες
    Service Level Agreements (SLAs)
    που είναι βασισμένες στις οργανωτικές απαιτήσεις, και παρέχουν τον πόρο που μετρά με βάση παραμέτρους οι οποίες εγγυώνται την σωστή μέτρηση για την χρήση των πόρων σύννεφων σε κάθε οργάνωση. Προκειμένου να ενεργοποιηθούν  
    multi-tenant cloud
    υποδομές, ο
    Windows Server 8
    περιλαμβάνει μια σειρά νέων τεχνικών χαρακτηριστικών γνωρισμάτων τα οποία περιλαμβάνουν  
    Hyper-V, storage, network,
    high-availability, disaster recovery, και manageability.
     .
     

    Τεχνικά χαρακτηριστικά του Hyper-V Core στον Windows Server 8 
    Στον Windows Server
    8, τα χαρακτηριστικά του Hyper-V εμπλουτίστηκαν και βελτιώθηκαν, έχοντας σαν αποτέλεσμα την θεαματική βελτίωση του virtual machine performance
    και το κυριότερο απ'όλα παρέχει εκείνη την αναβαθμιζόμενη βάση για virtualization η οποία είναι απαραίτητη για υποδομές cloud.
    Στον πίνακα 1 παρουσιάζεται μια σύγκριση μεταξύ των χαρακτηριστικών του Hyper-V key ανάμεσα στον Windows
    Server 2008 R2 και τον Windows Server 8.

     
     

    Hyper-V Χαρακτηριστικά

    Windows Server 2008 R2

    Windows Server 8

    Host Memory

    1 TB

    2 TB

    Logical Processors

    64 (Max)

    160 (Max)

    Guest VM Memory

    64 GB (Max)

    512 GB (Max)

    Guest Virtual Processors

    4 per VM (Max)

    32 per VM (Max)

    Guest NUMA

    N

    Y

    Host Failover Cluster

    Y (16 nodes)

    Y (63 nodes)

    VM Support - Failover Cluster

    1000 (Max)

    4000 (Max)

    Live Migration

    Y (serial)

    Y (concurrent)

    Live Migration (no cluster or shared storage)

    N

    Y

    Live Storage Migration

    N

    Y

    Table 1: Hyper-V - Σύγκριση χαρακτηριστικών
    Παρακάτω σας παραθέτω, αυτούσιο στην Αγγλική το κείμενο στο οποίο παρουσιάζονται αναλυτικά τα καινούρια χαρακτηριστικά, και σας παρακαλώ να με συγχωρέσετε για την μη μετάφραση στην Ελληνική γλώσσα διότι όπως θα διαπιστώσετε και εσείς λόγω των τεχνικών όρων δεν προσφερεται για μετάφραση.

     
    Hyper-V now supports 2 TB of physical memory and a maximum of 160
    logical processors. In Hyper-V, it is not only cores that are included
    in the logical processor count, so are threads if a core is Simultaneous
    Multi-Threading (SMT) enabled. Therefore, the following formula is
    handy to calculate the number of logical processors that Hyper-V can see
    on a given physical server:

    # of Logical Processors = (# of Physical Processors) * (# of Cores) * (# of Threads per Core)

    The increase in memory and logical processor support in Windows
    Server 8 provides the basis upon which to build dense virtual machine
    populations for private and public cloud infrastructures. In addition,
    Hyper-V in Windows Server 8 supports enhanced virtual machine
    performance by enabling the assignment of up to 512 GB of RAM and 32
    virtual processors to a virtual machine. That can easily accommodate
    scale up of high-performing workloads especially coupled with
    intelligent resource management features like dynamic memory, and new
    networking and storage management features that you will discover later
    in this article.

    For systems and applications that are built on top of a non-uniform
    memory access (NUMA) architecture, Windows Server 8 provides guest NUMA.
    Guest NUMA means that Hyper-V ensures guest virtual machine processor
    and memory affinity with physical host resources.

    Another upgraded feature in Windows Server 8 is the expansion of
    failover clusters to 63 nodes (from 16 nodes in Windows Server 2008 R2),
    effectively quadrupling the size of a cluster and the number of running
    virtual machines to 4000 (from 1000 in Windows Server 2008 R2) per
    cluster.

    With Windows Server 8, Hyper-V also supports multiple, concurrent
    live migrations of virtual machines. The number of concurrent live
    migrations is bounded only by the inherent resource constraints of the
    infrastructure rather than the serial limitation imposed in Hyper-V on
    Windows Server 2008 R2.

    And while Live Migration has been a cluster-centric feature requiring
    shared storage, the story gets significantly better in Windows Server 8
    with the support for live migration of a virtual machine between any
    two hosts without requiring clustering, shared storage, or any shared
    resources other than a network connection. You can control which Hyper-V
    hosts participate in this Live Migration mode, as well as the number of
    concurrent live migrations allowed by a host, and the network to use to
    perform the live migration. Furthermore, there is additional
    granularity in the selection of virtual machine components to migrate,
    allowing you to choose all components, including the VHD files, current
    configuration, snapshots, and second level paging, or only some of these
    components. You also have the ability to move the virtual machine data
    to a single location, or to specify individual locations for every
    selected virtual machine component.

    As if all this goodness wasn’t enough, Hyper-V also provides Live
    Storage Migration that supports moving virtual machine storage resources
    between physical storage units without service interruption.

    Hyper-V Key Storage Features στον Windows Server 8
    One of the
    main new Hyper-V storage features is the addition of a virtual Fibre
    Channel HBA adapter for virtual machines. This allows a virtual machine
    to connect to a Fibre Channel SAN, and enables new scenarios like guest
    clustering, use of MPIO, and other multipathing solutions for workloads
    that require high-performing SAN and application availability. This
    feature is available to existing Windows virtual machines like Windows
    Server 2008 R2 running on Hyper-V on Windows Server 8.

    Another new storage feature is the VHDX format, a new virtual hard
    disk (VHD) format that is introduced in Windows Server 8. With VHDX, the
    maximum size of a VHD increases to 16 TB, instead of the current 2 TB
    limit with the current VHD format which forces the use of pass-through
    disks to meet larger virtual disk storage requirements. The VDHX format
    also provides large sector support, and allows embedding user-defined
    metadata.

    Along with the increase in virtual disk size is an impressive
    performance boost when creating or managing large VHDX-based formats
    using the Offloaded Data Transfer (ODX) features of storage systems.
    Hyper-V support for ODX in Windows Server 8 allows handing off
    operations like data transfers and file creations to the storage system
    which can perform the actions with much higher performance while
    reducing the impact of associated operations on the Hyper-V host
    processor.

    Hyper-V Key Network Features στον Windows Server 8
    On the
    networking side, one the of the key Hyper-V features in Windows Server 8
    is the extensible Hyper-V switch. The Hyper-V switch is the component
    that controls the configuration and creation of external, internal, and
    private networks that support virtual machine connectivity to physical
    networks, to other virtual machines and the Hyper-V host, or to a subset
    of virtual machines, respectively. In Windows Server 2008 R2, the
    Hyper-V switch functionality cannot be modified. In Windows Server 8, an
    API exists that enables extension of the Hyper-V switch functionality.
    Microsoft’s goal is to enable security vendors to develop new security
    appliances as pluggable switch modules, enable switch vendors to create
    switch extensions that unify virtual and physical switch management, and
    enable network application vendors to create network monitoring
    extensions for the Hyper-V switch. Taking advantage of the Hyper-V
    switch extensibility, Cisco Systems has already announced support for Windows Server 8 Hyper-V with its Cisco Nexus 1000V switch.

    Probably one of the most requested networking features included in
    Windows Server 8 and supported by Hyper-V is NIC teaming. Up through
    Windows Server 2008 R2, NIC teaming has only been available as a
    third-party option. Windows Server 8 provides native NIC teaming that is
    configurable at the host (parent partition) or virtual machine (guest
    partition) level in either load balancing or failover mode. As a bonus,
    this new NIC teaming feature even works across different vendor network
    adapters.
    Ελπίζω ότι τα παραπάνω θα σας φανούν ιδιαίτερα χρήσιμα.
     
     
  24. 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. Ελπίζω ότι θα σας φανεί ιδιαιτέρως χρήσιμο.


     
  25. 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.
×
×
  • Create New...