in

Exchange Exchange

Check the home page for details on our July/August contest!

Brendan Keane's Exchange Blog

July 2007 - Posts

  • Setting up a Windows Server cluster (MSCS) in VMware ESX

    MSCS clustering in VMware can provide many benefits for a lab or testing environment for the system admin on a budget.  These should only be used in a non production environment.  In order to be able to VMotion VMs that are clusterd you must use Raw Device Mapping (RDM). This post does not go into how to use RDM.

    Not everyone has the budget or resources to have a multi node cluster in their lab or for testing.  In this blog, I am going to discuss how to use VMware ESX to create the shared disks necessary for MSCS cluster.  When complete a two-node cluster will have been deployed, and will allow for further deployment of an Exchange 2007 SCC, SQL 2005, or a file cluster.  This demonstration uses VMware ESX 3.0.1; however these same steps work with 3.5.

    1. Open your SSH client of choice and log into the ESX Server.

    scc1

    2. Su to root

    scc2

    3. Change directory (cd) to the location where the disk will be created.  This has to be a VMFS volume. In the screen shot below vmfs001 is the VMFS volume that I created.  Your volume name may be different.  Typically VMFS volumes are created under /vmfs/volumes.

    scc3

    4. To keep the datastore clean, it makes sense to create a directory for the cluster's disks.  Use make directory (mkdir) to create the name of the directory that will contain the disks.  In the example below, I named the directory SCC1 because when I create my SCC cluster the cluster name will be SCC1.  This is not mandatory; it just provides a concise path to the data. 

    scc4

    5. Change directory to the new directory created in step 4.

    scc5

    6.  Use vmkfstools to create the vmdk file.  Disk format (-d) needs to be set to thick, the bus type (-a) is set to lislogic.  To create the virtual disk use the lower case  c (-c) and specify a size.  For example to create a 1GB vmdk, the parameter can be specified as 1G or 1000M.  The last parameter is the name of the vmdk.

    vmkfstools  -d thick -a lsilogic -c 1G /vmfs/volumes/vmfs001/SCC1Q.vmdk

    scc6

    7. Change the vmdk name and the file size, and use the same command above for the data, log and backup directories.

    vmkfstools  -d thick -a lsilogic -c 10G /vmfs/volumes/vmfs001/SCC1S.vmdk

    scc7

    vmkfstools  -d thick -a lsilogic -c 3G /vmfs/volumes/vmfs001/SCC1T.vmdk

    scc8

    8. Logout

    scc9

    Once the disks have been created it is time to present them to the guests.

    9. From Virtual Center Click on the server.

    10. In the summary tab, in the commands pane, click on Edit Settings.

    scc10

    11. On the hardware tab click Add.

    scc11

    12. In the Add Hardware Wizard, click Hard Disk and then click next.

    scc12

    13. In the Select a Disk windows, click the Use an existing virtual disk radio button and then click next.

    scc13

    14. From the Select Existing Disk window click the Browse button.

    scc14

    15. Click on the Datastore that contains the vmdk files and click open.

    scc15

    16. Select the folder that contains the vmdk files and click open.

    scc16

    17. Click on the first disk to present and click ok.

    scc17

    18. On the Advanced Options screen click the drop down box for Virtual Device Node. SCSI0 is the controller that contains the local disk on each server.  Do not assign shared disks SCSI 0:1-0:15.  For the first disk select SCSI (1:0) and click next.

    scc18

    19. Click Finish to present the disk.

    scc19

    20. Perform steps 11-19 for each disk to add to the cluster, using an unique SCSI Id for each disk.

    21. When the new hard disk is added to the guest on the new SCSI Controller is created. Click on the New SCSI Controller.  Set the SCSI Bus Sharing to Virtual and click ok.  This setting allows for the sharing of virtual disks between guest on the same physical server. (Note: for Windows 2000 Server clusters make sure that this SCSI controller is a Bus Logic type)

     scc20

    22. On the hardware tab click Add.

    Now that the shared disk is setup on the first server, it is time to add the second NIC for heartbeat communication to the server. 

    scc11

    23. Click Ethernet Adapter and click next.

    scc21

    24. If you have multiple network select the correct network from the drop down box and click next.  make sure that in Device Status, the Connect at power on checkbox is checked.

    scc22

    25. Click finish.

    scc23

    On the second virtual server perform the same steps listed above.  Remember to use the same SCSI addresses for the shared disks.

    When you power on the guest machines, if you receive an error that you can not power them on, verify that the thick option was used when creating the vmdk file.

    From here, the disks can be sector aligned, formatted and used to create a MSCS cluster and then go on to install Exchange SCC.

  • SysOp Tools: Password Reminder Pro

    Have you ever wondered how many users in your environment have password that are about to expire?  Wouldn’t it be nice if you could have an automated report sent to your inbox about user account activity?  Can you help reduce the number of calls to the help desk or remind users that they only have so many days to change their password?  Expiring password for road warriors, remote office and SOHO users is a problem that all IT organizations face.  SysOp Tools has released a product to help alleviate this problem.  Enter Password Reminder Pro.

    This tool is one of three from SysOp Tools and at this time is their oldest product.  Alpha’d in September 2006 this product has quickly moved through the beta testers and into production. 

    Setup

    Product setup could not be any simpler.  One of the best things I like about the setup requirements is that this program does not have to run on a server.  This is particularly useful in smaller environments where servers are not always plenty, and more administration type tools are run from the desktop.  In larger corporations, it may be necessary for this to run on server class hardware especially if help desk, LAN administrators, and security auditors use the reporting data.

    Listed below are the installation requirements:

    Installation and use of Password Reminder PRO requires the following:
    - Software can be run under Microsoft Windows 2000, XP, Server 2000 or Server 2003
    - Exported Reporting Console data requires Excel 2003 or later, or other xml-capable spreadsheet program
    - Microsoft Windows Active Directory 2000 or 2003 Domain Containing User Account Objects
    - Microsoft .NET Framework v1.1 and SP1 Must Be Installed Prior to Running Password Reminder PRO
    - Available internal SMTP Mail-Host Relay (We Recommend Microsoft Exchange)
    - Mail-enabled Domain User Accounts (AD User Account That Has a Functioning Email Address)
    - Established Domain User Account Password Expiration Policy at the Domain Root Level
    - Admin and Test Consoles Must be Run Under Context of Logged On User With At Least Read Access to AD and LDAP
    - Reminder Service Must be Run Under a Domain Service Account With Access to AD and LDAP
    - Valid Password Reminder PRO License Key for your specific Active Directory domain that hosts your user accounts
    - Microsoft IIS and SMTP services are NOT REQUIRED to run Password Reminder PRO!

    Installation is a breeze and only takes a few minutes and uses the standard InstallShield Wizard.  Once the install is complete, open the service control manager, look for the Password Reminder Pro service and open its properties.  According to the setup documentation, “Specify a domain account that has rights to read from your Domain Controllers’ AD and LDAP. If you are not sure, use an account that is part of the Domain Administrators AD group. Make sure the account has been granted domain rights to ‘Log on as a Service’”.  I would have to disagree with the above listed statement.  Unless the AD objects have had their read attributes restricted, any account should be able to provide the necessary service.  However as a best practice a service account should be created to perform this task.  It will need the right to log on as a service, but should be denied any other logon  attributes.  Post SetupNow that we have the software installed, we need to fire is up and see what it does.  There will be a Password Reminder Pro application shortcut on your desktop.  Double click that and the application will open. 

     

    This is the main screen for the application.  Do not be fooled be its simplistic nature.  The beauty of this is that it is simple and quick to configure.  The Admin Mailbox Address is the name, mail enabled distribution list, or to your mail enabled public folder.  The three sections for messages refer to the actual message that the end users will see.  The messages that you configure here are what will end up in every users’ inbox.  The default message is pretty simple and will work for some organizations.  The PW Expiration needs to be set to the password policy set in AD at the domain level.  If this value does not correspond to what is in AD, the reports and emails sent to users will be incorrect. 

     

    Licensing

    The software needs a unique license in order to run.  Each license key is tied to a specific domain.  Licensing is also tied to the number of users  objects that have expiring passwords in the domain. One of the report functions show how many licensed vs. unlicensed users.  There is also a standalone application that will tell you how many users are licensed.   Below are some questions I sent to my contact at SysOp.

    Q::How will this work in a multidomain environment?  If I have users in foo.bar and in more.foo.bar  and the product is installed in foo.bar, will it be able to send password reminders to the child domains?

    A:: Good questions- We have some of this covered in the online help guide: PRP works with the root domain password change policy set in AD for each domain or sub domain. Presently, PRP can only work with one root domain password change policy at a time since each domain and sub domain have their own root policies set, and the license key used in PRP is generated for and locked to the specific domain name or sub domain name.You would therefore need to install one instance of PRP in each domain or sub domain that contains user account objects that you would like to send expiring password reminders to, and have a valid license key for each domain / sub domain. As far as licensing goes, if you have your users spread between the root domain foo.com and a couple of sub domains (east.foo.com and west.foo.com), we would only need to know the number of password expiring user accounts for each domain / sub domain, and we would issue you 1 license key for each of these three LDAP domains. You could set the daily admin summary email for all thee instances of PRP to be delivered to the same admin mailbox. 

     

    Q:: If I have an empty root forest but have multiple populated child domains, do you install it (PRP) in the root, or in each child domain?  

     

    A:: PRP must be installed in the specific domain (foo.com) or sub domain (users.foo.com) that contains your user account objects. 

     

    Q:: Is there a way/plan for this to work with trusts?  I work in a managed service provider where some of the clients have a one way trust with us so we can manage their domains.  It would be easier for a MSP to have this installed in their AD and be able to point it to additional AD's as needed.  A:: Yes, this will work with Trusts- In this situation you would install PRP in the trusting / managed domain and set PRP in accordance with their domain root change password policy. I see your point from a MSP / ASP perspective with installing all instances of PRP in one AD and pointing individual password reminder instances to each managed domain and separate root domain's password change policy. At this point it is not possible to use PRP in this manner and will take some serious work to try and make this happen, due again to the individual nature of each domain's root policy settings. 

    Reports

    Everyone loves reports.  The reports that ship with the product are solid.  Within the application you can see Licensed Users, New/Unused Accounts, Expiring Passwords, Inactive Users, Unlicensed Users, Miscellaneous & Disabled accounts.  These reports can also be exported to Excel for additional manipulation. 

     

    The password application log is also sent to the administrator every day so the admin knows who is going to call them in the morning about expired passwords.  For a help desk manager or even the security administrator, the reporting functions help ease the administration of user accounts. 

      Email 

    Not all users are excited to change their passwords.  Most wait till the last day before the password expires.  More often than not, they will tell you that they just changed it, or that no one told them their password was going to expire.  Fear not.  Password Reminder Pro will email users to reminder them up to 3 times that their password is going to expire.  The body of the email is completely customizable so instructions on how to perform a password change, or the number to the help desk can be added in order to improve the end user experience.  Personally I think that this is a great feature.  Not everyone pays attention to when their password are going to expire, and road warriors typically do not want to spend the energy to remember such thing.

     

      

    Summary

    I think it is a good product that fills a particular niche.  The features that this application offers is valuable compared to the minimal amount of hardware, configuration and training that would need to be done.  Other products on the market that provide the same type of service are rolled into an enterprise wide compliance or monitoring solution and that is too much software for too little return.  I wouldn’t be surprised if Microsoft did not try to buy this or to come up with something similar and incorporate it into a R2 release or a Systems Center report pack.  If user management, auditing, or help desk are one of your areas of responsibility, you should definitely give this product a shot.

    A few notes from the Password Reminder PRO staff:

    • Scalability: Presently, Password Reminder PRO has the only reminder engine capable of sending safe (no false alerts or spam) and reliable expiring password reminders regardless of AD setup or mail system used, and can function reliably in directories of over 20,000+ password expiring AD user objects. 
    • Mail-friendly: Our reminder email engine is 100% RFC compliant, mail-server friendly and will not overload your mail server's queue with reminder emails.
    • Text or HTML: In addition, for organizations that do not support HTML email (Government, etc), our software has an advanced feature that allows you to send the expiration reminder emails in plain-text mime-type. And, the  text-mode reminder emails sent to users still retain their dynamic fields for user’s name and number of days remaining!  
    • Ease-of-use: Password Reminder PRO is a set-it-and-forget-it program that any admin regardless of technical expertise can operate and maintain. We've done all the heavy lifting for you. 
    • Cost: With all of the wonderful features and reliability built in to Password Reminder PRO, we've tried very hard to maintain a low price point and keep ROI very high. Most Enterprise Software suites run in the range of $6 - to $8 per user, plus a base software fee. The cost breakdown of Password Reminder PRO is a base software fee plus about $1 per user. We cap our licensing at 2500 users for a single domain, which further reduces the cost-per-user substantially for very large organizations.

    Learn more about SysOp Tool Password Reminder PRO at http://www.sysoptools.com/

     

© 2003-2008 NamedPipes Consulting. All other company and product names are property of their owners.
Powered by Community Server (Commercial Edition), by Telligent Systems