Jump to content

i-away

Members
  • Posts

    462
  • Joined

  • Last visited

Blog Entries posted by i-away

  1. i-away
    Στο προηγούμενο post μας είχαμε εγκαταστήσει 2 CAS + Mailbox Server και 2 Hub Transport Server. Στο post αυτό θα παραμετροποιήσουμε τα Database Availability Groups μεταξύ των 2 Mailbox servers.
    Όπως είναι γνωστό θα πρέπει να έχει εγκατασταθεί το Failover Cluster feature απο τον Server Manager. Επίσης θα πρέπει να επιλέξουμε 1 Witness server ( προτείνεται κάποιος Hub Transport ) και αν θέλουμε και 1 Alternate Witness Server.
    Με την βοήθεια του Powershell λοιπόν:


    Αφού δημιουργήσαμε το DAG ας προσθέσουμε τον 1ο server:






    Get-DatabaseAvailabilityGroup | FL Name,*IP*


    Name : ConotosoDAG

    DatabaseAvailabilityGroupIpv4Addresses : {}


    DatabaseAvailabilityGroupIpAddresses : {}


    Το DAG χρειάζεται 2 διαφορετικά network 1 Public και 1 για το μεταξύ τους Replication.


    Public Network: 178.65.32.36/24

    Replication Network: 192.168.0.0/16


    Όπότε :




    και


    New-DatabaseAvailabilityGroupNetwork -DatabaseAvailabilityGroup ContosoDAG -Name Backup -Description "Backup Network" -Subnets 192.168.0.0/16 -ReplicationEnabled:$True





    Δίνουμε και την Group IP:







    Και τώρα μπορούμε να προσθέσουμε τον 2ο server μας στο DAG.











    Aς δημιουργήσουμε τώρα τις 3 databases:











    Ελέγχουμε ότι όλα πήγαν καλά:










    Get-MailboxDatabaseCopyStatus





    Τις κάνουμε mount:








     


    Και τις προσθέτουμε στο DAG έτσι ώστε να γίνουν replicate και στον άλλον server:








    Έλέγχουμε την κατάσταση του replicatation:











    Και αφού όλα είναι εντάξει κάνουμε το replication:











    Βάζουμε mailboxes στις DAG databases.







    Ελέγχουμε την κατάσταση του Move Request:







    Εφόσον πάρουμε status “Completed” μπορούμε να κάνουμε remove το request:







    Υπάρχουν όμως και κάποια “κρυφά” mailboxes:






















    Τώρα μπορούμε να σβήσουμε τις default mailbox databases.










    Ελέγχουμε και το replication health status για να δούμε ότι όλα πάνε καλά:












    Με την επιτυχή ολοκλήρωση του παραπάνω έχουμε 3 databases και ένα πλήρως λειτουργικό DAG περιβάλλον . Στο επόμενο post θα δούμε την δημιουργία mailboxes για τους πελάτες μας.



  2. i-away
    Πρίν απο λίγο έγινε μία ευχάριστη ανακοινώση που επιβεβαίωσε κάτι που είχα πει σε παλαιότερο post μου:"Τhe Microsoft Exchange team is enhancing positioning by including
    additional supported scenarios regarding Exchange Server 2010 running
    under hardware virtualization software. As of today, the following
    support scenarios are being updated, for Exchange 2010 SP1, and later:Combining Exchange 2010 high availability solutions (database
    availability groups (DAGs)) with hypervisor-based clustering, high
    availability, or migration solutions that will move or automatically
    failover mailbox servers that are members of a DAG between clustered
    root servers, is now supported."
     
    Όπως μπορείτε να καταλάβετε λοιπόν θα υπάρχουν πλέον και high available Dagged mailbox servers κάτι που δεν υπήρχε μέχρι σήμερα θέτοντας αρκετούς περιορισμούς στο Design.
     
    Μείνετε συντονισμένοι για περισσότερες λεπτομέρειες εντός των ημερών.
     
    Το πλήρες κείμενο της ανακοίνωσης θα το βρείτε εδώ . Πίσω στο σχεδιαστήριο λοιπόν...
     
  3. i-away
    Θέλοντας να μπω κι εγώ στο κλίμα του Cloud και ερχόμενος αντιμέτωπος με εταιρείες που θέλουν μεν cloud αλλά θέλουν και να το διαχειρίζονται κιόλας εξυπηρετώντας τους πελάτες τους. Ήρθα αντιμέτωπος με το θέμα του mail-hosting. Όπως ξέρετε υπάρχουν πολλές εταιρείες που προσφέρουν mail-hosting σε Exchange servers . Στην σειρά αυτή των Posts θα δούμε πως μπορούμε να υλοποιήσουμε ένα τέτοιο σενάριο.
    Το περιβάλλον που θα δημιουργήσουμε θα αποτελείται από:
    * 2 x 1 Hub Transport Role * 2 x 1 CAS + Mailbox Role
    Ας ξεκινήσουμε λοιπόν. Το πρώτο πράγμα που θα πρέπει να κάνουμε είναι να κατεβάσουμε τον Microsoft Exchange Server 2010 SP1: http://www.microsoft.com/downloads/details.aspx?FamilyID=50b32685-4356-49cc-8b37-d9c9d4ea3f5b&displaylang=en
    Η εγκατάσταση του Exchange σε Hosting mode γίνεται μόνο από command line καθώς δεν υπάρχει κάποιο GUI περιβάλλον.
    Ανοίγουμε λοιπόν cmd και ξεκινάμε:
    servermanagercmd /ip Exchange-All.xml
     

     
    Βέβαια μπορείτε να χρησιμοποιήσετε και την εντολή:
    C:\ExchangeSP1>Setup.com /mode:Install /roles:CA,HT,MB /hosting /organizationname:hosting
    Αφού τελειώσουμε την εγκατάσταση θα πρέπει να ρυθμιστεί και η υπηρεσία NetTcpPortSharing ώστε να ξεκινάει αυτόματα:
    Από powershell :
    Set-Service NetTcpPortSharing –startuptype Automatic
    Επίσης θα χρειαστούμε τα Remote Server Administration Tools:
    Από powershell :
    ServerManagerCmd -i RSAT-ADDS
    Κατά την διάρκεια της εγκατάστασης θα μας ζητηθεί και το Office 2010 filter pack. http://www.microsoft.com/downloads/details.aspx?familyid=5CD4DCD7-D3E6-4970-875E-ABA93459FBEE&displaylang=en
    Ξεκινάμε λοιπόν την εγκατάσταση και εγκαθιστούμε τον 1ο Hub Transport Server μας:
    setup.com /mode:install /role:HT,MT /organizationName:HostedExchange /hosting

     
     
    Για όσους αναρωτιούνται για τις διαφορές έχει το schema του Active Directory ενός “ κλασικού “ Exchange από έναν Hosted:

     
    Όπως μπορείτε να δείτε υπάρχει ένα καινούργιο CN container το ConfigurationUnits.
    Η εγκατάσταση μας έχει ολοκληρωθεί και έχουμε τον 1ο μας Hub Transport Server:

     

    Επόμενος στην σειρά είναι ο CAS και ο Mailbox server. Αυτοί οι 2 servers-ρόλοι έχουν κάποια προαπαιτούμενα hotfixes τα οποία έχουν ενσωματωθεί στο Windows 2008 R2 Server Service Pack 1. ( Ακόμα δεν το έχετε βάλει??? ) :
    KB982867 http://code.msdn.microsoft.com/KB982867
    KB979744 http://code.msdn.microsoft.com/KB979744
    KB983440 http://code.msdn.microsoft.com/KB983440
    KB977020 http://code.msdn.microsoft.com/KB977020
    Ξεκινάμε λοιπόν το installation των ρόλων από command line:
    setup.com /mode:install role:CA,MB,MT/organizationName:HostedExchange /hosting

     

    Την ίδια διαδικασία επαναλαμβάνουμε για την εγκατάσταση και των υπολοίπων server του περιβάλλοντος μας.. Στο επόμενο post θα συνεχίσουμε με τις αρχικές ρυθμίσεις.
  4. i-away
    Πρώτο post για το 2011 και ξεκινάει με χαρούμενα νέα. Από ανέκαθεν υπήρχαν διάφοροι τρόποι με τους οποίους οι χρήστες του Exchange Server μπορούσαν να δούν τμήματα μόνο της Global Address List (GAL). Αυτή η δυνατότητα μας βοηθούσε στο να διατηρούμε ένα μπούσουλα ειδικά σε μεγάλα Exchange Organizations χωρίς να στερούνται δυνατοτήτων όπως Public Folders, Transport Rules ή High Availability.
    Ο τρόπος που γινόταν αυτό διαφοροποιούταν από έκδοση σε έκδοση του Exchange μέχρι τώρα όμως δεν υποστηριζόταν στον Exchange 2010.
    Αυτό όμως έρχεται να αλλάξει. Το Exchange Team δουλεύει ήδη στην απευθείας ενσωμάτωση Global Address Segmentation δυνατοτήτων που θα έχουμε την χαρά να έχουμε και μάλιστα με γραφικό περιβάλλον στο επερχόμενο Service Pack 2 στα τέλη του 2011 ( Περισσότερες πληροφορίες λίαν συντόμως! ).
    Αποτέλεσμα του παραπάνω είναι ότι δεν θα δημοσιευτεί το καθιερωμένο Configuring Virtual Organizations and Address List Segregation Whitepaper ενημερωμένο για τον Exchange Server 2010, όπως στον Exchange Server 2007.
    Επειδή το τοπίο θα παραμείνει σχετικά θολό και δεν θα αποκαλυφτούν πολλά μέχρι την έλευση του Service Pack 2 ένα sneak peak του scope πάνω στο οποίο θα κινηθούν ενσωματώνοντας την δυνατότητα αυτή στον Exchange Server είναι το εξής:
    Το GAL Segmentation δεν θα αντικαταστήσει την multi-tenant enabled version του Exchange 2010. Η δυνατοτότητα αυτή θα απευθύνεται κυρίως σε: Εταιρείες που θέλουν κατακερματισμό του address book τους για διάφορους λόγους. Δυνατότητα sharing resources μεταξύ των χρηστών. Έλεγχος του τι θα βλέπει ο χρήστης όταν ανοίγει το address book. Αυτό θα γίνει μέσω ενός "Address Book Policy" αντί για το μέχρι τώρα ACL based GAL Segmentation που χρησιμοποιούσαμε. Παρόλα αυτά δεν θα είναι το ίδιο όπως σε κατάσταση Hosting mode του Exchange 2010 SP1.
    Περισσότερες πληροφορίες Σύντομα!. Stay Tuned.
     
    Source: Microsoft Exchange Product Group.
  5. i-away
    Just now Exchange Product Group announced the availability of the long-awaited Exchange 2019!!!!.
    There are several new and exciting features in this release and its the first time that Microsoft recommends install into Server Core!!!.
    Here are some of the new features:
    1) Exchange Server can use up to 48 processor cores and 256GB of RAM.
    2) Dual storage read/write capabilities to Exchange Server 2019 using Solid State Drive (SSD) technology to provide a super-fast cache of key data for improving end user experience
    3) Windows 2019 Core support and recommended method of installation
    For a full release announcement you can visit this link


  6. i-away
    A common issue when migrating to a new exchange version is the exhaustion of the log space resulting migration failures. Of course you can not simply go and delete those files because this will lead to more problems than the original one.
    One migitation to this problem is to run a full backup in order to clear the files and release the space.The other way is to enable circular logging which can be done before you start the migration in order to prevent the problem from happening in the first place.
    The migration  procedure uses the Migration  arbitration mailbox  to store migration information and causes the transaction logs that fill up the disk.
    You can find the name of the used arbitration mailbox and its database by the following powershell command:
    “Get-Mailbox -Arbitration | ft Name,Database”
    You can move those mailboxes to another Database and enable there the circular logging with the following command:
    “Set-MailboxDatabase “DatabaseName” -CircularLoggingEnabled $true”

    Happy disk space free migrations!!!!!


  7. i-away
    Hello to all.
    Recently i stumbled in client request asking if there is a way  to centrally configure Signatures for the employees without the need of a 3rd party tool. Fortunately there is an easy way in Office 365 to do this. Here is how :
    1) First of All you need to create a Transport Rule in EAC and choose to Build a Custom Rule
    2) Then you need to define the disclaimer text to be included in the rule. The trick here that you can use HTML Tags therefore have fields that will be replace accordingly for the user account details.
    3) Your Done!!!
    Note:  Although it may seem easy there are some tricky points:
    1) You need time to manually write the Rule with the HTML tags and have the correct fileds in the users configured
    2) The most important problem is the Format support.  The resulting signature will look weird on some devices and the image will increase the size of the mail.
    If you dont have problem with that you just have found and easy way to centrally manage your signatures across the organization.
    Happy signing!!!


  8. i-away
    Microsoft Exchange Team has released the official Exchange 2019 preferred architecture (PA) document.
    The document is updated with the new features of Exchange 2019 including the brand-new MetaCache Database (MCDB) feature and the increase in physical cores and memory limits.
    As always the document is a must for every admin that wishes to proceed to Exchange 2019 .
    You can donwload the document here.
     
    Happy Reading!!!


  9. i-away
    One of the audit tasks that you may need to do while your operation on exchange server is how to find out by whom and when an Exchange Object was Created, Modified, or deleted mainly for troubleshooting purposes.

    You can easily do that using exchange management shell:
    Search-AdminAuditLog -ObjectIds “ObjectName” –StartDate  (date) –EndDate (date)

    Note: The ObjectIds parameter accepts a variety of objects, such as mailbox aliases, Send connector names, and so on. If you want to specify more than one object ID, separate each ID with a comma for a more fine-grained report.
    Happy Searching!!!


  10. i-away
    A Security Researcher named Dirk-jan Mollema has recently discovered a vulnerability that affects Exchange and described a way that this vulnerability can be exploited to allow an attacker to obtain escalated privileges.
    The attack relies on two key components to be successful.
    Firstly by using a man-in-the-middle attack method against an Exchange Server to perform an NTLM relay attack ( an attacker intercepting the authentication process). This in itself isn’t actually an real Exchange vulnerability and its caused by the NTLM over HTTP authentication method that Exchange Server uses.
    The second component of this vulnerability relates to the ability of an attacker to force Exchange to attempt to authenticate as the computer account. To do this, the attacker has the ability to use Exchange Web Services in order to force Exchange Server to make a new outbound HTTP call that uses NTLM to attempt to authenticate against an arbitrary URL using the EWS Push Subscription feature.
    Microsoft is actively working on a hotfix and is not recommending performing any actions until a hotfix is released.
    Stay tuned for Updated info!


  11. i-away
    Today Exchange Team announce the  quarterly servicing updates, cumulative and update rollups, for all supported versions of Exchange Server. There are some important changes.
    What changes in Exchange Web Services Push Notifications
    The update to EWS Push Notifications is considered a critical security update and customers should deploy the update as soon as they understand and accept any potential impact. The change in Push Notification authentication is a permanent change to the product and necessary to protect the security of an Exchange Server.
    As outlined in KB4490060 the fundamental change is the authentication between  EWS clients and Exchange server. This only affects Push notificationsan and leaves Pull and Streaming Notifications unaffected and its applicable to all EWS clients.
    Also a computer reset of Exchange server credentials is required in Active Directory as a best practice.
    Decreasing Exchange Rights in the Active Directory
    The Team has also made a change in the Active Directory rights granted to Exchange Servers  reducing the items that exchange is able to write security descriptors as outlined in  KB4490059.
    Removing Legacy Auth protocols from Exchange Servers
    In Exchange Server 2019 Cumulative Update 1, there is a new cmdlet that restrict legacy authentication protocols on a per protocol and user by user basis. This change came from Office365 which already has the same  functionality implemented.
    Downloads
    The KB articles are the following:
    Exchange Server 2019 Cumulative Update 1 (KB4471391) Exchange Server 2016 Cumulative Update 12 (KB4471392) Exchange Server 2013 Cumulative Update 22 (KB4345836) Exchange Server 2010 Service Pack 3 Update Rollup 26 (KB4487052)
    Happy Patching!!!!
     
     
     


  12. i-away
    Today Exchange Team announced the new and updated site for the Exchange Deployment Assistant – https://assistants.microsoft.com! . This is a expected move since all the assistants are moved under assistants.microsoft.com site, following the Microsoft move to  docs.microsoft.com . The new assistant focus solely on on-premises deployments. For online and hybrid scenarios, there are two different resources offering guidance: the EDA, and the Office 365 mail migration advisors.
    When you go to the new site, you’ll see two options:

    The first option, On-premises Exchange deployments, will go to the Deployment Assistant and all the on-premises deployment options we all know and love today with Exchange 2019 scenarios coming soon!
    The second option, Migrate Exchange to Office 365 will lead you to the Office 365 mail migration advisors. The Office 365 mail migration advisors offer the best solutions for helping you migrate your organization to Office 365 including staged and cut-over migrations and all flavors of hybrid migrations.
    The existing Deployment Assistant will remain available until the end of April 2019.
    Happy advising!!!!


  13. i-away
    Hello to all!!
    Today Exchange Product Group announced a long-expected addition on Office 365. The ability to migrate G-Suite calendars and contacts to Office 365 with nothing more than Office 365 native tools.
    Currently there is a 2GB migration limit per day. This is a great step forward but there are many more things to come. Migration currently does not support
    Mail: Vacation Settings or Automatic reply settings as well as Filters or Rules Meeting Rooms: Room bookings Calendar: Shared calendars, cloud attachments, Google Hangout links and event colors Contacts: A maximum of three email addresses per contact are migrated over Contacts: Gmail tags, contact URLs and custom tags are not migrated over You can read more information here

    Happy Migrations!!!


  14. i-away
    Όπως έχω πει και σε προηγούμενο post μου τα προβλήματα που συναντάμε κατά την διάρκεια migration ή replication public folders είναι πολλά και ποικίλα.Σε αυτό το post δεν θα δώσουμε λύσεις για κάθε πιθανό πρόβλημα. Απλά θα δώσουμε κάποιες γενικές οδηγίες για το πώς μπορούμε να εντοπίσουμε πιο γρήγορα το πρόβλημα.
    Ο καλύτερος σύμμαχος μας σε αυτή την προσπάθεια είναι το application log. Ανοίγοντας το Diagnostic Logging στο Replication Incoming / Replication Outgoing λαμβάνουμε διάφορες πληροφορίες με την μορφή διαφόρων Event IDs.
    Δυστυχώς όμως τα Event IDs αλλάζουν μεταξύ των εκδόσεων του Exchange ( πχ. Στον Exchange 5.5 το outbound backfill request εμφανίζεται ως 3014 ενώ στον Exchange 2000 και 2003 ως 3016). Το ίδιο ισχύει και για τους άλλους τύπους Event όπως το outgoing hierarchy,incoming hierarchy,Status requests και status messages,κλπ.
    Η λύση σε αυτό το πρόβλημα που δημιουργείται είναι να συνδυάσουμε το Event ID με την παράμετρο Type. Υπάρχουν μόνο 7 types:
    Hierarchy - 0x2
    Content - 0x4
    Backfill Request - 0x8
    Backfill Response - 0x80000002 (για hierarchy) ή 0x80000004 (για content)
    Status - 0x10
    Status Request - 0x20
    Ακόμα όμως κι έτσι πολλές φορές υπάρχει παραπλάνηση όπως για παράδειγμα το event ID 3093 που δείχνει ότι υπάρχει κάποιο error σε ένα property ( πράγμα που μπορεί να αγνοηθεί με ασφάλεια).
    Ας δούμε κάποιους τύπους replication:

    Hierarchy Replication

    To replication αυτό λαμβάνει χώρα όταν ένας folder δημιουργείται ή σβήνεται ε’ιτε συμβαίνει κάποια αλλαγή σε properties του public folder ( replica list, client permissions, description, administrative note, storage limits).
    Κάθε 15 λεπτά (by default), το store κάνει broadcast τις αλλαγές που έχουν συμβεί στο μεσοδιάστημα αυτό. Με ενεργοποιημένο το logging για μια αλλαγή στο hierarchy θα δούμε κάτι της μορφής:

    Event Type: Information
    Event Source: MSExchangeIS Public Store
    Event Category: Replication Outgoing Messages
    Event ID: 3018
    Description:
    An outgoing replication message was issued.

    Type: 0x2
    Message ID: <[email protected]>
    Database "First Storage Group\Public Folder Store (ITPRODEVEXCH1)"
    CN min: 1-72CF, CN max: 1-72D3
    RFIs: 1
    1) FID: 1-6994, PFID: 1-1, Offset: 28
    IPM_SUBTREE\NewFolder
    Προσέξτε το "Type: 0x2" που δηλώνει ότι πρόκειται για hierarchy replication message.
    Το hierarchy replication message στέλνεται από το πρώτο server απευθείας σε όλα τα άλλα public stores. Δεν υπάρχει κάποια έννοια τοπολογίας. Η αλλαγή πάει απευθείας σε όλους τους servers που έχουν ένα public store με το ίδιο hierarchy.
    Content Replication

    Το Content replication συμβαίνει όταν ένα message δημιουργείται,σβήνεται ή αλλάζουν τα properties του. Ο χρόνος στον οποίο γίνονται broadcast οι αλλαγές είναι και εδώ ο ίδιος. Ένα content replication message έχει Type 0x4 και όπως και το hierarchy replication δεν ακολουθεί κάποιο topology.Τα πιο πιθανά σενάρια λάθους λοιπόν όπως καταλαβαίνετε σε replication αφορούν είτε content είτε hierarchy replication.

    1. Ο server έστειλε replication message?

    Αυτό μπορεί να διαπιστωθεί με αρκετούς τρόπους: Στον ESM, με δεξί κλικ στους Public Folders και διαλέγοντας "Connect To" στο συγκεκριμένο store. Προσοχή στα Client Permissions δεν αλλάζουν από τον ESM. Προ Exchange 2003 Sp2, όταν αλλάζαμε Client Permissions από τον ESM αυτός θα προσπαθήσει να κάνει την αλλαγή στο store που έχει την replica παρόλο που τα permissions είναι property του folder στο hierarchy. Με το 2003 Sp2 αυτό διορθώθηκε και πλέον η αλλαγή γίνεται στο hierarchy. Εάν χρησιμοποιούμε Outlook μπορούμε να χρησιμοποιήσουμε το MFCMAPI για να δούμε το PR_REPLICA_SERVER property του folder.Αυτό σε συνδυασμό με την εμφάνιση ή μη type
    0x2 ή 0x4 στο default χρονικό όριο μας οδηγεί στο ασφαλές συμπέρασμα ότι το πρόβλημα είναι στο server που κάνουμε την αλλαγή. Αυτά αναλυτικά περιγράφονται στο KB272999. Ιδιαίτερης προσοχής χρήζει το 3079 event:

    Event ID: 3079
    Source: MSExchangeIS Public
    Type: Error
    Category: Replication Errors
    Description:
    Unexpected replication thread error 0x3f0.

    EcGetReplMsg
    EcReplStartup
    FReplAgent
    Αν το 3079 έχει και το "EcReplStartup" τότε ο replication agent δεν έτρεξε για κάποιο λόγο.
    Αν στο organization υπάρχει ακόμα Exchange 5.5 τότε ο Exchange 2000,2003 όταν στέλνει replication message πρέπει να έχει και το ptagACLData property (ταe 5.5-style permissions βασισμένα σε legacyExchangeDN) από το ptagNTSD property (το 2000-style permissions βασισμένο σε SID). Αυτό σημαίνει ότι κάθε SID πρέπει να γίνει legacyExchangeDN. Αυτό μπορεί να αποτύχει για πολλούς λόγους: Πχ. Αν το SID αντιστοιχεί σε περισσότερους από έναν χρήστες:

    Event ID: 9528
    Category: General
    Source: MSExchangeIS
    Type: Error
    Description:
    The SID S-1-5-21-408248388-469072634-37170099-1391 was found on 2 users in the DS, so the store cannot map this SID to a unique user.

    The users involved are:
    /DC=com/DC=company/CN=Users/CN=User1
    /DC=com/DC=company/CN=Users/CN=User2

    2. Ο παραλαμβάνων server πήρε το μήνυμα?
    Σε αυτή την περίπττωση την απάντηση θα μας την δώσει το message tracking και συγκεκριμένα το πεδίο To: αν το target store δεν υπάρχει εκεί τότε οι αλλαγές δεν έχουν πάει εκεί για κάποιο λόγο.


    3. Έφτασε το message στον destination server?
    Εφόσον έχουμε βεβαιωθεί ότι το μήνυμα έφυγε από τον server τότε πρέπει να δούμε γιατί δεν έφτασε ποτέ. Εκέι την λύση δίνουν τα incoming replication events που server-στόχου.

    Τα παραπάνω αποτελούν απλώς κάποιες γενικές οδηγίες – κατευθύνσεις για την επίλυση των πιο συχνών προβλημάτω που μπορεί να παρουσιαστούν.Τα πράγματα περιπλέκονται λόγω μη ύπαρξης topology στο replication αλλά με απλές ερωτήσεις σαν αυτές που παρέθεσα παραπάνω η λύση είναι πάντα θέμα χρόνου.
  15. i-away
    Επειδή τελευταία παρατήρησα ότι στο φόρυμ υπάρχουν πολλές απορίες για το Public Folder migration θα επιχειρήσω να δώσω κάποιες κατευνθύσεις.
     
    Τα περισσότερα error κατά την διαδικασία Migration από 2003 σε 2007 η 2010 οφείλονται στο property validation. Το validation αυτό εμφανίστηκε για πρώτη φορά στον Exchange 2007 και η λειτουργία του είναι να καθαρίζει τα καινούργια public folder store απο "χτυπημένα" objects ( contacts,appointments,κλπ). Για τις περισσότερες των περιπτώσεων αυτό το script δίνει την λύση. Εαν πάλι δεν δουλέψει υπάρχει και ο πιο χρονοβόρος τρόπος που περιγράφεται  εδώ.
    Το κακό με την λειτουργία του validation είναι ότι κάποιες φορές μαρκάρει ως χτυπημένα και κανονικά objects. Δυστυχώς κανένας απο τους 2 παραπάνω τρόπους δεν δίνει οριστική λύση στο πρόβλημα και κάποιες φορές κάποια πράγματα θα πρέπει αναγακστικά να διαγραφούν. Στον Exchange 2007 δεν υπάρχει κάποιος τρόπος να απενεργοποιήσουμε το validation . Στον Exchange 2010 SP1 αυτή η λειτουργία απενεργοποιείται αυτόματα εξαλείφοντας όλα τα προβλήματα που δημιουργούσε μέχρι στιγμής. ( Ακόμα ένας λόγος να αναβαθμίσετε σε 2010 SP1) . Βέβαια αυτό σημαίνει ότι δεν γίνεται έλεγχος και τα items μεταφέρονται όπως είναι . Μπορούμε αν θέλουμε να χρησιμοποιήσουμε το Script για τον έλεγχο και τον καθαρισμό της καινούργιας βάσης.
    Για να μην μείνουν οι χρήστες του 2007 παραπονεμένοι ένα παρόμοιο fix βρίσκεται ήδη σε διαδικασία και πιθανώς θα ενσωματωθεί σε κάποιο Update Rollup.
    Επίσης προτείνεται πριν απο κάθε μετακίνηση βάσης να γίνεται απαραιτήτως Defrag για εξοικονόμηση χώρου αλλά και χρόνου.( Τα 2 GB γίνονται εύκολα 150 mb ) [].
     
     
    Σε επόμενο post θα αναφερθούμε αναλυτικά στα πιο συχνά παρατηρούμενα προβλήματα που παρατηρούνται κατά την διαδικασία του Migration και στους τρόπους επίλυσης τους.
     

     
  16. i-away
    Πριν απο λίγο η Microsoft ενημέρωσε την σελίδα του Exchange 2010 Services/client content σε όλες τις γλώσσες συμπεριλαμβανομένου και της Ελληνικής. Οι οδηγίες αφορούν όλες τις πλατφόρμες τις Microsoft ( Οffice 365 Beta for small businesses, Office 365 Beta for enterprises, Microsoft Friends and Family, Microsoft Exchange, Live@edu)
     
    Η ενημερωμένη σελίδα βρίσκεται στο Τechnet.
     
     
    Επίσης υπάρχει ήδη για όσους δεν το γνωρίζουν και το σχετικό Dashboard εδώ
     

     
     
    Καλό Διάβασμα!,

  17. i-away
    Ο Exchange 2010 έχει διάφορα " κρυμμένα " built-in εργαλεία με τα οποία μπορούμε να κάνουμε πολλά και θαυμαστά πράγματα. ( πχ. Get-MailboxDatabaseCopyStatus , Test-ReplicationHealth , CollectOverMetrics.ps1 - CollectReplicationMetrics.ps1 )
    Σήμερα θα δούμε ένα απο τα πιό χρήσιμα scripts το CheckDatabaseRedundancy.ps1. Όπως μπορείτε να καταλάβετε απο το όνομα του το συγκεκριμένο script παρακολουθεί την κατάσταση μιας replicated mailbox database ελέγχοντας εάν υπάρχουν 2 τουλάχιστον υγιή αντίγραφα. και μας ειδοποιεί σε αντίθετη περίπτωση.
    Το output που λαμβάνουμε έχει την μορφή:
    [PS] CheckDatabaseRedundancy.ps1 -MailboxDatabaseName "Mailbox Database TestDB01"

    DatabaseName : Mailbox Database TestDB01
    LastRedundancyCount : 0
    CurrentRedundancyCount : 2
    LastState : Unknown
    CurrentState : Green
    LastStateTransitionUtc : 14/11/2010 6:51:19 AM
    LastGreenTransitionUtc : 14/11/2010 6:51:19 AM
    LastRedTransitionUtc :
    LastGreenReportedUtc : 14/11/2010 6:51:19 AM
    LastRedReportedUtc :
    PreviousTotalRedDuration : 00:00:00
    TotalRedDuration : 00:00:00
    IsTransitioningState : True
    HasErrorsInHistory : False
    CurrentErrorMessages :
    ErrorHistory :
    Ένα απο τα πλεονεκτήματα του συγκεκριμένου scripts είναι ότι με την προσθήκη της MonitoringContext παραμέτρου μπορεί να χρησιμοποιηθεί από τον Microsoft System Center Operations Manager (SCOM). Σε monitoring mode το script εμφανίζει red και green alerts στο Application event log. Το κόκκινο (event ID 4113) alert εμφανίζεται όταν μια βάση είναι "red" για 20 ή παραπάνω λεπτά ενώ το πράσινο (event ID 4114) όταν η βάση είναι "green" για 10 συνεχόμενα λεπτά.
    Υπάρχουν κάποιες πρόσθετες παράμετροι που μπορούμε να ενσωματώσουμε στο script. Για παράδειγμα η ShowDetailedErrors που μας δίνει αναλυτικότερες πληροφορίες για τα error που προκύπτουν και η επίσης πολύ χρήσιμη SendSummaryMailTos που μας ενημερώνει μέσω email για οποιοδήποτε γεγονός.
    Το script προτείνεται να τρέχει σε τακτά χρονικά διαστήματα για λόγους ελέγχου.Η ρύθμιση γίνεται μέσω της TerminateAfterDurationSecs παραμέτρου με τιμές -1 και 0.
    CheckDatabaseRedundancy.ps1 -MonitoringContext -SleepDurationBetweenIterationsSecs:0 -TerminateAfterDurationSecs:1 -SuppressGreenEventForSecs:0 -ReportRedEventAfterDurationSecs:0 -ReportRedEventIntervalSecs:0 -ShowDetailedErrors

    Αυτό βέβαια σε περίπτωση που δεν έχουμε κάποια monitoring λύση ( SCOM ). Φυσικά μπορούμε να το ενσωματώσουμε ως scheduled task.
    schtasks /create /TN "Check Database Redundancy" /TR "Powershell.exe -NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; C:\Operations\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@(domain-name)' -SendSummaryMailTos:@('SMTPToAddress@(domain-name)') -ErrorAction:Continue" /RU SYSTEM /SC HOURLY
    Γιαυτούς που βαριούνται να γράφουν μπορούν να κατεβάσουν το XML αρχείο, και να το εισάγετε στον Task Scheduler. Όπως επίσης και το script από εδώ.

  18. i-away
    One of the improvements in Exchange 2019 is that that the client configuration became more easier. This is caused because of several improvements in Autodiscover.
    The clients that connect via EWS usually are connected to the EWS Endpoint using Autodiscover. It is known that Autodiscover provides also information for other protocol connections also and it support also multiforest configurations.
    When Exchange server is installed a virtual directory called Autodiscover  is created. After the appropriate URL are configured and stored in Active Directory the Client Access services that run on the Mailbox server provide authentication services and proxy services for both internal and external client connection.That results that Outlook clients can then connect to Exchange using only the user name and password.
    Autodiscover and Active Directory

    As said previously the creation of the Autodiscover virtual directory allows Outlook to automatically discover the necessary Exchange mailbox settings saving the users from having to write down and remember server names, ports, protocols, databases, etc. The user can simply provide a username and password and the rest is carried by Outlook.
    During the virtual directory creation an  SCP object is also created in Active Directory. That SCP object stores the authoritative URLs for the Autodiscover service and provides them to domain-joined computers. The SCP object points to the Exchange server and provides additional Autodiscover information to clients trying to connect to Exchange.
    The SCP object locates the Autodiscover server or endpoint that’s appropriate for the user trying to connect. It provides an easy way for domain-joined mail clients to look up Autodiscover servers.
    There are two types of SCP objects for the Autodiscover service that Exchange publishes. SCP pointers and SCP URLs.
    SCP pointers contain information that points to specific LDAP servers that are then used to locate Autodiscover SCP objects in the user’s Active Directory domain. SCP URLs contain Autodiscover URLs for Autodiscover endpoints.
    The Autodiscover service URL  will be either of the values below:
    https://yourdomain/autodiscover/autodiscover.xml https://autodiscover.yourdomain/autodiscover/autodiscover.xml The URL used will depend on whether the Autodiscover service is configured on a separate site or not.
    Autodiscover in DNS
    Exchange Server 2019 reduces the number of required namespaces since it does not require RPC Client Access namespaces. The Client Access services now proxy connection requests to whatever Mailbox server is hosting the active Mailbox database for the mailbox being connected to. A new feature in Exchange 2019 is the ability of a  a Mailbox server to proxy a session to another mailbox server in a different Active Directory site thus eliminating the need for  failback namespaces in DAG activation situations.
    Outlook and Autodiscover
    If Autodiscover is properly configured, Outlook clients can authenticate to Active Directory with just a user’s credentials. It will automatically search for the Autodiscover SCP objects for the domain. Once it finds the Autodiscover service, the Outlook client will connect to the Client Access services on the first Mailbox server it finds. Outlook will then collect profile information in XML format. This information is required to connect to the mailbox.
    Autodiscover can use one of four methods to configure an Outlook client:
    Connect to https://yourdomain/AutoDiscover/AutoDiscover.xml Connect to: https://autodiscover.yourdomain/AutoDiscover/AutoDiscover.xml Autodiscover redirect URL: http://autodiscover.yourdomain/autodiscover/autodiscover.xml Search for DNS SRV record The first two methods above are typical for smaller organizations with a single SMTP namespace. The second two are typical in multiple-SMTP namespace scenarios.
    Outlook uses the Autodiscover service to locate a new connection point. Autodiscover returns the following information to the Outlook client:
    User display name Internal and external connection settings Mailbox server hosting the active copy of the user’s mailbox URLs for various Outlook features (OAB, OWA, etc.) Outlook Anywhere server settings If the Exchange information for a user changes, the Outlook client will use the Autodiscover service to automatically reconfigure the user’s profile. This commonly occurs when a mailbox is moved. When this happens, Outlook contacts the Autodiscover service and automatically updates the user’s profile with the new mailbox location so that it can connect.
    Autodiscover and certificates

    When Exchange is installed, the installation process creates a self-signed certificate that’s signed by the Exchange server itself. This certificate is automatically installed on the server. However it is recommended that you use public certificate from a trusted third party.
    You can use the Microsoft Remote Connectivity Analyzer tool to confirm that the Autodiscover service in Exchange 2019 is accessible and functioning as expected. To test Autodiscover with the tool, launch the tool and select the Outlook Connectivity test. The tool will then attempt to connect to Exchange, using Autodiscover. If it fails, there is likely an issue with the external URLs configured in Exchange. Reading the results provided by the tool should reveal clues regarding why connectivity failed.


  19. i-away
    Παίρνοντας αφορμή απο πρόσφατο post συναδέρφου θα δώσω κι εγώ με την σειρά μου την δικιά μου οπτική και άποψη για το σύννεφο.
    Με την εξάπλωση του Cloud Computing ολοένα και περισσότερες εταιρείες μετακινούν τις υποδομές τους στο σύννεφο επωφελούμενες από τα οφέλη που τους παρέχει.
    Microsoft Business Productivity Online Suite
    Το μοντέλο που προσφέρει η Microsoft είναι το εξής απλό: Για κάποιο αντίτιμο η Microsoft προσφέρει σε κάθε χρήστη της εταιρείας e-mail, instant messaging, presence, Web conferencing και πρόσβαση σε intranet portal για collaboration. Απο την πλευρά της εταιρείας δεν υπάρχει ανάγκη για server software, hardware, storage ή maintenance costs. Η σουίτα του BPOS περιλαμβάνει Exchange Online (e-mail), SharePoint Online (intranet/Web portal), LiveMeeting (Web conferencing) και Office Communications Online (instant messaging/presence).
    Υπάρχουν δύο εκδόσεις BPOS: Standard και Dedicated. Η κύρια διαφορά τους είναι ότι στην Standard έκδοση πολλές εταιρείες μοιράζονται τα resources του ίδιου server στην Dedicated έκδοση κάθε εταιρεία έχει τον δικό της server. Να σημειώσουμε εδώ ότι η Exchange Online Dedicated υπηρεσία προσφέρεται μόνο σε εταιρείες μεγαλύτερες των 5,000 users.
    Εκτός του προαναφερομένουν υπάρχουν και άλλες διαφορές μεταξύ των δύο εκδόσεων όπως για παράδειγμα η αδυναμία deploy custom Web parts στην BPOS Standard SharePoint Online σουίτα ή η δυνατότητα search μεταξύ πολλών site collections στο Sharepoint,κλπ.
    Migrating στον Exchange Online
    Η μετάβαση ενός παραδοσιακού Microsoft Exchange απο τοπική υλοποίηση στον σύννεφο είναι κάτι που αν και με αρκετά προβλήματα και παγίδες ακόμα είναι μια διαδικασία που ολοκληρώνεται εύκολα και γρήγορα.
    Για την μετάβαση αυτή προσφέρονται 2 τρόποι: Η χρήση του native BPOS toolset ή η χρήση του migration tool για απευθείας σύνδεση του Exchange Online απο μία πλατφόρμα messaging τύπου Lotus Notes/Domino ή Novell GroupWise.
    On-premises to Exchange Online (Σε 2 βήματα) – Μέχρι πρόσφατα ο μόνος δρόμος για να ανεβάσουμε ένα μη-Microsoft σύστημα στο σύννεφο ( Lotus Notes/Domino,Novell GroupWise ) ήταν το on-site migration σε ένα νέο Exchange περιβάλλον και μετέπειτα στο Online περιβάλλον.
    Direct to Exchange Online (1 βήμα) – 3rd-party migration προιόντα έχουν κάνει δυνατή την απευθείας μετακίνηση απο μη-Microsoft σύστηματα σε Exchange Online με μία κίνηση κάνοντας όλα τα βήματα μαζεμένα.
    Σημεία προσοχής στα Exchange Migrations
    Directory Synchronization – Με το Microsoft Online Services Directory Synchronization Tool οι χρήστες ενός on-premises Active Directory (AD) μπορούν να συγχρονιστούν με το hosted Active Directory σε οποιοδήποτε στάδιο του migration.
    Content Migration – Στα on-premises migrations χρειάζεται προσοχή στο είδος των δεδομένων που θα μεταφερθεί μεταξύ των mail servers καθώς αυτά θα μεταφερθούν στην online πλατφόρμα μέσω του Internet.
    Mailboxes – Επειδή η μεταφορά γίνεται μέσω του Internet είναι σκόπιμο να μεταφέρονται μόνο τα απαραίτητα mail data. Εδώ προτείνεται η χρήση του archive για λόγους ταχύτητας και μείωση του όγκου δεδομένων.
    Resources – Σε περίπτωση που υπάρχουν “generic mailboxes” αυτά θα πρέπει να δημιουργηθούν στο onlime Active Directory πριν κάνουμε την διαδικασία του συγχρονισμού.
    SharePoint Online
    Η υπηρεσία του SharePoint Online προσφέρει τα ίδια ακριβώς πράγματα με τον Microsoft Office SharePoint 2007 (MOSS), χωρίς το επιπλέον “μπελά” της διαχείρησης – παραμετροποίησης της SharePoint farm. Είναι πλήρως λειτουργικό σε λίγα λεπτά εν αντιθέσει με της ακόμη και εβδομάδες που πολλές φορές χρειάζεται για να έχουμε ένα πλήρως λειτουργικό SharePoint και φυσικά μειώνει κατακόρυφα το κόστος της επένδυσης αυξάνωντας κατά πολύ το ROI.
    Το SharePoint Online διατίθεται σε 2 εκδόσεις και αυτό: Standard και Dedicated.Η standard έκδοση ( προτείνεται μέχρι 5,000 χρήστες ) παρέχει πλήρη πρόσβαση στο εκάστοτε SharePoint site collection αλλά όχι στο central administration ούτε και στο shared service provider. Η πλήρης πρόβαση – λειτουργικότητα προσφέρεται στο SharePoint Online Dedicated επίπεδο το οποίο δίνει πλήρη πρόσβαση σε όλα τα στοιχεία και τις λειτουργίες του Sharepoint ( personalization services, advanced search, Excel Web Services,Business Data Catalog).
    Challenges of Migrating to SharePoint Online
    Σε αντίθεση με το Exchange Online Migration η μετάβαση στο SharePoint Online, εστιάζεται σε 3 τομείς:security, user interface και functionality.
    Security: Ιδιαίτερη προσοχή χρειάζεται κατά την μεταφορά sharepoint contect από την on-premises στην off-premises κατάσταση εξαιτίας διαφορών στην δομή που μπορεί να υπάρξουν με αποτέλεσμα να δημιουργηθεί πρόβλημα με τα user permissions. Προτείνεται η ακριβής μεταφορά της δομής από την μία κατάσταση στην άλλη . Το πρόβλημα είναι εντονότερο σε περίπτωση που δεν έχουμε Sharepoint τοπικά αλλά κάποια 3rd party λύση.
    User interface: Εδώ δεν υπάρχει ιδιαίτερο πρόβλημα και το μόνο θέμα είναι σε μετάβαση από διαφορετική πλατφόρμα λόγω αλλαγής του "look and feel".
    Functionality: Επειδή το Sharepoint ουσιαστικά δεν είναι ένας απλός fileserver αλλά πολλά πολλά περισσότερα, οι δυνατότητες του είναι τεράστιες. Workflows,Document Libraries,IRM,κλπ ο μόνος περιορισμός είναι το τι θέλει να κάνει ο administrator και φυσικά επιφέρουν και το ανάλογο challenge υλοποίησης από μία “χαώδη” κατάσταση σε κάτι πολύ πιο λειτουργικό και αποδοτικό.
     
    Παρόλο τα προβλήματα που μπορεί να έχουμε και να αντιμετωπίσουμε κατά την μετάβαση , το σύννεφο είναι εδώ και θα μείνει . Το Microsoft’s Business Productivity Online Suite παρέχει ένα πλήρες σετ εργαλείων για την διαχείρηση και λειτουργία ( μέχρι ενός σημείου ακόμα ) όλως των IT operations απο το σύννεφο .
  20. i-away
    Πολλές φορές λαμβάνουμε στο mailbox μας μηνύματα που έχουν αποστολέα όχι συγκεκριμένο άτομο αλλά μια πιο γενική διεύθυνση του τύπου [email protected]. Η διεύθυνση αυτή αποτελεί συνήθως μια γενική διεύθυνση ενός τμήματος ( μάρκετινγκ συνήθως ). Παρόλα αυτά όλοι αυτοί που βρίσκονται στα συγκεκριμένα τμήματα έχουν την δική τους διεύθυνση και στέλνουν - λαμβάνουν από αυτήν.
    Το παραπάνω “τρυκ” ονομάζεται Address rewriting και δημιουργήθηκε απο την Microsoft για αυτόν ακριβώς τον λόγο. Η τακτική αυτή βρίσκει πολλές εφαρμογές τόσο σε εξερχόμενα email ( πχ. μαρκετινγκ) όσο και σε εσωτερικά email ( σε περιπτώσεις merge εταιρειών ). Εδώ να σημειώσουμε ότι για να δουλέψει το address rewriting πρέπει να ενεργοποιηθεί και στα εισερχόμενα αλλά και στα εξερχόμενα email έτσι ώστε να υπάρχει σωστή αντιστοίχηση τους.

    Βέβαια χρειάζεται προσοχή γιατί το Address rewriting δεν αλλάζει μηνύματα που είναι attached στο προς rewrite μήνυμα, όπως και τα SMTP Return-Path, Received, Message-ID, X-MSTNEF-
    Correlator, Content-Type Boundary=string headers και τους headers εντός των MIME body parts. Τα Message-ID, X-MS-TNEF-Correlator, Content-Type Boundary=string
    headers, και οι headers εντός των MIME body parts χρησιμοποιούνται για την ασφάλεια και την κρυπτογράφηση των email με τεχνολογίες όπως η Microsoft Rights Management γιαυτό και δεν μπορούν να μεταβληθούν καθώς η μεταβολή τους αλλάζει το authenticity του email.
    Για την διασφάλιση της σωστής αντιστοίχησης και δρομολόγησης πρέπει να έχουμε υπόψην μας κάποια πράγματα:
    Καταρχήν το αποτέλεσμα της αντιστοίχησης θα πρέπει να είναι μοναδικό για να μην δημιουργηθεί όπως είναι λογικό conflict.
    Συνέπεια του παραπάνω είναι ότι πρέπει να ενεργοποιηθει το address rewriting και στους 2 connectors όπως έχουμε αναφέρει παραπάνω.

    Κάτι άλλο εξίσου σημαντικό είναι ότι δεν μπορούμε να χρησιμοποιήσουμε εκτεταμένα wildcards παρά μόνο σε εσωτερικά domains, για παράδειγμα τα kladakis*@finance.autoexec.gr ή blackman@sales*.autoexec.gr δεν υποστηρίζονται ενώ το spanougakis@*.autoexec.gr υποστηρίζεται. Χρήσιμο για παράδειγμα θα ήταν το rewriting των *@development.autoexec.gr και *@software.autoexec.gr σε *@support.autoexec.gr.

    Δυστυχώς το Address rewriting configur-άρεται μόνο μέσω Exchange Management Shell. Ακόμα δεν υπάρχουν επιλογές στην Exchange Management Console ( stay tuned… ).Υπάρχουν 4 ειδών εντολές :
    Get-AddressRewriteEntry
    New-AddressRewriteEntry
    Set-AddressRewriteEntry
    Remove-AddressRewriteEntry.
    Από τα προθέματα τους είναι προφανής η χρήση τους. Για παράδειγμα:
    New-AddressRewriteEntry -Name “Two-way Rewrite entry for autoexec.gr”
    -InternalAddress autoexecint.gr -ExternalAddress autoexecext.gr

    Η εκτεταμένη χρήση του Address Rewriting ενδείκνυται σε μεγάλα περιβάλλοντα με πολλά υπο-τμήματα και όχι μόνο . Θεωρείται πιο “επαγγελματικό” το [email protected] παρά το [email protected]
    Σημείωση: Μετά απο διαδηλώσεις-διαμαρτυρίες-πολιορκίες εξαγριωμένων administrator στα Headquarters του Exchange Product Group εδόθη η υπόσχεση ότι το θέμα με την EMC θα διορθωθεί σύντομα .. Εν αναμονή λοιπόν..
  21. i-away
    Μετά απο πολύ καιρό και το αίσιο τέλος μιας μεγάλης αλλαγής σε πέλατη (
    migration στο migration ) αποφάσισα να γράψω τις εμπειρίες μου για ένα
    πρωτόγνωρο πράγμα για εμένα. Την συνύπαρξη του Exchange με τα Μαύρα Μούρα. Είχα
    ακούσει απο συναδέρφους εμπειρίες και απόψεις , είχα δει video αλλά επί της
    πράξης ανακάλυψα πολλά μυστικά και κολπάκια.

    Πολλές εταιρείες καταφεύγουν στα λεγόμενα “consumer BlackBerrys “ καθώς είναι
    εύκολο να συνδεθούν στην  cloud-based BlackBerry Internet
    Service και σε έναν  IMAP4 ή POP3-capable mail server. Με την ύπαρξη
    ενός Exchange server μπορούν  να συνδεθολυν  ακόμα και σε μία
    Outlook Web Access σελίδα.Τα  “consumer BlackBerrys “ είναι
    τέλεια για απλούς χρήστες ή για μικρού μεγέθους mailboxes, αλλά ζορίζονται όταν
    υπάρχουν πολύπλοκα mailboxes με πολλούς φακέλους.Επίσης  οι
    χρήστες πρέπει να συγχρονίζουν τα  calendar και τα contacts τους χειροκίνητα
    μέσου του  BlackBerry Desktop Software. Επίσης η υπηρεσία έχει 
    SLAs απλού χρήστη και όχι επαγγελματία, με τα όποια μειονεκτήματα αναδεικνύει
    αυτό.

    Για τις πιο επαγγελματικές περιπτώσεις χρησιμοποιείται ο BlackBerry
    Enterprise Server.Η δουλειά του είναι να συνδέει το δικτύο μας με το
    δίκτυο της RIM περνώντας mail απευθείας απο τον Exchange ή
    Notes ή GroupWise server απευθείας στο BlackBerry.
    Για την ιστορία η RIM ήταν απο τις πρώτες εταιρείες που χρησιμοποίησαν το
    λεγόμενο  push email.

    Όλα αυτά θα ήταν τέλεια αν και η εγκατάσταση του BES ήταν εύκολη …. Δυστυχώς
    όμως απαιτείται η αλληλεπίδραση του με το Windows network σε βαθύ επίπεδο. Δεν
    μιλάμε για μια απλή εγκατάσταση software αλλά για δημιουργία users που έχουν
    administrator-level access στον email server μας. Απο αυτό καταλαβαίνετε την
    σοβαρότητα και την προσοχή που απαιτείται κατά την εγκατάσταση και την
    παραμετροποίηση του.

    Στις απαιτήσεις της εγκατάστασης προτείνεται dedicated server . Το ευτύχημα
    είναι ότι ένας low-end Xeon ή ένας AMD Athlon server με  2 GB  RAM είναι αρκετός.
    Προσοχή χρειάζεται  διότι δεν γίνεται εγκάτάσταση σε  Windows Server
    2008, οπότε η λύση του Windows Server 2003 R2 είναι
    μονόδρομος. Παρόλα αυτά υπάρχει υποστήριξη  64-bit οπότε στο μέλλον θα δούμε εγκαταστάσεις και σε Windows server 2008 R2.

    Το παρακάτω γρήγορο tutorial αφορά Exchange Server 2007 SP1
    σε  64-bit εγκατάσταση Windows Server 2003 R2, σε δίκτυο με
    Windows Server 2008 domain controller. Η διαδικασία είναι
    παρόμοια και για τον Exchange Server 2003 με μόνη διαφορά την
    δημιουργία του  BESAdmin λόγω της διαφορετικής αλληλεπίδρασης του Exchange
    Server 2007 με το Active Directory.


    Τον  BES μπορούμε να το κατεβάσουμε είτε απευθείας απο την RIM είτε να τον προμηθετούμε σε
    CD. Επίσης χρειαόμαστε εκτός απο  CALs για τους χρήστες και product keys.



     


    Ξεκινώντας απο τον Exchange server το πρώτο βήμα είναι να δημιουργήσουμε ένα
    mailbox account για τον BESAdmin account. Αυτό μπορεί να γίνει απο την Exchange
    Management Console. Προσοχή στο password, γιατί θα μας χρειαστεί αργότερα.

    Τώρα αυτό το account πρέπει να γίνει Exchange administrator με  view only
    rights.

    Στο αγαπητό μας Exchange Management Shell λοιπόν:

     
    add-exchangeadministrator “BESAdmin” –role ViewOnlyAdmin


     


    Και για επιβεβαίωση:

     
    get-exchangeadministrator | Format-List



      


    “Real man do it CLI “ Blackman σου θυμίζει τίποτα? ( χεχεχ )

     
    get-mailboxserver <mailserver> | add-adpermission –user
    “BESAdmin” –accessrights ExtendedRight –extendedrights Send-As, Receive-As,
    ms-Exch-Store-Admin


    Έλέγχουμε με :
    get-mailboxserver <mailserver> |
    get-ADpermission -user BESAdmin | Format-List


    Πάμε τώρα στον server που θα φιλοξενήσει τον BES.
    Μπαίνουμε ως domain administrator και δίνουμε στον BESAdmin account local
    administration rights.Ο  BES πρέπει να εγκατασταθεί με την
    χρήση του service account που θα χρησιμοποιεί για να εξασφαλιστεί η σωστή και
    απρόσκοπτη λειτουργία των  components και των databases που εγκαθιστά .Μπαίνουμε λοιπόν με τον
    BESAdmin account και συνεχίζουμε.

      
     


    Μετά την επιλογή της τοποθεσίας εγκατάστασης, επιλεγούμε τους servers που θα
    συνδέετεαι ο BES . Με την επιλογή της άδειας επιλέγουμε και τον
    τύπο εγκατάστασης. Ο κάθε BES μπορεί να υποστηρίξει μέχρι 2,000
    users γιαυτό υπάρχει η επιλογή για multi-server scalable enterprise-grade
    system σε περιβάλλοντα άνω τοων 2000 χρηστών.

    Ο  BES μπορεί να εγκατασταθεί είτε ώς απλός  mail server είτε  για να συνεργάζεται με
    άλλα applications με την χρήση του MDS (BlackBerry Mobile Data System).
    Εάν χρησιμοποιούμε εργαλεία όπως ο  Microsoft’s Office
    Communications Server διατίθενται εργαλεία για την σύνδεση των
    BlackBerrys στην internal instant messaging and presence service.
    Μετά την
    αποδοχή αρκετών άδειων για τα components που χρησιμοποιεί ο BES ( συμπεριλαμβανομένου και του Apache
    Web server ) ξεκινάει η εγκατάσταση μετά τον έλεγχο και την
    εγκατάσταση των όποιων pre-requisites λείπουν.

    Τώρα ήρθε η σειρά των Microsoft’s Exchange Server MAPI
    Client και των Collaboration Data Objects. Αυτά διατίθενται ώς
    ξεχωριστό download που μπορούμε να κατεβάσουμε απο την Microsoft.

      
     


    Η υπόλοιπη διαδικάσία κυλά σχετικά ανώδυνα.


     


    Μετά τον απαραίτητο έλεγχο του  install summary για τυχόν λάθη και το
    απαραίτητο reboot , έρχεται η ώρα της εισαγωγής των keys του BES. Αυτά
    καθορίζουν πόσες  BlackBerry συσκευές θα συνδέονται στο δίκτυο της
    RIM.


     


    Με την εισαγωγή της πρώτης άδειας μπορούμε να κάνουμε και τον έλεγχο για το
    αν συνδεόμαστε σωστά στο δίκτυο της BlackBerry.Αν όλα πάνε καλά ήρθε η ώρα να
    προστεθούν οι  BES’s identifiers: Το SRP ID και το SRP
    authentication key. Αυτά τα προμηθευόμαστε είτε απο την ίδια την RIM είτε απο
    εκεί που πήραμε το Blackberry.Επίσης μπορούν να γίνουν download σε μορφή .SRP
    file. Αυτά πρέπει να γίνουν  πρώτα validate πρίν μπορέσουμε να προχωρήσουμε στο
    επόμενο βήμα.

    Ο BES με την ολοκλήρωση των παραπάνω βημάτων είναι έτοιμος να συνδεθεί στον
    Exchange server. Εάν έχουμε εγκαταστήσει τα Microsoft’s connection tools, θα
    δούμε ότι η διαδικασία είναι παρόμοια με την ρύθμιση ενός  Outlook account.

    Υπάρχουν εδώ και κάποιες έξτρα επιλογές όπως η χρήση των δεδομένων των
    BlackBerry πάνω από WLAN. Επίσης μπορεί να γίνει και
    ενεργοποίηση μέσω WLAN το λεγόμενο WLAN OTA activation. Μία
    πολύ χρήσιμη επιλογή εδώ είναι η δυνατότητα ρύθμισης password για την σύνδεση
    του BES και των built-in communication components όπως τον 
    MDS.


     


    Με κλίκ στο Finish έχουμε ολοκληρώσει την διαδικασία εγκατάστασης. Τώρα
    μπορούμε να βγούμε απο τον BESAdmin account και να κάνουμε log on με τον
    standard administrative account για να τρέξουμε τον BlackBerry
    Manager. Αυτόν θα τον χρησιμοποιήσουμε για να ενεργοποιήσουμε τις
    συσκευές και να προσθέσουμε χρήστες απο το Active Directory. Μπορούμε να κάνουμε
    provision τις συσκευές μας απευθείας μέσω USB connection στον BES server ή
    μπορούμε να τουσ στείλουμε απλά ένα email με το activation password. Οι χρήστες
    το μόνο που πρέπει να επιλέξουν είναι το built-in Enterprise Activation εργαλείο
    που υπάρχει στα  BlackBerrys τους , να εισάγουν το password και την email
    address τους για να ενεργοποιήσουν την συσκευή τους.


     


    Ο BES Manager παρέχει τα εργαλεία που μας επιτρέπουν να στείλουμε πολιτικές
    και ρυθμίσεις στις συσκευές . Αυτό γίνεται αν πάμε στο in the BlackBerry Domain
    view, ανοίξουμε το  Global Tab, επιλέξουμε  Edit Properties και μετά ανοίξουμε
    το IT Policy settings.

    Σύντομα θα ακολουθήσει ένα “ Deeper Dive “ post στον τρόπο λειτουργίας και
    διασύνδεσης.
  22. i-away
    Ας δούμε τώρα την διαδικασία του restore. Έχουμε 2 επιλογές είτε στην αρχική είτε στην εναλλακτική τοποθεσία.
    Για να ξεκινήσουμε το restore επιλέγουμε το “Recover” στο Action pane.

    Πατάμε “Next”.


    Επιλογή ημερομηνίας για restore και “Next”.

    Στην “Select recovery type” σελίδα, επιλέγουμε “Applications” και πατάμε “Next”.

    Στην “Select application” σελίδα επιλέγουμε τον Exchange και πατάμε στο “View Details”.
    Σε περίπτωση που κάνουμε restore το τελευταίο backup και δεν θέλουμε roll-forward recovery των databases, επιλέγουμε το παρακάτω:

    Στο “Details – Exchange” παράθυρο, βλέπουμε τα storage groups και τις databases που έχουν γίνει backup.

    Πατάμε “OK” και “Next”.
    Στο “Specify recovery options” επιλέγουμε το απευθείας restore στα production storage groups και databases ή το restore σε εναλλακτική τοποθεσία.

    Με κλίκ στο “Recover” ξεκινάει η διαδικασία.


    Κατά την διαδικασία οι databases γίνονται dismount και mount αυτόματα.

    Επίσης τα log files γίνονται restore.

  23. i-away
    Έχοντας τελειώσει με την προετοιμασία του AD και εφόσον έχουμε επαληθεύσει το replication-update μπορούμε να προσωρήσουμε στην εγκατάσταση του πρώτου Client Access - Hub Transport server Χρησιμοποιώντας την επιλογή Custom Exchange Server Installation επιλέγουμε την εγκατάσταση των Client Access - Hub Transport ρόλων.


    Κατά την εγκατάσταση του Hub Transport ρόλου σε Exchange 2007 server που συνυπάρχει σε Exchange 2003 υποδομή ο wizard μας ζητάει να του δώσουμε τον Exchange 2003 bridgehead server που θα χρησιμεύσει ώς connection point για τον νέο Routing Group Connector που διημιουργεί ο Exchange 2007.
     


    Στην περίπτωση μας η υποδομή είναι απλή έτσι μπορούμε να επιλέξουμε όποιον από τους back-end mailbox servers θέλουμε..
    Μετά την ολοκλήρωση του setup ελέγχουμε τα logs για πιθανά λάθη. Τα logs βρίσκονται στο C:\ExchangeSetupLogs.
    Παρόλο που τα CCR cluster nodes έχουν ήδη ετοιμαστεί στα Windows 2003 υπάρχει ακόμα αρκετό configuration που πρέπει να γίνει ειδικά όσον αφορά το network. Κάθε cluster node έχει 2 κάρτες δικτύου με την 2η να χρησιμεύει για την intra-cluster επικοινωνία και το heartbeat network. Για λόγους ευκολίας τις μετονομάζουμε σε Public και Private.Για το Private δίκτυο εφαρμόζουμε τις εξής αλλαγές:
    Δεν βάζουμε DNS Servers
    Αποεπιλέγουμε το Register this connection’w addresses in DNS
    Επιλέγουμε το Disable NetBIOS over TCP/IP
     

     
    Σημαντικό και προτεινόμενο είναι να έχουμε ενεργοποιημένο το Client for Microsoft Networks και File and Printer Sharing for Microsoft Networks για το Private network.Αυτό το κάνουμε και στα 2 δίκτυα για λόγους fault tolerance του Majority Node Set quorum.Επιβεβαβιώνουμε τις ρυθμίσεις μας πηγαίνοντας στο Network Connections του Control Panel και στο Advanced Menu επιλέγουμε το Advanced Settings.Η σειρά που πρέπει να έχουμε είναι Public , Private και Remote Access.
     

    Το επόμενο βήμα είναι η διημιουργία καθεαυτού του cluster.Αυτό μπορεί να γίνει είτε μέσω του Cluster Administrator είτε μέσω command line με την εντολή cluster.exe.Πρίν τρέξουμε τον cluster wizard διημιουργούμε ένα cluster service account στο domain
    Για λόγους οικονομίας χρόνου θα αναφέρω συνοπτικά τα βήματα
    Βάζουμε το όνομα του domain στο οποίο εγκαθιστούμε το cluster ακολουθούμενο απο το όνομα του cluster ( στην περίπτωση μας CLUSTER1 )
    Επιλέγουμε το πρώτο node που θα γίνει add στο cluster ( στην περίπτωση μας το NODE1 )
    Μετά το έλεγχο απο τον wizard του NODE1 εάν δεν υπάρχει κάποιο πρόβλημα μπορούμε να συνεχίσουμε με τα επόμενα βήματα.
    Επόμενη είναι η IP Address σελίδα στην οποία ρυθμίζουμε την IP Address του ίδιου του cluster.
    Στην Cluster Service Account οθόνη που εμφανίζεται αμέσως μετά βάζουμε το όνομα του service account που διημιουργήσαμε σε προηγούμενο σημείο.
    Η τελευταία οθόνη που εμφανίζεται είναι η Proposed Cluster Configuration η οποία μας δείχνει συνοπτικά όλες τις ρυθμίσεις μας.Εδώ όμως δεν πρέπει να ξεχάσουμε να ρυθμίσουμε το quorum resource .Πατώντας το Quorum button μας εμφανίζεται το Cluster Configuration Quorum παράθυρο στο οποίο πρέπει να βάλουμε ως επιλογή το Majority Node Set.
     

     
    Στο επόμενο post θα συνεχίσουμε με την εγκατάσταση και τις τελικές ρρυθμίσεις .
     
     
     
     
     
     
     
     
     
     
  24. i-away
    Στην τελευταία μου παρουσίαση στο event της Θεσσαλονίκης παρατήρησα ότι πολύ συνάδερφοι έχουν EXchange 2003 .Δεδομένου ότι με την έλευση του Exchange 2010 πολλοί θα μπουν στην διαδικασία να κάνουν το μεγάλο άλμα θα συναντήσουν ένα εμπόδιο. Δυστυχώς δεν υποστηρίζεται η μετάβαση απο τον 2003 στον 2010 αλλά μόνο απο τον 2007 και μάλιστα με Service Pack 2 σε Exchange 2010.Στην παρακάτω σειρά post θα δούμε βήμα προς βήμα πως μπορούμε να μεταβούμε εύκολα απο περιβάλλον 2003 σε περιβάλλον 2007. Η μετάβαση θα γίνει σε ένα περιβάλλον εργασίας που περιλαμβάνει 2 ξεχωριστούς Exchange 2003 σε ρόλο back-end servers και έναν Exchange 2003 σε ρόλο front-end server.Με την μετάβαση στον Exchange 2007 έρχεται και η μετάβαση σε Clustered Continuous Replication (CCR) περιβάλλον .Επίσης ένας Edge Transport server θα εγκατασταθεί σε αντικατάσταση ενός MailSweeper server και ο υπάρχον ISA Server θα χρησιμοποιηθεί για το publish των mobility λύσεων όπως Outlook Web Access (OWA) και Exchange ActiveSync (EAS) εξωτερικά.
    Με δεδομένο ότι το high availability είναι σχεδιασμένο για τον Mailbox server ρόλο αποφασίστηκε να επεκταθεί και στους Hub Transport και Client Access Server.Βέβαια το fault tolerance και το redundancy είναι ενσωματωμένα στον Hub Transport ρόλο έτσι αποφασίστηκε η εγκατάσταση 2 Hub Transport servers. Όμως δυστυχώς αυτό δεν ισχύει στην περίπτωση του Client Access Server ο οποίος μέχρι τώρα γινόταν highly available μόνο μέσω hardware ή software load balancing.Με δεδομένο ότι μόνο το OWA και το EAS χρησιμοποιούνται απομακρυσμένα και το γεγονός ότι βασίζονται και τα 2 στο Hypertext Transfer Protocol (HTTP) μπορούμε να χρησιμοποιήσουμε τον ISA Server για το Client Access Server load balancing. Επίσης για επιπλέον μείωση του κόστους οι Hub Transport και Client Access Server ρόλοι ενσωματώθηκαν σε ένα μηχάνημα και ένα δεύτερο μηχάνημα εγκαταστάθηκε για παροχή fault tolerance και redundancy.
    Επίσης εκμεταλευόμενοι τα καλά του virtualization, οι Hub Transport ,Client Access Servers, όπως και ο Edge Transport server,εγκαταστάθηκαν σε virtual servers. Τα 2 cluster nodes έγιναν με χρήση hardware. Για λόγους ευκολίας και οργάνωσης χρησιμοποιήθηκαν τα παρακάτω ονόματα :
    NODE1 and NODE2. Για τα cluster nodes. CLUSTER1. Το όνομα του cluster. EX2007. Το όνομα του Clustered Mailbox Server (CMS). HUBCAS1 , HUBCAS2. Τα ονόματα των 2 Hub Transport - Client Access Servers. EDGE1. Ο Edge Transport server. Τα μηχανήματα είχαν λειτουργικό Windows 2003 με όλα τα Service Packs και τα updates. Επίσης κρατήθηκε ομοιογένεια στο configuration των μηχανημάτων με ρυθμίσεις όπως:
    Page file. Ορίστηκε ώς το 1.5 x το ποσό της μνήμης. Τα SMTP και NNTP services δεν εγκαταστάθηκαν καθότι μπλοκάρουν την εγκατάσταση του Exchange 2007. Επιλύθηκαν τα θέματα με το Windows 2003 Scalable Networking pack Application event log .Το μέγεθος των application event log ορίστηκε σε 40MB, με ενεργοποιημένη την επιλογή overwrite events as needed configured. Οι πρώτοι servers που εγκαταστάθηκαν ήταν οι Hub Transport και Client Access Servers όποτε και προετοιμάστηκαν με τα παρακάτω:
    .NET Framework Windows PowerShell IIS World Wide Web Publishing Service RPC over HTTP Proxy service. Κατά το transitioning από Exchange 2003 σε Exchange 2007, οι Exchange 2007 servers πρέπει να εγκατασταθούν με την ακόλουθη σειρά:
    Client Access Server Hub Transport server Mailbox server Unified Messaging Server  
    Πριν ξεκινήσουμε την εγκατάσταση του πρώτου Exchange 2007 server πρέπει να προετοιμαστεί το Active Directory schema .
    Αυτό γίνεται με τις εντολές στον schema master :
    setup.com /PrepareLegacyExchangePermissions
    setup.com /PrepareSchema
    setup.com /PrepareAD
    setup.com /PrepareDomain
    Αφού εκτελεστούν επιτυχώς επιβεβαιώνουμε ότι το update-replication έχει γίνει επιτυχώς.
    Στο επόμενο μέρος θα συνεχίσουμε με τις επόμενες ενέργειες της εγκατάστασηις
  25. i-away
    Σε συνέχεια του προηγούμενου post για τον Exchange 2010 θα δούμε αναλυτικά το προαπαιτούμενο software που πρέπει να έχει ο υπολογιστής στον οποίο θα εγκαταστήσουμε τον Exchange μας.Ο υπολογιστής μας που θα δεχτεί όλους τους εσωτερικούς ρόλους του Exchange (CAS, HUB, Mailbox, UM) είναι ένας απλός member server σε ένα single forest που τρέχει Windows Server 2008.
    Ως γνωστόν πριν απο κάθε εγκατάσταση Exchange πρέπει να γίνει επέκταση του Active Directory schema, έτσι ώστε να δεχτεί τα νέα objects,attributes του Exchange. Εδώ θα μας είναι χρήσιμα το AD management tools.
    Τα AD MGMT tools (ADDS) μπορούν να εγκατασταθούν με την παρακάτω εντολή:
    ServerManagerCmd –i RSAT-ADDS
    Τώρα μπορούμε να εγκαταστήσουμε τα prerequisites που χρειάζεται ο Exchange
    Εγκαθιστούμε το .Net Framework 3.5 από : http://www.microsoft.com/downloads/details.aspx?FamilyId=333325FD-AE52-4E35-B531-508D977D32A6&displaylang=en
    Εγκαθιστούμε το WinRM 2.0 CTP3 από : Για να κατεβάσουμε το WinRM 2.0 CTP3 θα χρειαστούμε πρώτα ένα Microsoft Connect account και μετά το πακέτο είναι προσβάσιμο στο :
    https://connect.microsoft.com/WSMAN
    Σειρά του PowerShell V2 CTP3 http://www.microsoft.com/downloads/details.aspx?FamilyID=c913aeab-d7b4-4bb1-a958-ee6d7fe307bc&displaylang=en#filelist
    Ένα ακόμα update για την MMC http://www.microsoft.com/downloads/details.aspx?FamilyId=1A267131-0362-468C-AB62-28E8EB4ECAAD&displaylang=en
    Εxtensions για την ASP.NET AJX 1.0 http://www.microsoft.com/downloads/details.aspx?FamilyID=ca9d90fa-e8c9-42e3-aa19-08e2c027f5d6&displaylang=en
    Σειρά του Office System Converter http://www.microsoft.com/downloads/details.aspx?FamilyID=60c92a37-719c-4077-b5c6-cac34f4227cc&displaylang=en
    Για τους Hub Transport και UM Roles εγκαθιστούμε το update που αναφέρεται στο Microsoft KB article 950888 http://www.microsoft.com/downloads/details.aspx?FamilyID=6ab4c1d5-23bc-4d4a-a5c7-3845894cdd0f&DisplayLang=en
    Για τον Client Access Role εγκαθιστουμε το update απο το Microsoft KB article 958178 http://www.microsoft.com/downloads/details.aspx?FamilyID=6ab4c1d5-23bc-4d4a-a5c7-3845894cdd0f&DisplayLang=en
    Έχοντας εγκαταστήσει όλα τα παραπάνω επανερχόμαστε στην κύρια εγκατάσταση και με την βοήθεια της γραμμής εντολών :
    ServerManagerCmd -i Web-Server Web-ISAPI-Ext Web-Metabase Web-Lgcy-Mgmt-Console Web-Basic-Auth Web-Digest-Auth Web-Windows-Auth Web-Net-Ext Web-Dyn-Compression NET-HTTP-Activation RPC-over-HTTP-proxy
    Σε περίπτωση που θέλουμε να υλοποιήσουμε clusters προσθέτουμε και :
    ServerManagerCmd -i Failover-Clustering
    Για τον UM Role ειδικά
    ServerManagerCmd -i Desktop-Experience
    Με την εκτέλεση της παραπάνω εντολής έχουμε τελειώσει όλες τις προεργασίες που απαιτούνται και είμαστε έτοιμοι να προχωρήσουμε στην εγκατάσταση του Exchange.
    Ο παρακάτω πίνακας είναι μια συγκεντρωτική λίστα του τι χρειάζεται να εγκατασταθεί σε κάθε ρόλο

    Description
    Tools Only
    Mailbox
    UM
    Client Access
    Edge
    HT
    .NET Framework 3.5
    Yes
    Yes
    Yes
    Yes
    Yes
    Yes
    Power Shell 2.0
    Yes
    Yes
    Yes
    Yes
    Yes
    Yes
    Windows Remote Management
    Yes
    Yes
    Yes
    Yes
    Yes
    Yes
    KB951725
    Yes
    Yes
    Yes
    Yes
    Yes
    Yes
    MS Filter Pack
    Yes
    ServerManagerCmd -i Web-Server
    Yes
    Yes
    Yes
    Yes
    ServerManagerCmd -i Web-Metabase
    Yes
    Yes
    Yes
    Yes
    Yes
    ServerManagerCmd -i Web-Lgcy-Mgmt-Console
    Yes
    Yes
    Yes
    Yes
    Yes
    ServerManagerCmd -i Web-Basic-Auth
    Yes
    Yes
    Yes
    Yes
    ServerManagerCmd -i Web-Windows-Auth
    Yes
    Yes
    Yes
    Yes
    ServerManagerCmd -i Web-Net-Ext
    Yes
    Yes
    Yes
    Yes
    ServerManagerCmd -i Web-Digest-Auth
    Yes
    ServerManagerCmd -i Web-Dyn-Compression
    Yes
    ServerManagerCmd -i NET-HTTP-Activation
    Yes
    ServerManagerCmd -i Web-ISAPI-Ext
    Yes
    ServerManagerCmd -i RPC-over-HTTP-proxy
    Yes
    ServerManagerCmd -i Desktop-Experience
    Yes
    ServerManagerCmd -i ADLDS
    Yes
    ServerManagerCmd -i Failover-Clustering
    Yes
    ServerManagerCmd -i RSAT-ADDS
    Yes
    Yes
    Yes
    Yes
    Yes
    Στο 2ο μέρος θα δούμε της διαδικασία εγκατάστασης καθεαυτού του Exchange
     
     
     
     
     
     
     
     
×
×
  • Create New...