Tagged: Office 365

Office 365 – Prepare the client computer and configure remote connectivity

Client Computers

Trusted zones

Office 365 offers a number of office applications via a web browser e.g. Office 365 plans P1/E1/E2/E3/E4/K1 and K2 allow read write and read only access to office documents.

In order to get uninterrupted access it is recommended the browser be configured with the following trusted sites assignments.

Trusted sites list:

Local intranet list:

  • *.microsoftonline.com
  • *.outlook.com
  • *.sharepoint.com
  • *.lync.com

The above assignments can be configured via group policy or the IEAK. Note that when you configure the trusted browser zones via group policy the end user will be unable to make changes. If you need to implement this in an environment that has not used the ‘site to zone assignment’ group policy object before you may what to script the collection of existing trusted site configuration. See this here.

Client computer requirements

Desktop Setup – required if you’re not installing Office 365 Pro Plus.

Operating system

  • Windows 7 or later
  • Mac OS X 10.5 or later
  • Windows Server 2008 or later
  • Windows XP with SP3; support ends January 2014
  • Windows Vista with SP2; support ends January 2014

Client

  • Office 2010 SP1
  • Office 2007 SP2
  • Office 2011 for MAC
  • Outlook 2003 (POP and IMAP); support ends April 2014
  • Lync 2010
  • Microsoft .NET framework
  • Entourage 2008 Web services addition and Office 2008 for MAC are not supported but probably will work

Browser

  • IE 8 or later
  • Firefox latest version
  • Safari 5 or later
  • Chrome latest version

The Office suite available via Office 365 can be deployed in a number of ways:

  • Download from the portal

Downloads are initiated from the portal by the end user; this will require the end user to have local administrative rights.

  • Network share

The IT Administrator downloads the installer to a network share; this will again require the end user to have local administrative rights. This option requires you download Office 365 Pro Plus using the Office Deployment Tool for Click-to-run.

Create a share on a file server e.g. net share sharename=drive:path

Office365_Deployment3

Download the Click-to-run tool from the Microsoft download center, extract the files to the network share created above. Then configure the configuration xml file. Microsoft documentation here.

Office365_Configuration

Once the configuration is complete, download Office 365 Pro Plus using the download switch.

Office365_Deployment1

To install Office 365 Pro Plus you would run the command below at the client

Office365_Deployment2

Office 365 Pro Plus Group Policy

Administrative templates can be found here.

Office licensing considerations

Originally the Office suite provided via Office 365 had a number of restrictions e.g. the office suite used a retail SKU which prevented it being installed within a terminal services environment. The latest Office suite no longer has that limitation. See more below.

Office365_OfficeProPlus

Installation and use rights here.

Configuring Remote Connectivity

Troubleshooting Remote Connectivity

As Office 365 services are cloud based, so your internet connectivity and configuration needs to be solid. To diagnose and troubleshoot Microsoft have provided the following tools:

MOSDAL

MOSDAL is a good all round tool which collects system and network configuration, performs network diagnostics and logs information for all Microsoft Office 365 applications in use.

To use MOSDAL configure using the setup wizard then reproduce the problem; as you reproduce the problem MOSDAL will collect information, when MOSDAL is finished you can view the report. The MOSDAL report is best viewed top down, first view the summary and drill down where required to view console output, test traces and any attachments.

Remote Connectivity Analyser

browse to http://testexchangeconnectivity.com and select an applicable test e.g. to test Office 365 single sign-on select the Office 365 tab then select single sign-on test. Enter your credentials when prompted and click perform test.

VerifyRemoteConnectivity1

The image above is a single sign-on test I performed whilst my Federation proxy server was offline.

Office 365 Urls and IP address ranges can be found here.

Office 365 port requirements:

Exchange / Email:

  • Outlook 20xx, Entourage 2008, Outlook 2011 for Mac and Outlook Web Access – TCP 443.
  • SMTP mail routing uses – TCP 25.
  • SMTP relay uses – TCP 587.
  • IMAP migration – TCP 143 / 993
  • POP3 – TCP 995
  • Exchange migration – TCP 433 (Staged and cutover)
  • Exchange management console and shell – TCP 443

SharePoint:

  • SharePoint portal (sharepointonline.com) – TCP 443

Lync:

  • Lync Client (Lync Online to on-premises Lync Server) – TCP 443.
  • Lync data, video and audio – PSOM/TLS 443, STUN/TCP 443, STUN/UDP 3478 and RTC/UDP 50000 – 59999

Active Directory / Federation:

  • ADFS and ADFS Proxies – TCP 443
  • Directory Sync – TCP 80 / TCP 443

Verifying service connectivity

To verify Exchange / Outlook connectivity hold down the ctrl key whilst right clicking the Outlook icon in the system tray and selecting connection status.

To verify Lync connectivity browse to your local Lync test site from the list below: NOTE: requires Java be installed.

Once connected click start test, then enter the session ID (any number greater than 0), the click ok.

To verify SharePoint connectivity simply browse to the SharePoint site.

Autodiscover

The autodiscover service; autodiscover takes the email address and password of a user to automatically configure their Outlook profile. Autodiscover will attempt to get the users display name, connection settings for inbound and outbound connectivity, the mailbox server where the mailbox exists, Urls for free / busy, unified messaging, offline address book and outlook anywhere configuration.

Autodiscover will generally utilise a CNAME within your DNS namespace which points to autodiscover.outlook.com. You can test autodiscover using the Microsoft Remote Connectivity analyser.

Autodiscover3

Remote connectivity analyser results.

Autodiscover4

Administering Office 365 via PowerShell

This requires the Microsoft Online Services Module for PowerShell be installed. You can confirm this by opening PowerShell and typing Get-Module -ListAvailable

PowerShell1

Once you have confirmed the module is installed import the module and connect to your Office 365 tenant.

Import-Module

PowerShell2

Put the credentials into a variable $cred

PowerShell3

Connect to the Office 365 tenant using the variable

PowerShell4

To get a list of commands available run Get-Command -Module MSOnline

 PowerShell5

e.g. Get-MsolDomain

PowerShell6

Administering Exchange On-line via PowerShell

Exchange On-line can be administered via remote PowerShell.

First of all create a remote session to https://ps.outlook.com/powershell

RemoteExchange1

RemoteExchange2

Import the session to get the Exchange Online cmdlets. using Import-Session $session. To get a list of commands import the session into a variable and use the ExportedCommands property to retrieve a list of commands.

RemoteExchange3

Run the commands as if you were connected locally.

RemoteExchange4

Advertisements

Office 365 – Manage identity federation by using ADFS 2.0

Configure Directory Synchronisation

Directory synchronisation must be activated within the Office 365 portal; the activation can take 24 hours to complete.

Directory Synchronisation requires:

  • A domain joined computer.
  • Enterprise administrator credentials (it uses these to create a user object in the forest root domain).
  • Global administrative rights within the Office 365 online environment.
  • Computer hardware depends on no. of objects within ADDS but as a rough guide
    • 1.6Ghz CPU
    • minimum of 4GB RAM up to 32GB RAM
    • minimum 70GB hard disk space up to 500GB hard disk space

See this post for more details on deployment and configuration of directory sync.

Configuring and Managing Identity federation using ADFS 2.0

Single sign -on requirements using AD FS 2.0

  • Single Active Directory forest
  • AD FS 2.0
  • Latest client operating system and service packs
  • Public SSL certificate
  • PowerShell 2.0

Relying party trust between federation servers and Office 365 is required the relying trust acts as a secure channel where authentication tokens can pass.

The AD FS 2.0 install wizard will check for and install all the prerequisites with the exception of Microsoft .NET Framework 3.5 SP1 on Microsoft Windows Server 2008.

The federation server(s) requires a public SSL certificate for server authentication purposes. If federation proxies are also implemented then this public certificate should also be installed on them too. The federation servers also require a x.509 token-signing certificate which by default is a self signed certificate created by AD FS and will be sufficient in most scenarios.

It goes without saying but DNS resolution and TCP/IP are fundamental to the operations of AD FS.

Network Load Balancing (NLB) is recommended too to provide fault tolerance at the federation servers and federation proxies.

AD FS Installation

See this post for more details on deployment and configuration of ADFS 2.0.

Implementing single sign-on and two-factor authentication

Office 365 can utilise two-factor authentication but requires single sign-on be implemented first.

Microsoft recommends either using SecurID or using Forefront UAG and it supported two-factor authentication providers.

Two-factor authentication is only supported by Lync, SharePoint and OWA and the computer being used must be joined to a domain.

Office 365 – Lab 1 ADDS and DirSync

Lab 1

Prerequisites

  • Office 365 trial
    • Directory Synchronisation enabled within Office portal
    • Public domain name
    • Applicable DNS records configured
  • Windows Server with ADDS installed
  • Windows 7 client
  • Windows Server client
  • Enterprise Administrator credentials
  • Global Administrator credentials

Purpose

The purpose of this lab is to simulate the implementation of DirSync with Office 365 using an Active Directory domain which has been deployed with a non-public routable DNS domain name e.g. domain.local or domain.internal.

Once DirSync is synchronised with Office 365 then I’ll look at implementing Office 2013 on the Windows 7 client logging in as a domain user and observing the effects of DirSync and the password synchronisation feature.

Lab Setup

Domain Controller

Install Windows Server 2008 R2, assign a static IP address, give the computer a suitable name and then run dcpromo.

Computer Name: ADDS01

IP Address 192.168.0.100/24 Gateway 192.168.0.1 Primary DNS 127.0.0.1

IPConfig

Forest root domain FQDN: office.local

ADDSFRD

The forest functional level needs to be at least Windows Server 2003.

reboot on completion.

DNS configuration

Create a reverse DNS zone for your local subnet.

Create DNS forwarders which point to your ISPs DNS servers and deselect use root hints if forwarders are unavailable.

Remove the root hints.

Active Directory configuration

Using the Domains and Trusts snapin configure a publicly routable DNS name; this UPN must match your domain defined within the Office 365 portal.

UPN

Then configure all users who will be using Office 365 to use the public DNS name for their UPN; you can multi select.

UPN1

DirSync Server

Install Windows Server 2008 R2, assign a static IP address, assign a suitable name and join to the domain.

Computer Name: MSOLDS01

IP Address 192.168.0.101/24 Gateway 192.168.0.1 Primary DNS 192.168.0.100

ipconfig_dirsync

Join the computer to the office.local domain.

Install DirSync ensuring the prerequisite software is installed e.g. Microsoft .Net Framework 4.0.

DirSync configuration

Follow the wizard entering the global administrator username and password for your Office 365 environment.

Azure1

Enter the username and password of an account with Enterprise Administrator membership.

Azure2

Enable password synchronisation – http://technet.microsoft.com/en-us/library/dn246918.aspx. This enables the user to only remember one password; when the user changes their password within the on-premises ADDS the password will be synchronised within minutes.

Azure3

Once you click finish you’ll be prompted to synchronise your ADDS with the cloud.

Azure4

With password sync enabled the directory sync will result in the application event log recording verify Password Change Requests and Password Change Results for user accounts

Azure8

Azure7

You also notice event ID 650 and 651 recorded to signify that synchronisation has started and finished.

Once the directory synchronisation is complete you can verify within the Office 365 portal the last sync time and synchronised users.

Azure5

Azure6

Windows 7 Client

Install Windows 7, assign a suitable and name and join it to the domain. I’ve assumed DHCP is deployed so no need to configure an IP address.

Computer Name: Client01

ipconfig_client

Join the computer to the domain.

Client configuration

Logon to the client computer using your domain credentials e.g. jbloggs@UPN, login to the Office 365 portal and install Office 2013.

Login1

Open Outlook 2013 and follow the wizard, if your Active Directory properties do not have an email address defined as below then then Outlook auto-configure will not populate the Display Name, Email address etc.

ADAttributes

OutlookAutoConfigure

Click next, If you have configured your DNS records as suggested by Microsoft e.g.

DNS_autodiscover

then Outlook will auto-configure itself too, you’ll be prompted for your Office 365 credentials as we are not using federated logins but because the password has been synchronised the password is the same as your Windows login credentials.

Autodiscover1

If you haven’t configured the autodiscover record correctly this step will fail; check out https://www.testexchangeconnectivity.com/ and select Outlook Autodiscover.

Autodiscover2

Outlook 2013 is now connected to Exchange Online

Outlook1

Office 365 – Manage Roles

Office 365 administrator roles

Billing Administrator – manages subscriptions, purchases, support tickets and service health.

Global Administrator – There can only be one, by default it is the person who signs up for Office 365. This administrator can assign other administrative roles.

Password Administrator – manages password resets, service requests and monitors service health. NOTE: This role cannot reset passwords for other administrative roles.

Service Administrator – manages service requests and monitor service health.

User Management Administrator – manage password resets, monitor service health, manage user accounts and groups and manage service requests. NOTE: This role cannot create administrative users nor can it reset the passwords of users with administrative role assignments.

Delegated Administration

Delegated administrators can create users, reset passwords and manage domains.

To enable delegated administration you need to send your customer a link in an email which will enable delegated administration; this is done via the partner page within the Office 365 portal.

office365_delegatedadmin1

Once the customer accepts you as a delegated administrator you’ll be listed within their delegated administrators. The global administrator of the partner Office 365 account can then decide how much administrative access you have over the partners.

office365_delegatedadmin2

office365_delegatedadmin

To access a customers resources using your delegated credentials go to service settings from within your customers portal.

DelegatedAdminServiceSettings

Within SharePoint you can grant your organisation as a support partner access to your customers SharePoint site collections.

DelegatedAdminSharePointAccess

Exchange role-based access control (RBAC) roles

Exchange role-based access control (RBAC) is used to grant administrative users specific privileges within Exchange and allow users to make changes to their personal settings e.g. mobile number.

RBAC can be assigned in 3 ways.

  1. Management role groups; these are used to assign a group of users administrative privileges within the organisation or for objects with a specific attribute.
  2. Management role assignment policies; these are used to assign users more or less privileges over their own mailbox. Only one management role assignment policy can be assign to any one mailbox at a time.
  3. Direct user role assignment; this is where a user account or universal security group would be granted access to a particular role without using a role group or role assignment policy.

The diagrams below show how RBAC components link together.

e.g the Discovery Management role group has management role assignments of Mailbox Search-Discovery Management and Legal Hold-Discovery Management. The assignments link the role group to the management roles Mailbox Search and Legal Hold, if you query those management role using PowerShell you’ll see which cmdlets are available e.g. Get-ManagementRoleEntry  “Mailbox Search\*”

The scope of the management role assignment can be the organisation or a specific attribute e.g. the office attribute equal to “some location” e.g. New-ManagementScope -Name “Ossy Branch” -RecipientRestrictionFilter {Office -eq “Ossy”} If you wanted to protect who could manage mail recipients in the Office location of Ossy, you could make the scope exclusive.

Once the scope is created you would also create New-DistributionGroup as a universal security group (USG) and a New-RoleGroup which defines the Branch e.g.

New-DistributionGroup -Name “Ossy Admins” -Alias OssyAdmins -Type Security

New-RoleGroup “Oswaldtwistle Recipient Admins”

Finally to link together your role group and management role you would create a role assignment defining the scope created earlier e.g.

New-ManagementRoleAssignment -Name “Oswaldtwistle Recipient Admins-Mail Recipients” -Role “Mail Recipients” -SecurityGroup “Oswaldtwistle Recipient Admins” -CustomRecipientWriteScope “Ossy Branch”

Users are now made a member of the USG OssyAdmins would be able to manage recipients who have the Office attribute equal to Ossy.

A custom management role must have a builtin parent role, and cannot have more rights than its parent role i.e. access to more cmdlets. Every role with a Remove- or Set- cmdlet must have a respective Get- cmdlet.

Management Role Assignment

The management role assignment policies are assigned to end users and allow them to manage their own mailboxes and distribution groups; you can introduce new functionality or remove functionality by creating new management role assignment policies, modifying the role assignments and assigning that new policy to a mailbox.

A mailbox can only have one role assignment policy and can only contain roles which are scoped to the end user i.e. start with My…

To view the role assignment assigned use PowerShell to query the management role assignment that are part of the default role assignment policy e.g.

Get-ManagementRoleAssignment | ? {$_.RoleAssigneeName -eq “Default Role Assignment Policy”} | Select-Object Name, RoleAssigneeName

Management Role Assignment Policy

  

Office 365 – Provision and manage users, groups, and domains

Office 365 Identities

Office 365 identities can be either based either in the cloud or federated from Active Directory Directory Services (ADDS).

Cloud identities are authenticated within the cloud and are subject to the password policy stored within the cloud whereas federated identities are authenticated against the on-premises ADDS, once verified a token is passed to the cloud to authenticate the user in the cloud.

Office 365 identities fall under three usage scenarios:

  1. Cloud identities
    1. Primarily used by small organisations with no on-premises ADDS.
    2. No single sign-on possible.
    3. No two factor authentication possible.
    4. Two sets of credentials depending on whether local credentials are required to logon to the local workstation.
  2. Cloud identities with Directory Sync (DirSync)
    1. Primarily used by medium sized organisations with an on-premises ADDS.
    2. Allows for co-existence of Exchange and Lync.
    3. No single sign-on.
    4. No two factor authentication.
    5. Two sets of credentials but as of the latest release of DirSync passwords are now synchronised.
    6. Password policies are defined within ADDS; DirSync requires passwords be at least eight characters.
  3. Federated identities
    1. Primarily large organisations.
    2. Requires a minimum of:
      1. ADDS – should be more than one.
      2. Federation server – should be load balanced.
      3. Federation proxy in the DMZ (if using Outlook)  – should be load balanced and will be a member of a workgroup not the domain.
      4. DirSync server.
    3. Enables single sign-on.
    4. Enables two factor authentication.
    5. Password policies are defined within ADDS; DirSync requires passwords be at least eight characters.
    6. Allows for co-existence of Exchange and Lync.

Creating users

Via the Office 365 portal

Login to the Office 365 portal > users and groups > add > Display Name (mandatory) >  Login name (mandatory) > Assign a location (mandatory) and role (optional) > Assign licenses > next > create (optionally you can have the password sent to you or another email address).

Via PowerShell

Prerequisites:

  • Microsoft Online Services Sign-in Assistant – here
  • Windows 7 or Windows Server 2008 R2
  • Microsoft .NET 3.5.1
  • Microsoft Online Services Module for Windows PowerShell

Open the Microsoft Online Services Module for Windows PowerShell or just open Microsoft Windows PowerShell and just import the Online module using Import-Module MSOnline.

Once in PowerShell get the Office 365 credentials

  • $Cred = Get-Credential

Connect to Office 365

  • Connect-MsolService -Credential $Cred

List of available licenses

  • Get-MsolAccountSku

Create the user

  • New-MsolUser – UserPrincipalName user@domainname.com -DisplayName “Joe User” -UsageLocation [Country e.g. “GB”] -LicenseAssignment [AccountSkuId from the previous command]

If you want to specify a password use the -Password parameter.

Via the bulk import wizard

The bulk wizard can be used from within the Office 365 portal. The bulk wizard simply takes a csv file with the following headers:

  • User Name
  • First Name
  • Last Name
  • Display Name
  • Job Title
  • Department
  • Office Number
  • Office Phone
  • Mobile Phone
  • Fax
  • Address
  • City
  • State
  • Postal Code
  • Country

Username and Display Name are mandatory.

You can also bulk import using PowerShell using a csv file and ForEach-Object loop.

If you wish to set a different password for each user consider omitting the password parameter and using Export-Csv to capture the newly created account details.

Via DirSync

Directory Sync can be used to create users in the cloud from users already defined within ADDS. Directory Sync can also synchronised user password but the passwords must be greater than eight characters. Directory Sync must be activated first within the Office 365 portal; users and groups > AD sync > Activate.

Directory Sync must be installed on a domain computer and requires an enterprise administrator account for the on-premises ADDS; the enterprise administrator credentials are used to create the MSOL_… user account. This is the account which will be used to export information from Active Directory.

The ADDS accounts UPN must be publicly resolvable e.g. @domainname.com

User and Group Properties

User and Group properties can be edited via:

Office 365 console

User properties such as Details, Settings and licenses can be edited here e.g. https://portal.microsoftonline.com/UserManagement/EditUser.aspx?id={Guid}

You can also bulk edit users Domains, Department, Office number, Office phone, Fax number, Street, City, State, Zip / Post Code, Country e.g  https://portal.microsoftonline.com/UserManagement/BulkEditUser.aspx

User admin page

This page is used to reset user passwords e.g. https://portal.microsoftonline.com/UserManagement/ActiveUsers.aspx select the checkbox next to the user.

PowerShell

You can use PowerShell to set basic user properties using Set-MsolUser e.g

SetMsolUser

Other useful PowerShell commands are Set-MsolUserPassword to reset the password; use Set-MsolUser to set the PasswordNeverExpiresFlag.

To assign a licence to a user you would use Set-MsolUserLicense.

Creating a Office 365 domain

The default domain you’re assigned when you sign up for a portal has onmicrosoft.com appended to the tenant name e.g. companyA.onmicrosoft.com.

To assign the companies actual public domain sign into the Office 365 portal > domains > Add domain > [to prove you own the domain you’re adding you’ll need to add a txt or mx record to the DNS zone file of the domain you’re adding to Office 365].

DomainDNSVerify

The record you’re required to create is only needed for the verification process and is completely random.

Licenses and Subscriptions

Licences can be managed and assigned to users via the Office 365 portal and Windows PowerShell.

Before a user can use Exchange they must be granted a licence from the licenses available in the subscription. This can be accomplished via the Office 365 portal or PowerShell; Edit users within the portal or Set-MsolUserLicense within PowerShell. Set-MsolUserLicense can be used in conjunction with New-MsolLicenseOptions. The Licence options allow you to divvy up specifics of the subscription in a granular fashion.

In the Office 365 portal you can add new subscriptions; using the purchase services link.

Licences can be assigned to users with either all licence components or a subset of components.

Recovering Identities and users

Administrators can reset their own passwords, or a global administrator can reset it for you.

If users are deleted they are stored in the deleted view for 30 days. If you need to restore a user from the deleted view you can use Restore-MsolUser or browse to https://portal.microsoftonline.com/UserManagement/DeletedUsers.aspx