gvarakis

Πτωχέ Σίμο ... ξεχνάς πως ήταν developer ... [H]

<πρίζα mode = on> Δεν το στήνεις κι όλας και να το πας βήμα βήμα, να έχεις να ασχολείσαι για κανά δίμηνο; <πρίζα mode = off> Πολύ πολύ καλό το δεύτερο άρθρο της σειράς! Κάνε τώρα και ένα για τον Exchange 2007 --> 2010, γιατί στο technet είναι πολλές οι σελίδες και έχουμε και τεμπέληδες εδώ

Κώστα σωστά σε πάει στο ECP, γιατί εκεί είναι το control panel με τα options, αλλά το λάθος είναι το θέμα του authentication ... Δες λίγο κάτω από τον IIS, αν έχει διαφορετικά settings το ECP σε σχέση με το OWA ... Αν δεν παίρνεις error στο event viewer, μήπως τουλάχιστον έχεις authentication failure στο security log?

Σωστόςςςςς ....

Ομοίως ακολούθησα τη διαδικασία του Technet (1 role at a time) και όλα έπαιξαν με τη μία. Το μόνο που αντιμετώπισα, ήταν ότι μετά την εγκατάσταση του πρώτου ρόλου (CAS) είτε μέσα από EMC είτε από shell, δεν μπορούσα να πάρω τα Virtual Directory του OutlookWebApp & ExchangeActiveSync. Χρειάστηκε να προσθέσω το group "Exchange Trusted Subsystem" στον 2007 CAS, για να μπορέσω να δω τα αντίστοιχα Virtual Directories. Το workaround το βρήκα στα Microsoft Support Forums, και από όσο έψαξα ΔΕΝ περιλαμβάνεται στο Technet Exchange 2010 Library ... Ο HUB εγκαταστάθηκε χωρίς παρατράγουδα, παίρνοντας τις σωστές ρυθμίσεις από τον 2007 HUB. Τέλος ο Mailbox εγκαταστάθηκε και αυτός χωρίς κάτι το ιδιαίτερο, ενώ με το που ολοκληρώθηκε η εγκατάσταση και έκανα move έναν test user, όλες οι δοκιμές (2010 <-> 2007 & 2010 <-> Ιντερνετ) ήταν επιτυχείς. Να σημειώσω βέβαια πως δεν έχω προχωρήσει σε αλλαγές στο εξωτερικό μου δίκτυο, και την εισερχόμενη κίνηση ακόμη την υποδέχεται ο HUB 2007. Keep you posted [H]

Αυτό το Σ/Κ σκοπεύω να κάνω το αντίστοιχο Migration, ενώ λόγω του Blackberry Enterprise Server που τρέχει στην εταιρεία, θα πρέπει να κρατήσω κάποια mailboxes στον Exchange 2007 μέχρι να αναβαθμίσω το BES. Αν βρεθεί κάτι παρόμοιο στο δρόμο μου θα ενημερώσω ...

Επίσης να συμπληρώσω ότι με την εργοστασιακή NC375i ακόμα και μετά από τις ρυθμίσεις του offloading, όπου κατάφερα να παίζουν τα VM's 2008 που είχα εγκαταστήσει, είχα τα εξής συμπτώματα : 1) To Host Machine, σερνότανε στο δίκτυο (εννοείται με δικό του dedicated NIC και όχι shared στο Virtual Switch) 2) Κάποια Windows Server 2003 που έκανα P2V με τον SCVMM μου έριχναν ΟΛΟ το δίκτυο (Virtual Switch ΚΑΙ Host Server NIC) μόλις σηκώνονταν μετά τοP2V Βγάλε άκρη ...

ΔΕΝ το βγάζω, μέχρι να παραδώσω το έργο, γιατί θέλω να δω αν θα μου βγάλει κάτι στο άμεσο μέλλον

Update : Αντικατέστησα την εργοστασιακή κάρτα NC375i με μία NC360T (dual port Gigabit με Intel 82571EB chipset) και παίξανε τα πάντα μια χαρά, ΧΩΡΙΣ να χρειαστεί να πειράξω ούτε offloading ούτε τίποτα. Τα VM σηκώνονται και συνδέονται κανονικά, ενώ και όλα τα P2V τρέξανε άκοπα και αβίαστα με το SCVMM. Να συμπληρώσω επίσης ότι η NC375i ΔΕΝ περιλαμβάνεται στο σχετικό compatibility list της HP για Windows Server 2008 Hyper-V, σε αντίθεση με την NC360T Με τις υγείες μας ...

Εγώ αυτό που λέω, είναι πως όσο λάθος είναι το perception "Αφού τα αγοράσαμε τα 2000 νόμιμα, γιατί να αναβαθμίσουμε;;;" το ίδιο λάθος είναι και το "Αφού το έχουμε πληρώσει το firewall, γιατί να το αλλάξουμε;" Δεν το βλέπω από τη μεριά της μπίζνας, το βλέπω από τη μεριά της ανάπτυξης της τεχνολογίας στη χώρα μας. Και ειλικρινά, χωρίς να θέλω να θίξω το Γιώργο (τον οποίο εκτιμώ απεριόριστα) με λυπεί που ακόμα και άνθρωποι που είναι και με το παραπάνω technology/security aware, πέφτουν στο τριπάκι να "γκρινιάξουν" (έστω και δειλά) γιατί το 10ετίας τεχνολογικό προϊόν τους δεν υποστηρίζεται πλέον... Ανεξάρτητα από vendors & business approach!

Καλά τα λέτε. Αλλά ρε παιδιά, παίρνουμε με τις πέτρες όποιον δουλεύει ακόμα με Windows 2000 & Exchange 2003, αγοράζουμε Double Quad-Core Xeon & Hyper-V R2, και θεωρούμε σωστό και πρέπον (και φυσικά, όχι άδικα!) να έχουμε στημένη την τελευταία λέψη της τεχνολογίας που μας παρέχει η Microsoft, αλλά μας φαίνεται την ίδια ώρα μια χαρά να δουλέυουμε με το PIX, που το αγοράσαμε το 2000, έχουμε να το κάνουμε update (γιατί δεν βγαίνει πλέον update) από το 2005, και μας φαίνεται παράλογο να αναβαθμίσουμε το Cisco ... επειδή είναι device και είναι στον δρόμο τον κακό;;; Ε, τότε και η Microsoft μας κοροϊδεύει, που δεν βγάζει ένα Service Pack, να μπορούμε να κάνουμε Direct Access με Windows Server 2000!!!

Αφού έχει και quantity discount ... Τώρα αν αφού το βάλεις στο "χέρι", σε αφήνει να το βάλεις σε "όσους", δεν το ξέρω, αλλά πάντος αν πας να αγοράσεις on-line, σου ζητάει Quantity, και ανάλογα, σου παρέχει και έκπτωση ...

Γεια σου ρε Γιώργο! Παρόλα αυτά το κόστος της εφαρμογής είναι μεγάλο και σε μια κλίμακα 5+ χρηστών, συμφέρει να πάρεις ένα ASA5505-SEC και να τελειώνεις με το AnyConnect ... Έχουμε κάνει επανηλλημένα παράπονα προς τη Cisco, αλλά ως συνήθως, δεν ιδρώνει το αυτί τους ... Η απάντηση είναι, το PIX τελείωσε, πάρτε ASA. Από την άλλη βέβαια, το PIX υποστηρίζει και PPTP / IPSec-L2TP remote VPN access, οπότε μπορείς πάντα να το χρησιμοποιήσεις και να μην έχεις πρόβλημα με το client κομάτι!

Έτσι, έτσι, να πληθαίνουμε οι ... πολυγραφότατοι Good Job CF!

Ο Exchange σου είναι ακόμα σε λειτουργία ή όχι;

Υπάρχει διαθέσιμο σε Beta μορφή, ένα external connectivity tester για τον Access Edge Server του OCS. Προς το παρόν, μας δίνει τη δυνατότητα να τρέξουμε δύο είδη test, όπου στο ένα δίνουμε εμείς το DNS name του Access Edge Server, user SIP URI, username, password και η μηχανή ελέγχει το αν και κατά πόσο μπορεί να κάνει επιτυχημένο logon στην υπηρεσία, ενώ το δεύτερο δεν ζητάει το DNS name, αλλά χρησιμοποιεί τον auto-configure μηχανισμό που χρησιμοποιεί και ο Communicator Client (αναλυτική περιγραφή εδώ), ώστε να βρει τον κατάλληλο Access Edge Server και να κάνει τη σχετική δοκιμή. Το καλό με το εργαλείο, είναι ότι δίνει τα αποτελέσματα σε βήματα, βοηθόντας με αυτό τον τρόπο τη διαδικασία του troubleshooting, σε βασικά στάδια. Συγκεκριμένα ελέγχει : Αν υπάρχει το σωστό DNS SRV record, και αν αυτό γίνεται resolve σε IP Address (εντοπισμός DNS misconfiguration) Αν η IP έχει ανοιχτό το Port TCP 443 ώστε να δέχεται client authentication request (εντοπισμός Firewall misconfiguration) Αν το Certificate που είναι εγκατεστημένο είναι valid. (Εδώ χρειάζεται προσοχή, αν το πιστοποιητικό μας ΔΕΝ είναι από External CA, δεν θα περάσουμε το step, χωρίς όμως αυτό να σημαίνει πως οι χρήστες μας δεν μπορούν να σνυδέεονται στον Access Edge Server!) Αν μπορεί να κάνει logon με τα credentials που του δώσαμε. Τα παραπάνω τεστ πρόκειται να εμπλουτιστούν σε επερχόμενες εκδόσεις του εργαλείου, όπου θα περιλαμβάνουν περισσότερες πληροφορίες, προκειμένου να μπορούν να χρησιμοποιηθούν και για advanced troubleshooting. Το εργαλείο θα βρείτε και μπορείτε να χρησιμοποιήσετε online εδώ

Αυτό το τελευταίο σε πάει καρφί για τον εισαγγελέα κύριε Κλαδάκη!!! Πιαστήκατε επ' αυτοφόρω!!!

Υπάρχει ένα πρόβλημα όταν τρέχουμε τον Hyper-V ρόλο, σε Windows Server 2008 x64 με SP2 (δεν έχω εξετάσει ακόμα αν ισχύει χωρίς SP2, ή για έκδοση R2) στον server HP ML370 G6, ο οποίος χρησιμοποιεί την κάρτα δικτύου Quad Port NC375i. Πιο συγκεκριμένα, όταν φτιάχνουμε ένα Virtual Switch και το κάνουμε bind σε κάποιο από τα network port, το Guest VM, ενώ παίρνει IP από DHCP, δεν περνάει κανενός άλλου είδους traffic από και προς το εξωτερικό δίκτυο (ενώ επικοινωνεί κανονικά με το Host Server). Το παράδοξο, είναι ότι τρέχοντας Wireshark στο Guest VM, φαίνονται πακέτα να φεύγουν και να επιστρέφουν (πχ ένα DNS query φεύγει από το Guest, και επιστρέφει απάντηση από τον DNS) αλλά παρόλα αυτά το σύστημα παίρνει time-out. Υπάρχουν δύο workaround σε αυτό. Legacy NIC on VM Ναι, καλά διαβάζετε, μόλις έβαλα (για δοκιμή) Legacy Network Adapter σε ένα από τα VM, το δίκτυο δούλεψε χωρίς κανένα απολύτως πρόβλημα! Μόνο που μόλις σήκωσα έναν exchange 2003 μετά από P2V και του έδωσα Legacy NIC, μου κρέμαγε ΟΛΟ το δίκτυο, τόσο στο VM, όσο και στο Host (Και φυσικά και σε όλα τα VM’s). Οπότε ψάχνοντας λίγο καλύτερα, βρήκα το παρακάτω (νομίζω το είχε γράψει και ο Νάσος σε παλιότερο post, με άλλη συμπτοματολογία και άλλο εντελώς configuration) το οποίο από όσο κατάλαβα είναι και best practice (άν όχι ΑΠΑΡΑΙΤΗΤΟ όταν δουλεύουμε με Hyper-V) Disable offloading on Netowrk Card Ενώ όταν έκανα disable IPv4 checksum offload, πήρα κανονικά ICMP, η χαρά μου κόπηκε το ίδιο απότομα, αφού δεν κατάφερα να κάνω τίποτε άλλο, εκτός από το παίρνω dhcp & icmp. Οπότε, έκανα disable ΟΤΙΔΗΠΟΤΕ έχει να κάνει με offloading επάνω στην κάρτα δικτύου και κατάφερα να πάρω το πολυπόθητο network functionality και να προχωρήσω τις δουλειές μου. Στη συγκεκριμένη κάρτα υποστηρίζεται (και άρα θέλει disable) : IPv4 Checksum Offload TCP Checksum Offload IPv4 TCP Checksum Offload IPv6 UDP Checksum Offload IPv4 UDP Checksum Offload IPv6 ΥΓ 1 : Για να χαλαρώσουμε και λίγο … περιττό να αναφέρω τι είχα σούρει (από μέσα μου, ε στον αγαπητό Vangeli μέχρι να επιλυθεί το πρόβλημα και να δουλέψει ο Hyper-V ώς θα όφειλε … και για να τα ανάψω λίγο ακόμα (τα αίματα) … με το VMWare δεν είχαμε αντίστοιχο θέμα (όχι που δεν θα το έστηνα στον 2ο 370G6 για τη σχετική δοκιμή) ΥΓ 2 : Μάλλον αποτελεί BEST PRACTICE, να κάνουμε disable το οποιοδήποτε offloading υποστηρίζεται από τις σύγχρονες κάρτες δικτύου όταν πρόκειται να τις χρησιμοποιήσουμε με Hyper-V. Είναι έτσι; Ας επιβεβαιώσει ο Βαγγέλης, ή κάποιος άλλος αν το έχει συναντήσει και αλλού … .

@GSimos : Στον εισαγγελέα όμως κολώνεις να πας ε;

Και το δικό μου το πρώτο έτσι ήταν Χαχαχαχα ΑΡΛΕΚΙΝ ! ! !

Και ΜΗ φανταστείτε ότι θα λείπω εγώ ... παίζει και διαγωνισμός πίτσας;;; [H]

Περιμένατε το επόμενο άρθρο για OCS; ΧΑ! Σας την έφερα! Και καθώς όπως είπαμε ο OCS δεν είναι στην καθημερινότητά μας (σε αντίθεση με τον Exchange), είπα να γράψω για ένα σχετικό θέμα, το οποίο βλέπαμε το απόγευμα παρέα με εκλεκτό συνάδελφο, και αφού μου κέντρισε την περιέργεια και το έψαξα, είπα να το μοιραστώ και μαζί σας για κάθε ενδεχόμενο (μακρυά από εσας!) Όλοι μας έχουμε χρησιμοποιήσει τη δυνατότητα αυτή που παρέχει ο Exchange Server 2007 για clients Outlook 2007. Ναι, για αυτό το μαγικό μιλάω, που ανοίγεις το outlook 2007, σε αναγνωρίζει, σε συνδέει και με τον Exchange, και παίρνεις το προφίλ σου έτοιμο για χρήση σε χρόνο dt… Έχουμε όμως ποτέ σκεφτεί πώς ακριβώς δουλεύει αυτό το “μαγικό” και τι κάνουμε αν θέλουμε για κάποιο λόγο να επέμβουμε σε αυτό; Πάω στοίχημα … όχι Και γιατί να θέλουμε να το πειράξουμε δηλαδή; Μια χαρά δε δουλεύει από μόνο του; Μια χαρά δουλεύει … αλλά ας δούμε πρώτα … πώς; Το συγκεκριμένο service, τρέχει στον Client Access Server (CAS) και συγκεκριμένα στο URL http://CAS/Autodiscover/Autodiscover.xml Πώς όμως βρίσκει ο client αυτό το service, ώστε να μάθει τα πάντα για τον Exchange Organization και να κάνει τα προαναφερθέντα ‘μαγικά’; Εδώ υπάρχουν δύο περιπτώσεις. Αν ο Η/Υ είναι joined στο domain (ας πούμε στο autoexec.gr), τότε υπάρχει στο Active Directory καταχωρημένο ένα Service Connection Point (SCP) το οποίο δείχνει στον CAS, και ο client πάει όμορφα και ωραία και τον ρωτάει. Μαθαίνει λοιπόν τελικά ποιος είμαι ο Mailbox Server του χρήστη, και παράλληλα μαθαίνει πλήθος χρήσιμων πληροφοριών, όπως Outlook Anywhere External URL, Offline Address Book (OAB) download URL, Unified Messaging URL, Out of Office information URL, Availability Service (Πρώην free/busy). Είναι προφανές, πως για να αλλάξουμε τη σχετική πληροφορία, θα πρέπει να επέμβουμε στο Active Directory. Ο τρόπος να το κάνουμε αυτό είναι μέσα από το Exchange Management Shell, δίνοντας την παρακάτω εντολή (πληροφοριακά, αλλάζει το περιεχόμενο του attribute msExchOutlookProvider που περιέχεται στο object msExchDiscoveryConfig στο Active Directory) : Set-OutlookProvider –id exch –server:CAS (όπου προφανώς αλλάζουμε το CAS με το σωστό NetBIOS name του σχετικού CAS) Εναλλακτικά, μπορούμε και με τον “αντρικό” τρόπο, να πάμε να σφάξουμε, με χρήση ADSIEdit… Αλλά προφανώς προτιμάτε τον καλλιτεχνικό … Έτσι δεν είναι; Τέλος πάντων, ξέρω ότι σας τρώει η περιέργεια … CN=<CAS_server>,CN=AutoDiscover,CN=Protocols,CN=<CAS_Server>,CN=Servers,CN=Exchange Administrative Group, CN=AdministrativeGroup,CN=<Organization>,CN=Services,[Configuration Naming Context]. Στην περίπτωση που ο υπολογιστής δεν είναι joined στο domain, τότε το Outlook έχει hardcoded τη δυνατότητα να ψάξει για το σχετικό service, με βάση το e-mail του χρήστη, και απομονώνοντας το SMTP domain (πχ από το [email protected], θα απομονώσει το autoexec.gr) ψάχνοντας στα παρακάτω URL : https://autoexec.gr/Autodiscover/Autodiscover.xml https://autodiscover.autoexec.gr/Autodiscover/Autodiscover.xml Με την εφαρμογή του Hotfix που περιγράφεται στο KB 939184, δίνεται επιπλέον η δυνατότητα αναζήτησης με βάση ένα σχετικό SRV Record στην αντίστοιχη ζώνη : _autodiscover._tcp.autoexec.gr (port 443) Το παραπάνω record μπορεί να δείχνει στο όνομα του mail server (πχ mail.autoexec.gr) κάτι το οποίο διευκολύνει πάρα πολύ τη διαδικασία των σχετικών πιστοποιητικών (αφού η σχετική σύνδεση είναι SSL) αφού διαφορετικά θα πρέπει να περιλαμβάνουμε και το αντίστοιχο όνομα (autodiscover.autoexec.gr) στο SSL Certificate του Client Access Server… Είναι λοιπόν επίσης προφανές, πως για να αλλάξουμε τη συμπεριφορά του σχετκού Service για Η/Υ που δεν είναι joined στο domain, ο μοναδικός τρόπος είναι να αλλάξουμε το σχετικό DNS SRV record, ή να φτιάξουμε τα σχετικά A / CName records που αντιστοιχούν στο σχετικό όνομα. *** Είναι πολύ σημαντικό εδώ να επισημάνουμε, πως η ίδια διαδικασία χρησιμοποιείται, και όταν ο client είναι joined στο domain, βρίσκεται εκτός του εσωτερικού δικτύου (χρησιμοποιεί Outlook Anywhere) και έχει εγκατεστημένο Office Communicator Client (συνδέεται πάνω από Access Edge Server) και προσπαθεί να ενημερώσει το Free/Busy information στο Presence! (όχι, που θα έγραφα post που να μην έχει ΚΑΙ OCS!!!) Περισσότερα σχετικά με το τελευταίο σε πιο αναλυτικό post, ειδικά για αυτό. Ελπίζω να βρείτε τα παραπάνω ενδιαφέροντα, και κυρίως ΑΝ ποτέ σας κάτσει … χρήσιμα! .

Bad habbits die hard ... και όταν διαβάσει ο Κλαδάκης ότι κάτι το κάνουν καλύτερα οι άλλοι ... βγάζει σπυριά. Τι να τον κάνουμε; Τον συνηθίσαμε

Καλώς τον μας κι ας άργησε (ακόμη περισσότερο και από εμένα δηλαδή...) Γρήγορος άκουσα ... για να δούμε Καλή αρχή και καλή χρονιά κύριε Κουρή !

Σωτήρη και Νάσο ευχαριστώ πολύ για τα καλά σας λόγια, τα οποία δεν σας κρύβω πως μαζί με το Read Count & Rating είναι αυτό που περιμένει ο blogger, σαν την "ανταμοιβή" του για τον κόπο και το χρόνο του (αν μπορεί να το αποκαλέσει κανείς έτσι...). Παρόλα αυτά, ο OCS δεν είναι το προϊόν της καθημερινότητάς μας, οπότε είναι φυσικό και αναμενόμενο να μην τραβάει τα βλέματα η σχετική θεματολογία. Επειδή όμως πέρασα ένα δύσκολο καλοκαίρι στήνοντας OCS για έναν αρκετά μεγάλο (σε μέγεθος) και εξαιρετικά απαιτητικό πελάτη, και διαπίστωσα πως το περιεχόμενο που υπήρχε στο διαδύκτυο για την "φρέσκια" τότε ακόμη έκδοση του R2 ήταν περιορισμένο, αποφάσισα (μετά από το σχετικό μαστίγωμα βεβαίως-βεβαίως, κανείς δεν το γλυτώνει...) να ασχοληθώ με το θέμα, και ας είναι πιο ... δύσπεπτο σε σχέση με άλλα της σύγχρονης εποχής. Ήδη πάντως ξέρω από καλό συνάδελφο, πως έστειλε μηχανικό να κάνει εγκατάσταση edge server και του είπε "μην με ρωτάς, διάβασε το blog στο autoexec.gr ..." Από όσο ξέρω η εγκατάσταση ολοκληρώθηκε με επιτυχία Καλή μας χρονιά και πάλι!