New Active Directory User and Office365 New User Powershell Procedure

As a systems administrator, quite often you’ll need to create new user accounts in Active Directory and MSOnline Office 365. It’s good to streamline your new user creation procedure as much as possible to make the process faster and more accurate. Thanks to PowerShell, we can turn a whole bunch of point and clicks into just a few PowerShell commands. In this example procedure we will first create an Active Directory AD user account with powershell and a .csv file and then add that user into multiple groups with a different powershell script and a .txt file that has a list of the groups. We will also use another powershell script to get the canonical name of the groups so that our script can find the LDAP location of the group in Active Directory. Secondly, because we do not run our own exchange server we will use powershell to connect to Office365, and create a new user there, license the user, and then add the user to some distribution groups. Prerequisites are powershell, and import AD components and MSOnline components.

 

  1. Go to https://gallery.technet.microsoft.com/scriptcenter/PowerShell-Create-Active-7e6a3978 and download the create_ad_users.zip and extract to c:\newusers\
  2. Edit create_ad_users.ps1 lines 92 and 98 to accommodate longer last names. In the original script it only allows for first initial and then a truncated last name of 4 characters. In my case, we have some users with long last names, so I set those values to 20:
  3. If($replace.length -lt 20)
    {
      $lastname = $replace
    }
    Else
    {
      $lastname = $replace.substring(0,20)
    }
    

     

  4. Copy info from your HR department about the new user into the .csv file c:\newusers\import_create_ad_users.csv
  5. Run PS C:\newusers> .\create_ad_users.ps1
  6. Next check the new username in ADUC for such things as account name, address, phone number etc. to ensure the entries are accurate.
  7. With our new user account created, most likely we will want to make that user a member of several security groups. To do that with PowerShell, we need to make sure that we have the correct LDAP names for our groups and place them into a file named groups.txt. In order to do so, we need to run another powershell script named find-dn.ps1 . The code is as follows:
    # Function Find Distinguished Name
    function find-dn { param([string]$adfindtype, [string]$cName)
        # Create A New ADSI Call
        $root = [ADSI]''
        # Create a New DirectorySearcher Object
        $searcher = new-object System.DirectoryServices.DirectorySearcher($root)
        # Set the filter to search for a specific CNAME
        $searcher.filter = "(&(objectClass=$adfindtype) (CN=$cName))"
        # Set results in $adfind variable
        $adfind = $searcher.findall()
        
        # If Search has Multiple Answers 
        if ($adfind.count -gt 1) {
            $count = 0 
            foreach($i in $adfind)
            {
                # Write Answers On Screen
                write-host $count ": " $i.path
                $count += 1
            }
            # Prompt User For Selection
            $selection = Read-Host "Please select item: "
            # Return the Selection
            return $adfind[$selection].path
        }
        # Return The Answer
        return $adfind[0].path
    }

    This code should be inserted into a new PowerShell ISE tab and then saved as find-dn.ps1 . Running the code will produce a new PowerShell function (but will not write any output to the screen.) Find the group names in ADUC that you want the CN name for, and then use the following command(s) to return the CN name:

    find-dn "group" "FinanceGroup"

    The script will return something similar to the following:

    LDAP://CN=FinanceGroup,CN=Users,DC=intranet,DC=contoso,DC=com

    Remove the part “LDAP://” and copy the remaining string into the c:\newusers\groups.txt file, which after finding the rest of your group CN names, should look something similar to the following:

    CN=FinanceGroup,CN=Users,DC=intranet,DC=contoso,DC=com
    CN=HRGroup,CN=Users,DC=intranet,DC=contoso,DC=com
    CN=OperationsGroup,CN=Users,DC=intranet,DC=contoso,DC=com
    CN=ITGroup,CN=Users,DC=intranet,DC=contoso,DC=com
    CN=AccountingGroup,CN=Users,DC=intranet,DC=contoso,DC=com
    CN=ComplianceGroup,CN=Users,DC=intranet,DC=contoso,DC=com
    CN=MarketingGroup,CN=Users,DC=intranet,DC=contoso,DC=com

     

  8. Now that we have our CN security group names, we can add the user(s) into the groups with the following script. For this step we can utilize the script found here: https://community.spiceworks.com/topic/459481-adding-users-to-multiple-security-groups-in-ad – which was contributed by Martin9700 . Copy the following script into a new PowerShell ISE tab and name the file Add-MultipleGroups.ps1 :
    #requires -Version 3.0
    Param (
        [Parameter(Mandatory,ValueFromPipeline)]
        [String[]]$Groups,
        [Parameter(Mandatory)]
        [String[]]$Users,
        [switch]$Passthru
    )
    
    Begin {
        Try { Import-Module ActiveDirectory -ErrorAction Stop }
        Catch { Write-Error "Unable to load Active Directory module, is RSAT installed?"; Exit }
        $Result = @()
    }
    
    Process {
        ForEach ($Group in $Groups)
        {   Try {
                Add-ADGroupMember $Group -Members $Users -ErrorAction Stop
                $Result += [PSCustomObject]@{
                    Group = $Group
                    AddMembers = $Users -join ", "
                }
            }
            Catch {
                Write-Error "Error adding members to $Group because $($Error[0])"
                $Result += [PSCustomObject]@{
                    Group = $Group
                    AddMembers = $Error[0]
                }
            }
        }
    }
    
    End {
        If ($Passthru)
        {   $Result
        }
    }

     

  9. Run the following command to add user to the appropriate security groups:
PS C:\newusers> .\Add-MultipleGroups.ps1 -Groups "CN=ITGroup,CN=Users,DC=intranet,DC=contoso,DC=com","CN=OperationsGroup,CN=Users,DC=intranet,DC=contoso,DC=com" -users user1, user2

With the above script you can use the file to run a number of different options as well such as:

You can just put the group names in -Groups:

.\Add-MultipleGroups.ps1 -Groups "testgroup1","testgroup2" -users user1,user2,user3,user4

You can use a text file (either in Groups or via pipeline):

.\Add-MultipleGroups.ps1 -Groups (Get-content c:\groups.txt) -users user1,user2,user3,user4

Get-content c:\groups.txt | .\Add-MultipleGroups.ps1 -Groups -users user1,user2,user3,user4

You can also use Get-Content for users, but you can pipe it:

Get-content c:\groups.txt | .\Add-MultipleGroups.ps1 -Groups -users (Get-content c:\users.txt)

 

You can confirm in ADUC that the users are now members of the security groups in our groups.txt file.

Add users to Office 365 and Distribution Groups with PowerShell

Great! Now that we have our user accounts created on the AD side of things, we will move on to adding our user(s) into Office365:

With PowerShell up and running will will issue the following commands:

From https://www.petri.com/use-powershell-create-assign-licenses-office-365-users

Import-Module MSOnline

Connect-MsolService

Now we will create the user with the following command:

New-MsolUser -UserPrincipalName user1@contoso.com -DisplayName ‘User 1’ -FirstName User -LastName 1

This command will return something like the following (sorry about the formatting:)

 

PS C:\Users\jcoltrin> New-MsolUser -UserPrincipalName user1@planmember.com -DisplayName ‘User 1’ -FirstName User -LastName 1



Password                                   UserPrincipalName                          DisplayName                                isLicensed

--------                                   -----------------                          -----------                                ----------

Suso4007                                   user1@contoso.com                       User 1                                False

 

Now we need to add a license to the user account. We need to do two things before we can assign the licenses. First is we need to to determine the different sku’s we have available to license, and second, we need to set the usage location. To accomplish the first part, we can issue the command:

Get-MsolAccountSku

Second, by using the instructions here: https://social.technet.microsoft.com/Forums/ie/en-US/bfde2a73-579c-409b-a7cd-77110048c7b7/license-enabling-script?forum=onlineservicesadministrationcenter

We can set the MS Online user’s principal location:

Set-MsolUser -UserPrincipalName user1@contoso.com -UsageLocation US


Set-MsolUserLicense -UserPrincipalName user1@contoso.com -AddLicenses Contoso:STANDARDPACK

Now that the user is licensed, we will add the account to a few Exchange Distribution Groups. We will need to import a new PSSession from outlook.com before we can run the Exchange commands. Import the session by first creating a function called “Connect-O365” by running the following (just like we created the function find-dn above):

function Connect-O365{
 $o365cred = Get-Credential username@domain.onmicrosoft.com
 $session365 = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://ps.outlook.com/powershell/" -Credential $o365cred -Authentication Basic -AllowRedirection 
 Import-Module (Import-PSSession $session365 -AllowClobber) -Global
}

Save and name this function: Connect-O365.ps1 and run it. We now have a function that we can run:

.\Connect-O365.ps1
Connect-O365

(enter creds)

Now we can add the distribution group members with the group identity and member name in quotes:

 

Add-DistributionGroupMember -Identity "Finance" -Member "user1@contoso.com"

Add-DistributionGroupMember -Identity "AllEmployees" -Member "user1@contoso.com"

A number of these scripts and commands can be combined into .ps1 files to optimize the workflow even further. With the information here you should have a good place to start. Let me know in the comments how you added your own features to the procedure.

 

Microsoft Bizspark – free business software for 3 years

If you’re thinking about which cloud service to use for a startup business, Microsoft just upped the ante with BizSpark.

Microsoft BizSpark https://www.microsoft.com/bizspark#start-two is really an amazing deal for business start-ups. If you wish you could get Microsoft software for free or for a huge discount check out their offer. BizSpark offers the following services and software for free for three years:

BizSpark gives startups 3 years of free stuff – software, services, tech support, and Azure cloud. Your startup qualifies if it is less than 5 years old, is privately held, and earns less than $1M annually. And at the end of your 3 years, you keep all the software you’ve downloaded – at no cost.

To expand on this service what you get with the Microsoft Bizspark details are the following:

Get up to $750 per month of FREE Azure cloud services for 3 years; that’s $150 per month each for up to 5 developers.

This potentially is a $27000 value!

Membership puts all Microsoft development and test software at your fingertips, including Azure, Windows, and Office 365 – for free. Plus, enjoy access to hundreds of free training classes, technical content, and 4 break-fix phone support incidents to help you on your journey.

It’s pretty amazing that BizSpark, in addition, also offers up to $120,000 worth of Azure credit.

Makes me want to go out and start a new business – hmm, maybe jasoncoltrin.com would qualify?

Exchange/Outlook 2010 autodiscover certificate error name mismatch

Exchange/Outlook 2010 autodiscover certificate error name mismatch

Recently some users have been receiving the following autodiscover certificate error when opening outlook:

Security Alert: autodiscover.domainname.org

Information you exchange with this site cannot be viewed or changed by others. However, there is a problem with the site’s security certificate.

√ The security certificate is from a trusted party

√ The security certificate date is valid

X The name on the security certificate is invalid or does not match the name of the site

Firstly, we host exchange at a different hostedexchange.com, and our autodiscover uses a wildcard certificate “*.hostedexchange.com”. So starting with the client I made sure to view the certificate. The correct name on the certificate listed was “*hostedexchange.com.”

1. I installed the certificate on to the client PC into the trusted store. Closed outlook/opened again and still the same error.

2. I looked at the proxy settings in the account setup and found that the ‘server name’ and msstd: were correct, they were.

3. We used nslookup externally and found that there are no valid dns records pointing to autodiscover.domainname.org

4. We used https://www.testexchangeconnectivity.com/ and found that while it does automatically check for autodiscover.domainname.org, dns did not return a value; it failed

5. From the client we were able to ping autodiscover.domainname.com, the ping returned an internal ip address of our mail server.

6. So from the results above it appears as though the client (or citrix server’s hosted desktop in this instance) had an incorrect dns entry.

7. From a (run as administrator) command prompt I issued an “ipconfig /flushdns” command on the client server but the error persisted, and pings still replied from autodiscover.domainname.org

8. We checked the hosts file on the server (c:\windows\system32\drivers\etc), and sure enough there was an old entry for autodiscover.domainname.org

9. In order to edit the hosts file, did a “Run as administrator” to open notepad, edited the file and saved successfully.

10. Issued another ipconfig /flushdns

Now when the client opens, the request to get autodiscover.domainname.org fails, and there is no mismatch of certificate names.

 

How to grant users access to other user’s mailboxes in Office365 using PowerShell

This procedure shows how to grant users access to other user’s mailboxes in Office365 using PowerShell
How to:
*Grant a user access to a single mailbox
*Revoke the above permissions (recommended cause of action after the Administrator has finished his/her tasks)

1. Fire up PowerShell (Run As Administrator).

First make sure you have the remote signed execution policy set to true. You can do this by running PowerShell in admin mode and running:
PS> Set-ExecutionPolicy RemoteSigned

2. Next, run the following to authenticate your self and import PowerShell commands to your local session:
PS> $LiveCred = Get-Credential
(Supply credentials for MSOnline Portal: admin@company.com/Password)

3. After supplying credentials to PowerShell as $LiveCred variable, authenticate and import PowerShell commands into your local session:
PS> $Session = New-PSSession -ConfigurationName Microsoft.Exchange-ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic –AllowRedirection

You’re In!
PS> Import-PSSession $Session

4. For example, to grant user@company.com full access to admin@company.com, you would enter the command:
PS> Add-MailboxPermission user@company.com -User admin@company.com -AccessRights FullAccess -InheritanceType All

PS> Exit
Have the user who was granted access close/reopen Outlook and the new mailbox will be listed in their Outlook Account Tree
5. If you want to hide the user mailbox from appearing in the mailbox tree in Outlook who you just granted access, you can add the switch -AutoMapping $false

1. To Revoke access you would enter the command:
PS> Remove-MailboxPermission user@company.com -User admin@company.com -AccessRights FullAccess -InheritanceType All
Jason Coltrin
MCSE 2003:Security, CSSA
Engineer Consultant, CIO Solutions

 

Exchange 2010 – Part 20 – A look at the Hub and Edge Transport Server Roles

The Hub and Edge Transport Server Roles

The purpose of this post is to explain the differences between the two transport role servers, the Hub Transport and the Edge Transport.

We will look at some of the key aspects of transport servers including:

  • Send/Receive Connectors
  • Anti-spam and Anti-virus protection
  • Transport Rules
  • Hub/Edge Synchronization

Take for example a scenario where your company has configured enough of it’s organization that they want to be able to send and receive email in full production. Because of this, we should discuss the configuration elements involved in our transport role servers. In our example, we have more than just a Hub Transport server, we also have an Edge Transport server that we installed but never configured to work with our Hub.

You’re never really completely done with Exchange, there’s always something left to do, to monitor etc.

So to start, in the Hub Transport server in the EMC, and click on Organization Configuration -> Hub Transport, we have several tabs:

Click Image to Enlarge

Send Connectors – Here you might not see any send connectors if none have been setup. Receive connectors are located under the Server Configuration-> Hub Transport. We don’t have any Anti-spam settings here yet in our Hub Transport role.

Edge Subscriptions – Here we will create a connection to our Edge Transport Server

Global Settings – we will go over this later

Email Address Policies – we will go over this later

Transport Rules – Here we can create transport rules, with conditions, actions, and exceptions – by default none.

Journal Rules – by default are blank

Remote Domains – we will go over this later

Accepted Domains – we will go over this later

 

If we remote into our “Edge” transport server, our EMC will be pretty much empty except for our Edge Transport settings. It’s one of the easiest server roles to work with because there is not much here to configure:

Click Image to Enlarge

The five tabs we have to work with are:

Anti-Spam

Send Connectors

Receive Connectors

Transport Rules

Accepted Domains

Hub vs. Edge: – Hub is on the inside of the firewall

Edge Transport sits on the edge of the network, in the DMZ. It it isolated, but is there to defend the network. Edgesynch synchrononization is the connection between the hub and edge transport servers.

Hub handles all of the mail flow within the company: Applies Transport Rules, Journaling policies, delivers messages to mailboxes and more.

 

If there is no Edge transport role, the Hub will relay messages to the internet. The Edge Transport server minimizes attacks from the internet – virus, spam, etc. . You can have more than one Hub or Edge Transport servers for failover capabilities.

You can export settings from one Edge Transport server to a 2nd Edge.

Do you need to have an Edge Transport Server? No. However, it is recommended that you have some kind of protector in se.

Without an Edge Transport Server, by default you will be missing Anti-Spam solution, and certain Transport Rules.

You can enable Anti-Spam on the Hub transport server, or a 3rd party solution.

Mail will go through Hub and Edge transport servers. All mail will flow between them.

  • If you have one HT and one ET, all mail will flow between them, both incoming and outgoing
  • To make the connection between the HT and ET you need to make a manually configured synchronization. It is also called a subscription or an “edge synch process”
The Edge Transport Role is engineered to protect on the front lines of your network
  • It isn’t part of the domain
  • It can cut down the spam at the front door
The Hub Transport role, although it can protect the front lines to a degree, is designed to be a second layer of defense and has a greater role in message compliance, internal mail flow and policy enforcement.

 

 

 

A large majority of the content provided in my Blog’s Exchange series is derived from J. Peter Bruzzese’ excellent Train Signals Exchange Server 2010 Video Disk Series, as well as my own Exchange 2010 lab. Trainsignal.com is an invaluable source for accurate, easy to understand, IT information and training. http://www.trainsignal.com

Exchange 2010 – Part 19 – Client Access Server Security and Secure Socket Layer Certificates

Client Access Server Security and Secure Socket Layer Certificates

In this post we will review:

– CAS security through digital certificates and how these vary.

– We’ll also review the different SSL certificate types.

– Lastly, we’ll work through the following:

  1. Create a Certificate Signing Request (CSR)
  2. Obtain a certificate from a Certification Authority (CA)
  3. Install the SSL Certificate on the Client Access Server

Up until this point in your Exchange deployment, you may have configured access with the default self-signed certificate. This may be problematic because it doesn’t support all of the access methods (Outlook Anywhere) and isn’t the most secure method of authentication. You may decide to obtain a trusted certificate from a third-party commercial Certification Authority (CA) and install that certificate on the Client Access Server. You do also have the ability to use a PKI certificate through Microsoft Certificate Services which you can setup internally, however, the infrastructure costs and labor may not be worth the trouble.

Managing Authentication

  • A digital certificate will authenticate to the client that the server with the certificate is trust-worthy. The server can prove, they are who they say they are.
  • In addition, a digital certificate will ensure the data that is exchanged is protected.
  • By default, with Exchange 2010, client communications are encrypted using SSL with Outlook Web App, Exchange ActiveSync, and Outlook Anywhere (SSL will not use the Self-Signed Certificates). By default, POP and IMAP aren’t configured to communicate over SSL. You will use the IIS Manager to ensure SSL is enabled on the virtual directory.

Go to the IIS Manager on your mailbox server. Select the server itself, scroll down to Server Certificates. Here you’ll find the Microsoft Exchange Certificate (Issued to itself by itself).

Click Image to Enlarge

You can double-click on the certificate and check out the properties and see that it’s not trusted.

In IIS, expand Sites and then Default Web Site.  If we look at the different sites in IIS, as far as SSL turned on, click on OWA, and then Secure Socket Layer settings, and see if it says “Require SSL”. We can test to see if that works by browsing to localhost in the web browser. An easy way to do this is to click on the “Browse: 443 (https)” link in the Actions pane:

iissslbrowse443
Click Image to Enlarge

This will open the browser and we’ll be brought to our Outlook Web App. We will have a certificate error. Users will have to install the certificate if they want to get rid of the Red Security Trust Bar in their browser. In this case we will want to install the certificate into the Trusted Certificate Store. Windows cannot validate the certificate, but since we know where the certificate is from we can install it and accept the warning.

Three types of Certificates:

  1. Self-signed: Signed by the application itself (in our case Exchange 2010) and will allow for OWA and/or ActiveSync functionality but not Outlook Anywhere. *For these to work you have to manually copy them over to the trusted root certificate store of the client computer or mobile device.
  2. Public Key Infrastructure (PKI): Requires setting up certificate servers and establishing the certificates for communication.
  3. Trusted Third-Party Certificates: Provided by a CA, these are automatically trusted by clients (unlike the two options above), so the deployment is simplified.

Certificate Types

When you go to purchase a certificate from a CA you’re going to find that different types to purchase.

  • Wildcard Certificates: Can represent multiple domain names (for example *.jasoncoltrin.com), however these types of certs provide a less secure method because the wildcard can be used for any sub-domain. Microsoft does not recommend wildcard certs, but to use SAN’s.
  • Subject Alternative Name (SAN) or Unified Communications Certificates (UCC) certificates are considered better in this regard because you specifically list out each of the trusted domain names. *It is considered best practice to use as few host names as possible (perhaps as few as three).

The CA Process for Obtaining and Installing Certs

  • Take a look at the GoDaddy website for SSL Certificates
  • Begin the process of managing a purchased certificate
  • We will return to our Exchange Server and use the Exchange Certificate Wizard to obtain a Certificate Signing Request (CSR)
  • Use the CSR to complete the GoDaddy certificate process
  • Once that certificate is provided (up to 72 hours), we will install it on our Client Access Server
On our Mailbox Server, open the EMC, browse to Server Configuration.
Under the Server Config Node, beneath the servers, we will have our Exchange Certificates.
What we really want is an SSL certificate from a CA.
In the GoDaddy website, we’ll purchase our cert, manage our Products -> manage my certificates, and then in the SSL management, we will click “Request Certificate”. It will ask where the cert will be hosted. We will want to choose Third Party or dedicated server. Now we will need to Enter your Certificate Signing Request (CSR). Use at least a 2048 bit key.

 

Go back to the EMC, under server configuration, in the Actions Pane, click on New Exchange Certificate. For Starters, enter a friendly name for the certificate.
If we want to Enable Wildcard Certificate we can do that here. But we don’t want that at this time, we want a literal domain name so leave unchecked and click next.
Now depending on the cert purchased, our options here will be different. For example we have 5 certs purchased and can only use 5 names.
For Federated Sharing, we will place a checkmark in the Public Certificate because in the future we may want to Federate with a different site.
For Client Access Server (Outlook Web App), for the Intranet – you may want to use a local name like mail.jasoncoltrin.local and for the Internet – use mail.jasoncoltrin.com
New Exchange Certificate
Click Image to Enlarge
We want Exchange ActiveSync, so perhaps sync.jasoncoltrin.com is the name we’ll want to use. Most use mail.domainname.com.
Go down the list and have Exchange Web services enabled; Outlook Anywhere enabled.
Autodiscover used on the internet: Autodiscover URL to use: autodiscover.jasoncoltrin.com.
The use of sync.jasoncoltrin.com differentiates and relates to mobile devices. When you set up the cert, that’s when it (the name) counts. For the dropping of POP and IMAP support, in all honesty is probably a good thing, and we prefer a more secure protocol and have everyone come in through ActiveSync. With ActiveSync we have the ability to wipe devices.
At this time we don’t need a cert that supports POP or IMAP.
For Unified Messaging, you can go with a self-signed cert.
At this time we are going to skip Hub Transport server mutual TLS and Hub Transport server for POP/IMAP.
At this time we are not going to use Legacy Exchange Server.
Clicking next will give us a review of our cert (request). In our case we have 6 names. To bring this down to 5, we can change intranet/internet mail.jasoncoltrin.local to mail.jasoncoltrin.com and save a name.
Click next, and the wizard will ask for some information. The full legal organization name, Org unit (none), Country, City, State, Certificate Request File Path – name the file something like “SSLRequest”, then New and Finish. Make sure the CSR generated is 2048 bit. Once finished, browse to where the file was placed, open the Certificate request with notepad, and copy and paste the entire string including –Begin new cert —  to   —End New Cert..— into the GoDaddy.com CSR text box.
SSLCertcopytoCSR
Click Image to Enlarge

After submitting the encrypted data to GoDaddy, you will see the Subject Alt Names and Primary Domain Name. Your cert will be issued shortly (72hrs), and at that time we will be able to import it. Once the cert is issued, you can download it from GoDaddy. The cert will come down zipped, so unzip it.

Go back to the EMC, You will still see your requests and your self signed cert. Right-click on the SSL Cert and choose Complete Pending Request.

CompleteCertRequest
Click Image to Enlarge

Browse to the downloaded cert (domain.com – not the intermediate cert), click complete, and that’s all there is to it. So we’ve installed it but don’t have any services using it. Right-click on the cert and choose Assign Services to Certificate.

AssignCertServices
Click Image to Enlarge

Use SMTP, IIS, click Next, and then Assign.

AssignServices
Click Image to Enlarge

Do we want to override? Yes.

When we downloaded and unzipped the SSL Certificate, we also received an Intermediate Certificate. The intermediate certificate is used to enhance the security of the root certificate. These are also called a Chained Root Certificates. There are instructions on the GoDaddy site for installing the Intermediate Certificate. It is optional, but you should install the Intermediate certificate if the CA provides you with one, but we will forego that for now. Your CA may or may not issue Intermediate certificates.

In conclusion, in this lesson we discussed the benefits of SSL digital certificates, encouraged SAN certificates, worked through the process of requesting a certificate from the GoDaddy Certificate Authority, and installed and enabled services using that cert on our Exchange Client Access Server.

 

 

 

 

A large majority of the content provided in my Blog’s Exchange series is derived from J. Peter Bruzzese’ excellent Train Signals Exchange Server 2010 Video Disk Series, as well as my own Exchange 2010 lab. Trainsignal.com is an invaluable source for accurate, easy to understand, IT information and training. http://www.trainsignal.com

Exchange 2010 – Part 18 – Understanding and Managing Outlook Anywhere and POP/IMAP

Exchange 2010 – Part 18 – Understanding and Managing Outlook Anywhere and POP/IMAP

In this post, we’ll look at two main parts to Outlook Anywhere and the POP/IMAP protocols:

  1. We will explain the concepts of Outlook Anywhere, POP, and IMAP.
  2. We will look at the implementation of Outlook Anywhere, POP and IMAP.

Outlook Anywhere, POP and IMAP are different from Outlook Web App and ActiveSync. You can get OWA and ActiveSync to work with an Exchange self-signed certificate. Although for a production environment, it’s best to setup your own cert server or purchase a certificate from a Third-Party Certificate Authority. But with Outlook Anywhere, POP/IMAP, to go live, you need valid certificates. If you’re tempted to setup a PKI infrastructure, it’s not as easy as you might think. It usually isn’t worth the headache when you can purchase certs from CA’s for a very low cost.

Outlook Anywhere Overview

  • Outlook Anywhere allows external clients to use Outlook 2003/2007/2010 to connect directly to their corporate network email, without using a VPN connection.
  • Outlook Anywhere uses a networking feature called RPC over HTTP (in fact, in legacy Exchange versions that was the name of Outlook Anywhere). RPC over HTTP is a component in Windows – where Outlook Anywhere takes client connections using Remote Procedure Calls, boxes it up in HTTP and passes it through the firewall.
  • All you have to do is enable Outlook Anywhere on a CAS server
  •      *Install a valid SSL certificate – because certs touches on many areas which we will cover in a later post.
  •      *Install the RPC over HTTP component – this component is probably installed already during an initial installation. If we still need to install, you go to Server Manager -> Features -> Add Feature
  •      *Enable Outlook Anywhere.
  • You can enable Outlook Anywhere from EMC or EMS
  •      *”Enable-OutlookAnywhere” cmdlet.
  • To test Outlook Anywhere you can use the following tools:
  •      *Run the Test-OutlookConnectivity cmdlet to ensure your RPC over HTTP connections and TCP/IP settings are right.
  •      *Run the Exchange Remote Connectivity Analyzer (ExRCA) tool.
  • Testing looks for the following:
  1. Autodiscover connectivity
  2. DNS validation
  3. Certificate Validation
  4. Firewall configuration
  5. Client connectivity

POP and IMAP Overview

  • Protocols for connecting to Exchange (disabled by default) most organizations would prefer you do not use POP as a security liability.
  • The old standard: POP was designed for ‘offline mail processing’
  •       * POP removes emails from the server and brings them down to a local client (unless configured otherwise)
  •       * POP doesn’t provide calendaring, contacts, or tasks
  • The new standard: IMAP
  •      * Provides both online and offline access but still no extra features like calendaring, contacts, or tasks
  • Note: These are ‘receive protocols’ not ‘send protocols’ so they still rely on SMTP to send email
  • With both POP and IMAP, the client is responsible for checking in for mail, it isn’t pushed down to the client.
  • Enabling POP and IMAP is as easy as enabling the services on the system
  • After the services are running you can enable your users to use POP or IMAP
  • You can configure various properties for each protocol including:
  •      * Connection Limits
  •      * Security
  •      * Message Retrieval format options

To enable Outlook Anywhere, open the EMC and browse to Server Configuration and then the Client Access Role:

OutlookAnywhereCA1

Click Image to Enlarge
In the screenshot above, you can see that Outlook Anywhere is already enabled. However if it was not, and you wanted to enable it, you’d highlight the Client Access server, and then in the Action Pane, click on Enable Outlook Anywhere.
ScreenShot004
Click Image to Enlarge

From here you will be directed to a simple Wizard. Here you will enter the External Host Name:

ScreenShot005

Click Image to Enlarge

Here we will want to provide an External Host Name that an external client will use to connect to the server, something like site.jasoncoltrin.com or mail.jasoncoltrin.com.

Client Authentication method:

Basic Authentication – A client will need to provide a domain/username/password and will need to be entered every time when connecting to the server. When Basic Authentication is used, the information will be sent in clear-text over the wire.

NTLM Authentication – The user doesn’t have to enter a Username/Password, the windows network authentication is used and is encrypted and a hash is passed through the networks. NTLM Authentication can cause problems when trying to pass the encrypted traffic through firewalls, and some Exchange Admins will want to use Basic authentication if users are not members of the Exchange Server’s domain. Clients that have already logged into a domain, are simply passing cached credentials to Exchange.

Allow Secure Channel (SSL) offloading – This is all about if you have a separate server for SSL encryption/decryption. Some choose to use a SSL accelerator to offload the CPU processing power used for SLL.

First, make sure that under the Server Manager -> Features -> make sure the RPC over HTTP Proxy feature is Installed/Added.

The command for enabling Outlook Anywhere with the Exchange Management Shell will something like the following:

enable-OutlookAnywhere -Server ‘EXCH1’ -ExternalHostname ‘mail.jasoncoltrin.com’ -DefaultAuthenticationMethod ‘Basic’ -SSLOffloading $false

 To configure POP3 and IMAP4, we do not enable/configure it through the Exchange Console, we will actually go into the server’s services:

Start -> Administrative Tools -> Services (control panel)

Find the service named Microsoft Exchange POP3 ->Startup = Automatic -> Startuptype: Automatic (then start the service)

Find the service named Microsoft Exchange IMAP4 ->Startup = Automatic -> Startuptype: Automatic (then start the service)

To make changes to the protocols, you can change them in the EMC -> Client Access -> POP3 and IMAP4 tab.

To Configure the Clients i.e., to decide which recipients are allowed access to Outlook Anywhere/POP3/IMAP4, go into EMC ->Recipients ->Right-click on users -Properties ->Mailbox Features Tab -> Enable/disable POP3/IMAP4

Using the Set-CASMailbox cmdlet

In order to control the access to some of our client access server settings, we want to use the Set-CASMailbox cmdlet.

  •  The Set-CASMailbox cmdlet is used to set attributes related to client access for ActiveSync, OWA, Outlook Anywhere, POP and IMAP for specified users.
  • You can use the command with the -MAPIBlockOutlookRpcHttp parameter to determine if clients can connect to Outlook using Outlook Anywhere. For example, if you want make sure users in a certain location deny them the ability to use Outlook Anywhere.
  •      * Get-Mailbox “UserHere” | Set-Casmailbox -mapiblockoutlookrpchttp:$true
  •      * Get-Mailbox -OrganizationalUnit “OU here” | Set-Casmailbox -mapiblockoutlookrpchttp:$true (anyone who has this applied will not be allowed to use Outlook Anywhere).
  • Or you can use ISA or some other solution to block entry (or other proxy filtering software)
To verify Outlook Anywhere has been enabled, you can see an event in the Application Log event 3006, “The Outlook Anywhere feature has been enabled.”

In review, we learned the purpose of Outlook Anywhere, POP and IMAP. We reviewed the initial configuration of these different access methods. It’s not all that complicated to setup.

A couple of EMS points to remember:

*Enable-OutlookAnywhere (can enable through shell)

*Test-OutlookConnectivity (ensures connectivity is solid) – an excellent tutorial for using the Test-OutlookConnectivity cmdlet is located here: http://blogs.catapultsystems.com/tharrington/archive/2010/09/17/troubleshooting-the-client-access-server.aspx

*Set-CASMailbox (cmdlet configures users for access to the Client Access Server)

 

 

 

A large majority of the content provided in my Blog’s Exchange series is derived from J. Peter Bruzzese’ excellent Train Signals Exchange Server 2010 Video Disk Series, as well as my own Exchange 2010 lab. Trainsignal.com is an invaluable source for accurate, easy to understand, IT information and training. http://www.trainsignal.com

Exchange 2010 – Part 17 – Using the ECP to manage ActiveSync

Using the ECP to Manage ActiveSync

In this post, we will be visiting the Exchange Control Panel (ECP) to see all the new administrative control we have been given with SP1, without having to work on a system with the EMC Management Tools installed. You may recall our first visit to the Exchange Mangement Console in Part 8 of this series.

To get to the Exchange Control Panel, log into your OWA site as an administrator. From here, you will see the options button in the upper right-hand corner of OWA, this contains the link to the ECP.

From within the Administrative Control Panel we can perform the following (new w/SP1) administrative tasks:

  • Manage default access for mobile devices
  • Configure email alerts when a mobile device is quarantined
  • Create personalized recognition or quarantined messages
  • List quarantined mobile devices
  • Create and manage device access rules
  • Allow/Block specific devices
  • Initiate password recovery or remote wipe of a user’s mobile device

To manage the default access for mobiles, go OWA as administrator, then go to options -> View all options -> Manage My Organization -> Phone and Voice:

ECP Mobile
Click Image to Enlarge

Here, when a device that isn’t managed by a rule or personal exemption connects to Exchange we can allow access, block, or quarantine (on a case by case basis) mobile devices. If we choose, we can send out notification warnings that will go out to administrators.

Under ActiveSync Device Policies, we have a duplicate of what is in the EMC, in that we have a default policy, and the ability to look at, and change, policy settings (Device Security, Sync Settings, Device Settings).

We can create additional activesync policies here as well. Polices created here will be replicated in the EMC. There are some options/tabs that exist only in the EMC however; Device Applications Tab and the “Other” tab: discrete management of Applications on Mobile Devices.

So this is a short post but I think is worthwhile looking at the new enhancements for the Exchange Control Panel in SP1.

 

 

 

 

A good majority of the content provided in my Blog’s Exchange series is derived from J. Peter Bruzzese’ excellent Train Signals Exchange Server 2010 Video Disk Series, as well as my own Exchange 2010 lab. Trainsignal.com is an invaluable source for accurate, easy to understand, IT information and training. http://www.trainsignal.com

Exchange 2010 – Part 16 – Concepts and Management of Outlook Web App and ActiveSync

Concepts and Management of Outlook Web App and ActiveSync

In this post, first, we will explain virtual directories and how they are related to the CAS services.

Next we will help you understand Outlook Web App (OWA) and ActiveSync features.

Last, we will use a Scenario to help guide us in the creation and application of OWA and ActiveSync policies.

Scenario: OWA and ActiveSync Management

First, we will help our IT team gain a greater understanding of OWA and ActiveSync.

Next, we will perform the following OWA management tasks:

  • Adjust the authentication for the virtual directory to allow for Integrated Windows authentication. This allows for single sign-on for internal clients.
  • Disable WebReady Document Viewing for the virtual directory.
  • Create an OWA policy and apply it to a researcher user “Alex Heyne” that will ensure he only uses OWA Lite.

Finally, we will do the following ActiveSync management tasks:

  • Block “Unknown Servers” from the virtual directory.
  • Create an ActiveSync policy and apply to all users in the Chicago OU.

Virtual Directories

Web applications are represented by virtual directories that point off toward physical folders.

  • For example, Exchange Outlook Web App has an OWA virtual directory that points off to a literal folder on your system.

You access the virtual directory through its virtual directory name, not its physical folder name (although the two may be the same.)

You can see virtual directories in IIS and also quickly find the physical location on your system through the Properties of the virtual directory.

Although you have default virtual directories created for you when you install the CAS role, you can create additional virtual directories if you like.

In the EMC, go to Server Configuration -> Client Access. Here you will find owa (Default Web Site). Looking at the properties of OWA, we can see both the internal and external URL’s, as well as a number of tabs used to configure OWA.

Exchange Management Console OWA properties
Click Image to Enlarge

Each of the options in the tabs is part of IIS on the client access role. For the most part, if you want to see the location of the virtual directories and their physical location on the server, we would need to open ISS:

IIS Virtual and Application directories
Click Image to Enlarge

Here, take note that some of the sites are considered Virtual Applications (highlighted in red), as opposed to Virtual Directories (highlighted in green). Sometimes you’ll need to use IIS to configure things like SSL.

But for now, lets look more into OWA in the EMC.

Virtual Directory Settings vs. Policy Settings

Virtual directory settings are made through the Server Configuration node

  • Some virtual directory settings are only found under the Server node, whereas others may be configured in a policy as well.
Policies are created under the Organization Configuration node
  • Policies override virtual directory settings
  • There are default OWA and ActiveSync policies create
  • Only one policy (one for OWA and one for ActiveSync) can be applied to a mailbox at a time and if no policy is applied, the virtual directory settings apply.
Understanding OWA Features:
Virtual Directory Property Tabs:
  • General
  • Authentication
  • Segmentation
  • Public and Private Computer File Access – WebReady Document Viewing
  • Remote File Servers
Policy Setting Tabs:
  • General
  • Segmentation
  • Public and Private Computer File Access – WebReady Document Viewing
Note: Public and Private Computer File Access provides two tabs but you cannot have different settings on each one.
In the EMC -> Server Configuration -> Client Access -> OWA Settings for this virtual directory.
General Tab: shows internal url and external url (informational) -config is actually in DNS
Authentication Tab: Use forms-based authentication. Logon format – Domainusername is secure but not completely secure without SSL.
Use one or more standard authentication methods:
-Integrated Windows Authentication. The client computer has to be a member of the same domain or in a trusted domain.
-Digest authentication for windows domain servers (users have an account in AD)
-Basic authentication (password is sent in clear text). Can be used in a secure way if you use SSL.
Segmentation Tab: you can determine if you wan to enable or disable certain features.
For example “Premium Client” is the full version of Outlook Web App. You can choose to use a “Lite version” of OWA. You can force the lite version of OWA for users of Firefox or Safari. You can disable things like Instant Messaging and Text Messaging.
Public Computer File Access tab:
-Direct File Access – determines how files will be allowed or denied access. If you connect on a “Public” computer, you can enable or disable the ability for users to open file attachments. Direct File Access allows you to allow or block or Force Save of even unknown files.
-In the Private File Access tab: same exact settings as above.
WebReady Document Viewing: allows OWA documents to be converted to HTML and shown in the browsers. You can force docs to be changed to HTML before being opened in a supported application.
You may not want a certain document to be shown in the browser. This provides an opportunity for users to view the document at least even if they don’t have a supporting application.
Remote File Servers Tab: you might want to allow or block file servers here. You can enter the domain suffixes that should be treated as internal.
You have an opportunity to use Policies to override the settings placed on the virtual directory settings.
Under Organization Configuration -> Client Access role.
Provide a new policy name. Enable/disable features -> New. Now after creating the policy, go back and open up the policy. You will have more features available now that the policy has been created. It’s important to consider these items again. If you do not enable direct file access, users will not be able to download attachment files.
Once the policy has been created, you need to apply the policy. Take for example, you wish to apply a new policy to an individual user. Go into Recipient Configuration, pick the mailbox, go to Mailbox Features tab -> Select OWA ->Properties. Now you can choose an OWA mailbox policy to take precedence over the virtual directory settings.
Outlook ActiveSync Features:
Virtual Directory Property Tabs:
  • General
  • Authentication
  • Remote File Servers
Policy Setting Tabs:
  • General (Allow non-provision-able devices -this allows mobile phones to sync even if they do not support policy settings)
  • Password
  • Sync Settings
  • Device
  • Device Applications
  • Other
Note: Some features require Exchange Enterprise Client Access Licenses for mailboxes that have policy setting restrictions
Go to the EMC ->Server configuration -> Client Access -> Exchange Activesync tab properties.
3 tabs:
General tab – internal and external urls
Authentication tab – Basic authentication/certificates
Remote File Servers – same configuration of virtual directories
EMC -> Organization Configuration -> Client Access -> Exchange ActiveSync Mailbox Policies
-allow non-provision-able devices
Password tab -> many options here for passwords (length, expiration, require encryption, etc.)
Sync Settings -> Include past calendar items, Include past email items, Allow Direct Push when roaming (you can force it so that roaming users will not get Direct Push). Allow attachments.. etc.
Device tab -> Allow removable storage, allow camera, allow wifi, allow infared, allow bluetooth etc.
Device Appliations tab -> Allow browser, allow unsigned applications (Need enterprise CAL)
Other tab -> (Need Enterprise CAL)
To block unknown servers from the virtual directory (by default is allow), go to the EMC -> Server Configuration -> Client Access -> Exchange ActiveSync Tab -> Virtual Directory Properties. Go to the Remote file servers tab -> Unknown servers by default is set to allow. OWA has the ability to access file shares and SharePoint libraries. If there are no dots in a URL a user clicks, it is considered internal. If there are one or more dots in the URL, then it will only be considered internal if the domain suffix has been added to the configuration.
The following Exchange Management Console Shell commandlet will apply a custom activesync mailbox policy to the OU Chicago:
Get-Mailbox -OrganizationalUnit Chicago | Set-CASMailbox ActiveSyncMailboxPolicy “ASChicago”
So in this post, we reviewed:
  • The feature settings for Outlook Web App and ActiveSync
  • Both virtual directory settings (found under the Server Configuration node) and policy settings (found under the Organization Configuration note)
  • Made virtual directory adjustments and created policies and then applied those to users within our organization using a powershell commandlet.

 

A good majority of the content provided in my Blog’s Exchange series is derived from J. Peter Bruzzese’ excellent Train Signals Exchange Server 2010 Video Disk Series, as well as my own Exchange 2010 lab. Trainsignal.com is an invaluable source for accurate, easy to understand, IT information and training. http://www.trainsignal.com

 

 

 

 

 

Exchange 2010 – Part 15 – Overview of the Exchange CAS Server Role

The Exchange 2010 CAS Server Role

In this post, we will review the purpose of the Client Access Server (CAS) Role in Exchange 2010.

We will discuss the following CAS Role aspects:

  • Outlook Web App
  • Exchange Active Sync
  • Outlook Anywhere
  • POP3 and IMAP
  • The Availability Service
  • The Autodiscover Service

Take for example the scenario: a Team Meeting to Discuss CAS role

  • The more mobile your users wish to be, the more the CAS Role comes into focus
  • You most likely will have mobile users that want to connect to Exchange using their browser, mobile, smart phone or tablet, through Outlook or some POP/IMAP oriented mail application
  • The role of an administrator is to ensure connectivity from any remote location, and that connectivity is provided without compromising security

 

The Evolution of CAS

  • Exchange 2000/2003 didn’t have CAS servers, they had “Front End” servers
  •      – With “Front End” servers, internal clients connected with Outlook using MAPI. MAPI is “Messaging Application Program Interface” – it allows you to send email with Outlook. MAPI is the protocol Outlook uses to connect with Exchange. Internal Outlook clients connected directly to Mailbox servers using MAPI over RPC.
  •      – External clients used the “Front End” as more of a proxy that could handle RPC over HTTP (for Outlook Anywhere), HTTPS (for Outlook Web Access, or OWA), and POP/IMAP. Clients connect in, provide credentials, and the Front End server would decide which mailbox to connect.
  • Exchange 2007 introduces the CAS role which is more than a proxy server but offloads a significant amount of the load that the mailbox servers typically handled
  •      – Internal MAPI clients still connect directly to the MB role. In 2007, The Client Access Role started to handle middle tier of a three tier application (the logic tier).
  • Exchange 2010 introduces a new service (MSExchangeRPC) so that the CAS Role is “true” middle tier. It now takes on the brunt of the work that the MailBox Role had to do in the past.

The Exchange 2010 CAS Role is Middle Tier

  • In Exchange 2010, the CAS Role handles both external and internal connections to the Mailbox role; with the exception of Public Folder connections. So whether they’re coming from OWA or Outlook inside the LAN, they will both go through the CAS Role.
  • MAPI and directory connections are handled by thte CAS server now, relieving a ton of load off the Mailbox server role, and ultimately increasing the number of concurrent connections to a Mailbox server (in Exchange 2007, we had 64K and now we have 250K).
  • By offloading the CAS features, now we have a lot more responsibility with CAS, so we need to ensure load balancing and CAS Array concerns as well as security concerns are met.

CAS Role Aspects

  •  Outlook Web App: Allows you to access email through a web browser (including IE, Firefox, Safari and Chrome). This used to be called “Outlook Web Access”. The biggest change that users appreciate is that it works in different browsers on the same level. It is handled by the CAS Role and IIS
  • Exchange ActiveSync: Allows you to synch your data between your mobile device or smart phone and Exchange – There are varying levels of ActiveSync support in devices and one key security element is remote wipe, which is not available for all devices.
  • Outlook Anywhere: Allows you to connect to your Exchange Mailbox externally using Outlook (RPC over HTTP) without going through a VPN connection. Its great for Outlook at home with the “In-house” experience.
  • POP/IMAP support – Mail clients other than Outlook (e.g. Mozilla Thunderbird/Live Mail) that connect with POP or IMAP are supported through the CAS role.
  • Availability Service: Shows free/busy data to Outlook 2007/2010 users.
  • Autodiscover Service: Helps Outlook clients and some mobile phones to automatically receive profile settings and locate Exchange services.

Looking at the Exchange Management Console:

Under Organization Configuration, you can make changes to the Client Access Role:

ClientAccessRole

At this point you have two options, modify the default policy of Outlook Web App Policies or the Exchange ActiveSync Mailbox Policies.

As an administrator you can control functionality of the user experience and even the devices connecting to the CAS.

Is modifying the following options a good or bad April Fools joke to play on your User’s smart phones?

Click Image to Enlarge

 

ActiveSynchOptions2
Click Image to Enlarge

Maybe not such a good idea to mess with these…

Client Access under the Server Configuration Node in the EMC, provides us with much more configuration options.

ServerConfigCAS

Some of the different tabs located here are:

  • Outlook Web App – Config changes to owa Default Web Site
  • Exchange Control Panel – connected with IIS ecp default web site
  • Exchange ActiveSync – Configure IIS/ActiveSync default website
  • POP3/IMAP4 – configure these mail protocols
  • Offline Address Book Distribution – If you recall we talked about the OAB now being distributed through web services
  • Outlook Anywhere – in a future post we will hit the “Enable Outlook Anywhere…” feature and go through it’s configuration.

So in review we’ve explained the purpose of the Client Access Server roles, discussed the different CAS features, and toured the EMC locations for working with the Client Access Service.

 

 

 

A good majority of the content provided in my Blog’s Exchange series is derived from J. Peter Bruzzese’ excellent Train Signals Exchange Server 2010 Video Disk Series, as well as my own Exchange 2010 lab. Trainsignal.com is an invaluable source for accurate, easy to understand, IT information and training. http://www.trainsignal.com