Backtrack:  
 
showing posts tagged with 'office365'
 
edited by on February 19th 2021, at 09:54

You can enforce a password change for Office 365 (Azure AD) users without having to reset the password through Powershell.

For a single user:

Set-MsolUserPassword -UserPrincipalName user@domain.com -ForceChangePasswordOnly $true -ForceChangePassword $true

To force all users to change their password:

Get-MsolUser -All | Set-MsolUserPassword -ForceChangePasswordOnly $true -ForceChangePassword $true

You can also use filters ? {} to limit the password change enforcement to specific groups of users.

Note that it is recommended to also use Revoke-AzureADUserAllRefreshToken to end all current open sessions, and immediately enforcing the user(s) to log in again and change their passwords.

edited by on November 9th 2020, at 16:43
If you are using multi-factor authentication, it is not possible to use the old method of connecting to Exchange Online. You will have to install the Exchange Online PowerShell Module, and use the Connect-ExchangeOnline cmdlet to connect.

With the deprecation of Internet Explorer, the old method below no longer works. Use the method described here to install: Installing Exchange Online Management Powershell cmdlets

Old instructions
Log on to Exchange admin center.

In the left menu, click on hybrid.

Click the configure button for the Exchange Online Remote PowerShell Module. This will start the installation.

In the Application Install that appears, click the Install button.



When using  ...
edited by on November 9th 2020, at 16:34

With the deprecation of Internet Explorer, it is currently no longer possible to install the Exchange Online Powershell module via ECP. But you can also install the Exchange Online Powershell module via Powershell itself:

First install the dependencies:

Install-PackageProvider -Name NuGet -Force
Install-Module -Name PowerShellGet -Force

Next install the Exchange Online Management module:

Install-Module -Name ExchangeOnlineManagement
edited by on October 22nd 2020, at 14:35
You can manually trigger an update of Office Click-to-Run installations, without starting any of the Office applications. This can be useful in VDI-environments where it may be necessary to update Office in the source image.

To trigger the update, start the Click-to-Run client with the /update switch.

Perform the update (will show a progress bar):

"C:\Program Files\Common Files\microsoft shared\ClickToRun\OfficeC2RClient.exe" /update user

Silently perform the update (don't show progress bar and force Office apps to restart):

"C:\Program Files\Common Files\microsoft shared\ClickToRun\OfficeC2RClient.exe" /update user displaylevel=false forceappshutdown=true

Both comm  ...
edited by on March 20th 2020, at 16:02

With the strong increase in hackers targeting Office 365 tenants, it may be useful to see who has Global Administrator access in your tenant. This can be done either via the Office 365 Portal but also through Powershell.

Note: be sure to install the required Powershell cmdlets before attempting this.

Connect to your Office 365 tenant:

Connect-MsolService

To retrieve a list of users with the Global Administrator role, run this:

Get-MsolRoleMember -RoleObjectId $(Get-MsolRole -RoleName "Company Administrator").ObjectId | Select DisplayName,EmailAddress

You can append Export-Csv to export the list to a CSV-file.

edited by on March 17th 2020, at 09:26
If you wish to use TLS, or are using TLS authentication in a Office 365 Hybrid environment, and have manually changed or renewed the SSL certificate, you may still get errors about unable to initiate the TLS session (STARTTLS), even though the SSL certificate has been correctly renewed. Just setting the SSL certificate to be used with SMTP is not enough to make TLS work correctly. You also need to (re-)configure the TLS certificate name on your send and receive connectors.

As stated by the manual:

TlsCertificateName
The TlsCertificateName parameter specifies the X.509 certificate to use with TLS sessions and secure mail. Valid input for this parameter is [I]Issuer[S]Subject. The Issuer val  ...
edited by on July 10th 2018, at 14:46
A few steps to enable management of your Office 365 subscription using Powershell. One uses Powershell because not all configuration is available through the Office 365 Portal, and it's also useful for automation.

Note that the old method of installing the Azure Active Directory Module is deprecated. The only supported way is to install the cmdlets directly through Powershell, as described below.

UPDATE (2018-07-09): removed all deprecated information.

UPDATE (2016-04-20): updated links and information.

Download and install the Microsoft Online Services Sign-In Assistant.

Download and install Windows Management Framework 5.1.

Open an elevated Powershell, and run the following comma  ...
edited by on July 9th 2018, at 14:30
You can manage Exchange Online through Powershell in a similar fashion as you would an on-premise Exchange. There are some differences between available cmdlets and what they do between on-premise Exchange and Exchange Online, but the majority are the same.

Using multi-factor authentication
The method mentioned below is deprecated and only works for non-MFA usage. If you are using multi-factor authentication, you will have to use the Exchange Online Remote PowerShell Module to connect to Exchange Online. Instructions can be found in this article.

Using PS remoting, the cmdlets for Exchange Online are imported through the internet, so first, you need to change the Powershell execution polic  ...
edited by on March 12th 2018, at 12:01

A very useful blog article about killing active sessions to a compromised Office 365 account:

https://blogs.technet.microsoft.com/cloudyhappypeople/2017/10/05/killing-sessions-to-a-compromised-office-365-account/

edited by on December 19th 2017, at 09:11
Currently, it's not possible to set up HTML-based auto-reply messages on shared or resource mailboxes, as you cannot directly log on to OWA to set the message. Through Powershell, you can do this quite easily.

First, create two HTML-files containing your internal and external message. You do not have to specify the <html> and <body> tags. Save these to a convenient location. Be sure to save them as regular text files, with extension .txt.

Next, log on to Exchange Online management shell.

cd to the location of the two message files, and load them to variables:

$internalmessage = Get-Content -Path internalmessage.txt

$externalmessage = Get-Content -Path externalmessage.txt  ...
edited by on September 15th 2017, at 14:25
On October 31 2017, RPC over HTTP will be deprecated in Office 365, as stated here. This means that older Outlook versions (those that use RPC over HTTP) will no longer be able to connect to Office 365. The reason for this is that RPC over HTTP will be replaced in favor of the much newer MAPI over HTTP.

This switchover has an impact on all (older) Outlook versions that do not have the required update (incorporating MAPI over HTTP) functionality installed. Only Outlook versions that get this update will be able to connect to Office 365, resulting in the following changes:

Outlook 2007: no longer supported (there is no update).

Outlook 2010: only supported with SP2 and KB 2878264 installed   ...
edited by on April 10th 2017, at 11:36

You can manually trigger Azure AD Connect to perform a sync cycle. Open a Powershell on the server running Azure AD Connect, then type:

  • Perform a delta sync:
    Start-ADSyncSyncCycle -PolicyType Delta
  • Perform a full sync:
    Start-ADSyncSyncCycle -PolicyType Initial
edited by on April 10th 2017, at 10:41

During the installation of Azure AD Connect, the registration of the Azure AD Connect Health for Sync-agent may fail. When this happens, you can manually register the agent by running this Powershell cmdlet:

Register-AzureADConnectHealthSyncAgent -AttributeFiltering $false -StagingMode $false

You need the credentials of an O365 account with Global Admin rights.

edited by on April 6th 2017, at 10:35
Differentiating users that are synchronized from an on-premise AD and users created in Office 365 is easy when logged in through the Office 365 Portal. When using Powershell, it's another matter. While there's a parameter for Get-MsolUser to show only synchronized users, the ability to filter on only cloud users is missing. However, as cloud-only users do not have the ImmutableID set, you can build your own filter.

This one's obvious:

Get-MsolUser -All -Synchronized

You can filter on ImmutableID as it's not set for cloud-only users:

Get-MsolUser -All | ? ImmutableID -eq $null

If you want to filter out external users (i.e. if you shared something in Sharepoint Online with users that aren  ...
edited by on January 23rd 2017, at 11:03
In a hybrid Exchange environment, you may get an error when attempting to log in to Office 365 when performing a management task involving Office 365. When clicking the "Sign in to Office 365" link, the following error is displayed:

critical error
The web page isn't loading correctly. Please reload the page by refreshing your browser.

Technical information: Unable to set the property "mkt" of a null reference or undefined

Not really a solution, but you can work around the issue by performing these steps:

In EAC, navigate to Hybrid.

Click Modify.

Click Sign in to Office 365, type in your Office 365 username and password.

Once logged in, click on the Enterprise tab and try per  ...
edited by on January 9th 2017, at 16:33
A new Powershell module, called Azure AD v2 is available to manage Office365 from Powershell, and is now the preferred method for managing Office365 tenants from Powershell. Unlike the older MSOnline module, you need to download and install this version from the Powershell Gallery, for which there is no direct download link.

Windows 10 already has the PowershellGet module needed to download modules from Powershell Gallery, so all you need to do is run the following in an elevated Powershell:

Install-Module AzureAD

You may get a message about NuGet provider is required to continue. You can safely confirm this.

Everything pre-Windows 10 and starting from Windows 7 SP1 and 2008R2 SP1, you n  ...
edited by on August 10th 2016, at 15:31
It may not seem evident to find out which mailboxes are accessible by a particular user or group. Through EAC, there is no apparent way to do this, as giving access for a user to a (shared) mailbox can only be done through the shared mailbox and then providing the user/group access. There is no way to query a particular user/group and show a list of mailboxes that user/group has access to. Fortunately, it seems that Powershell (EMS) does provide an easier answer.

These cmdlets work in both Office365 and on-premise Exchange 2007 or newer.

List mailboxes to which a user/group has access to:

Get-Mailbox | Get-MailboxPermission -User user1

Although the cmdlet states a user name, replacing th  ...
edited by on June 30th 2016, at 13:11
When you migrated your mail from an on-premise Exchange to Office 365, and you did not (yet) uninstall Exchange and/or clean up AD, Outlook will still try to configure itself to connect to the on-premise Exchange when adding a new account, even though Autodiscover has been configured correctly (autodiscover.domain.tld pointing to autodiscover.outlook.com).

The reason for this is in the way how Outlook performs its autodiscovery attempts. The first step in the discovery process is trying to configure the account using Service Connection Point (SCP), which is defined in AD (or in rare cases, in the registry of the computer). As the SCP is still configured in AD/registry, Outlook will use thos  ...
edited by on April 8th 2016, at 15:57

In-place online archive, this means having your online archive readily available in Outlook, is only available if you have Office ProPlus or a standalone version of Outlook. Outlook from Office Standard (including Office365 Business Premium) does not provide access to the online archive, and as such, it can only be opened from OWA.

edited by on November 23rd 2015, at 10:47
You can block Office 2013 Click-To-Run (CTR) from automatically updating to 2016 through a policy (or registry if you're not in a domain).

If you have the Office 2013 Group Policy templates installed on your domain controller, you can use them to set a policy to disable automatic updating.

You can find the setting at:

Computer Configuration → Administrative Templates → Microsoft Office 2013 (Machine) → Updates

Set Enable Automatic Upgrade to Disabled.

You can also disable the upgrade by manually adjusting the registry.

In regedit, navigate to the key:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\office\15.0\common\officeupdate

Create a registry value:

Type: DWORD

...
 
showing posts tagged with 'office365'