PowerShell Install-Module: The term ‘Install-Module’ is not recognized

PowerShell error : Install-Module: The term ‘Install-Module’ is not recognized as the name of a cmdlet.
This error Is Manly Because Of The Limitation of cmdlet and resource available on Machine.

This Gallery TechNet Will help you to resolve The Error” Install-Module: The term ‘Install-Module’ is not recognized as the name of a cmdlet.”
While Performing This Step We Need to restart the system So Request You to Save Any unsaved Document Before Following the Below Steps.
To Resolve This We Need to Update. Windows Management Framework 5.1 with the Help of Below Link

https://www.microsoft.com/en-us/download/details.aspx?id=54616
*Tested on Client Machine

Step 1 : Run the PowerShell as Administrator.

 

Step 2 : When We try the Command Install-Module msonline
PS C:\Users\Administrator>Install-Module msonline
It Givens Error
Install-Module : The term ‘Install-Module’ is not recognized as the name of a cmdlet, function, script file,or operable program.
Check the spelling of the name, or if a path was included,verify that the path is correct and try again.
At line:1 char :1
+Install-module msonline



Step 3 : To Check the Host version Type Host

PS C:\Users\Administrator>HOST

 

Step 4 :if the Host Version 4.0 or Below That Need to Download And Install the Windows Management Framework 5.1

Need to Update. Windows Management Framework 5.1 with the Help of Below Link

https://www.microsoft.com/en-us/download/details.aspx?id=54616
* Note :When We Download and install windows Management Framework 5.1. it Will restart the Machine So please Save any unsaved Document.


Step 5 : Choose the Download you want as per Your Operating System.

Step 6 : Once we Restart the Machine Than Run the PowerShell as Administrator again.

Step 7 : We can Confirm if the HOST Version is Updated to 5.1

How to Enforce Multi-Factor Authentication for All Users of Your Office 365 Subscription

Multi-Factor Authentication (MFA) is a great security tool, and we always recommend it. Office 365 admins can enforce MFA for users, which means you can help protect anyone sharing your Office 365 business subscription.

To do this you’ll need to be an Office 365 administrator, which only happens with a business plan. If your Office 365 subscription comes as part of a domain hosting package, then you’ll have access to the Admin console. However, if you’ve just purchased a personal subscription (or home subscription for your family), then you won’t have access to the Admin console, and you can only turn MFA on for yourself. If you’re not sure, click the Office 365 app launcher and look for the Admin tile.

The Admin tile on the O365 app launcher

If it’s there, you’ve got access to the Admin console. Click the Admin tile, and on the menu on the left-hand side click Settings > Services and add-ins.

The "Services & add-ins" option in the Admin menu

This opens the Services and add-ins page, where you can make various tenant-level changes. One of the top items will be “Azure multi-factor authentication.”

The "Azure multi-factor authentication" option

Click this, and on the panel that opens on the right, click “Manage multi-factor authentication.”

The "Azure multi-factor authentication" link

This will take you to the multi-factor authentication page. You can immediately turn MFA on for anyone who is using your Office 365 subscription, but, before that it’s best to acquaint yourself with the default settings. To do this, click “Service Settings.”

The "service settings" tab

You can change whatever settings you like, or leave them as the defaults. One potential setting to look at changing is whether or not MFA can be remembered on a device. By default this is off, but turning it on means your family won’t have to go through the MFA process every time they want to check their email or edit a document.

If you switch this on, the default number of days a device can go before having to re-authenticate is 14, which means a phone/tablet/computer will be trusted for 14 days before the user has to go through the MFA process again. Having to go through the MFA process is simple, but having to do it every 2 weeks on every device that your family uses might still be a bit too much and you have the option to set this as high as 60 days.

If you do make any changes to this or any other settings, click “Save” at the bottom to the panel to save the changes, then click “users” to go back to turning on MFA.

The "service settings" options and the "users" tab

Now that you’ve made sure the settings are right, you can enable MFA for each user. Select the users for whom you want to turn MFA.

The users table with a selected user

To the right of the table of users, click the “Enable” option that appears.

The Enable option

On the confirmation screen, click “Enable Multi-Factor Authentication.”

The "enable multi-factor authentication" button

This will enable MFA for the user, and the next time they login to Office 365 on the web, they’ll have to go through a process of setting up MFA. If they don’t log in very often (or you want to make sure you’re around to help them through the process), you can also send them the link from the confirmation screen so that they can set up MFA at a time that suits them. The link is https://aka.ms/MFASetup, which is the same for everyone setting up MFA.

Once you’ve clicked “Enable Multi-Factor Authentication” you’ll see a success message, which you can close.

The "Updates successful" dialogue

MFA is now enabled for the user; now, they need to set it up. Whether they wait until the next time they login, or they use the link we mentioned above, the process for setting up MFA is exactly the same.

Login to your Office 365 account as normal, and a screen will be displayed telling you that “your organisation needs more information to keep your account secure.”

The start of the O365 login process

Click “Next” to be taken to the “Additional security verification” panel, where you can choose your MFA method. We always recommend using an authenticator app, and you’ll have to use Microsoft Authenticator with Office 365. Even using MFA via SMS is still better than not having MFA at all, so choose the method that works best for you in the first dropdown.

The "Additional security verification" panel

We’re going to use a mobile app, which will change the available configuration options. First you need to choose whether to”Receive notifications for verification” (which means a message will pop up on the Microsoft Authenticator app on your phone asking you to approve or deny a login to your account) or whether to “Use verification code” (which means you’ll have to enter a code generated by the Microsoft Authenticator app on your phone when you login to Office 365). Either works fine, and it’s up to you what you choose. After this, you need to click the “Set Up” button to set up the app.

Radio buttons to choose the contact method

At this point a panel will appear telling you to install the Microsoft Authenticator app on your phone and then either scan a QR code or, if you can’t scan the QR code, enter a code and URL instead. Once you’ve done this, click “Next” to go back to the Additional Security Verification window, which will show that the activation status is being checked.

The "Checking activation status" message

This may take a few seconds, and once it’s finished the message will change to show that MFA has been configured.

The successful MFA configuration message

Click Next, and Office 365 will check that everything is working. Depending on what option you selected for verification, it will either send a Deny or Approve message to your app, or ask you to enter a code from the app. In this example, it sent a Deny or Approve message and is waiting for a response.

A message displayed while waiting for you to respond to the test notification

After you’ve verified that MFA is working, you’ll be asked for a phone number in case you lose access to the app.

The mobile phone number text field

This phone number will be used as backup to use SMS or voice calls in the event that you can’t use the Microsoft Authenticator app, such as when you haven’t got Wi-Fi (or you’ve run out of data on your monthly plan, and you’re out and about). It could also be used if you’ve lost your phone, so you might want to choose the number of a family member instead of your own. Once you’ve entered a number, click “Next” to see the final screen.

The app passwordtext box, and Finished button

This page includes a Microsoft-generated password that it will recognize as being created for MFA use. You’ll need to use this password now on rather than the one you normally use, in all of the following apps:

  • Outlook desktop app for your PC or Mac
  • Email apps (except the Outlook app) on an iOS, Android or BlackBerry device
  • Office 2010, Office for Mac 2011 or earlier
  • Windows Essentials (Photo Gallery, Movie Maker, Mail)
  • Zune desktop app
  • Xbox 360
  • Windows Phone 8 or earlier

The next time you try to open any of these apps they’ll ask for your password, so copy it down from here and use it when asked. We can verify that Outlook on your computer needs to use the generated password but the Outlook app on your phone doesn’t, and yes, we find that odd as well, but it’s not a great hardship.

Click “Finished,” and you’ll be taken back to the login screen to login as normal, but this time using MFA. It’s a simple, quick process that provide a valuable layer of extra security, and one that we at How-To Geek strongly recommend.

Add members to O365 Security Groups using Azure AD Powershell Module

Step 1. Create a CSV file with a column “UserPrincipalName” and add all users under it who are to be added as a member of the group.


Step 2.  Run The below command to import the csv file and get the object IDs for members to be added to group

Import-Csv C:\temp\Members.csv csv  | Foreach {Get-Msoluser -UserPrincipalName $_.Userprincipalname | select Objectid } | Export-csv C:\temp\MembersWithObjectID.csv

This will convert the user’s identity to their unique guid details, and export it to the same CSV file.


Step 3. Collect the guid ID of the security group as well to which you want to add the mebers

The below command will help with the object ID of the Group.

Get-MsolGroup  “SecurityGroupName” | FL

I have my object ID as below.

ObjectId                  : XXXXXX-XXXX-XXXX-XXXXXXXXX


Step 4. Run the below command to Add members in the CSV to the Group.

$sub2 = Import-Csv C:\RAhul\sspruser.com.csv

Import-Csv C:\temp\MembersWithObjectID.csv | Foreach {Add-MsolGroupMember -groupObjectid ‘XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX’ -GroupMemberObjectId $_.ObjectId -GroupMemberType User}


Step 5. Verify the users from the Group just added.

Get-MsolGroupMember -all -groupObjectid ‘XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX’ | Select DisplayName,EmailAddress,GroupMemberType | Export-csv C:\temp\security-group-members.csv

Error: No-Start-Connection in AD Connect Export Sync

Getting this error while exporting the objects in AD Connect. You will also see the below result in Sync service.

image

 

Resolution:- To resolve this issue go to Connectors, go to the properties of the connector giving the above error, select “Connect to Active Directory Forest” option and provide the credentials to connect. Once this is successful then sync will start again.

How to put O365 mailbox on in-place hold using the Exchange Online powershell

In Exchange Server, In-Place Hold functionality is integrated with In-Place eDiscovery searches. You can use the In-Place eDiscovery & Hold wizard in the Exchange Administration Center (EAC) or the New-MailboxSearch and related cmdlets in Exchange Management Shell to place a mailbox on In-Place Hold.

Connect to Exchange online powershell and run the below command

New-MailboxSearch -Name “NameOfMailbox” -SourceMailboxes EmailAddress -ExcludeDuplicateMessages $True -InPlaceHoldEnabled $true -ItemHoldPeriod Number of Days -Description In-PlaceHoldDescription

 

Many organizations require that users be informed when they’re placed on hold. Additionally, when a mailbox is on hold, any retention policies applicable to the mailbox user don’t need to be suspended. Because messages continue to be deleted as expected, users may not notice they’re on hold. If your organization requires that users on hold be informed, you can add a notification message to the mailbox user’s Retention Comment property and use the RetentionUrl property to link to a web page for more information. Outlook 2010 and later displays the notification and URL in the backstage area. You must use the Shell to add and manage these properties for a mailbox.

Difference Between Azure AD Connect and Single Sign-On Options

Azure AD Connect offers customers a number of ways to enable a “Single Sign-On” (or SSO) experience for users. I think it is important to understand the differences in these options, so that when you deploy Azure AD Connect into customer environments, you can pick the right solution to suit the business needs.

Single Sign-On is an experience, wherein a single logon event (like logging into your local workstation) will automatically qualify you for login to other, disparate systems (e.g. Office 365)–in other words, you have all the tokens, exchanges and mechanisms in place that are needed just from your primary logon event. From the user’s perspective: after signing into the local Active Directory network on their workstation using a corporate email address, they might then open a web browser, point it at https://mail.office365.com, and automatically be signed into their Office 365 mailbox, without having to provide credentials a second time. This is (so to speak) a “true” SSO experience.

There are three primary methods we can use to achieve “true” SSO:

  1. Password Hash Synchronization with Seamless Single Sign-On enabled
  2. Pass-Through Authentication with Seamless Single Sign-On enabled
  3. Active Directory Federated Services

I am actually going to start with this last option, which was in fact, the original. Many early adopters of the 365 platform ended up with this type of configuration.

Pass-Through Authentication with Seamless SSO

Pass Through Authentication or PTA is the simplified cousin of AD FS. It works both very similarly, AND very differently from the above solution.

Similar to AD FS, it means that all logins rely on the local Active Directory for authentication and sign-in–we still have that same annoying dependency. However, because the cloud authentication takes place via the local Azure AD Connect service, and does not require a complex AD FS server infrastructure or SSL certificates, it might be preferred in some scenarios. You would still want the redundant ISP links, but there are no additional requirements. Therefore, if you are faced with the challenge of keeping passwords and authentication events on-premises, and the customer also wants to keep the complexity down with a lighter on-premises footprint, then PTA is your best option (be sure to also enable SSO in the AAD Connect configuration wizard when choosing this option).

Pass-Through Authentication with Seamless SSO

Pass Through Authentication or PTA is the simplified cousin of AD FS. It works both very similarly, AND very differently from the above solution.

Similar to AD FS, it means that all logins rely on the local Active Directory for authentication and sign-in–we still have that same annoying dependency. However, because the cloud authentication takes place via the local Azure AD Connect service, and does not require a complex AD FS server infrastructure or SSL certificates, it might be preferred in some scenarios. You would still want the redundant ISP links, but there are no additional requirements. Therefore, if you are faced with the challenge of keeping passwords and authentication events on-premises, and the customer also wants to keep the complexity down with a lighter on-premises footprint, then PTA is your best option (be sure to also enable SSO in the AAD Connect configuration wizard when choosing this option).

Active Directory Federated Services (AD FS)

With AD FS, you need to deploy an on-premises service called Active Directory Federated Services, and it’s best if you make this service highly available. In this configuration, passwords never leave the on-premises Active Directory.  When someone attempts to sign-in to the Azure AD application, there is a configuration bit in the tenant that says “I’m not in charge of authentication, I have to go check in with <insert corporate AD FS web address here>.” This is super cool for security and compliance, because all authentication attempts are still logged against the local Active Directory.

But it is super uncool for many small businesses, because it requires setup and installation of AD FS, which also means that the cloud-based applications are dependent on the local Active Directory. So, if the corporate internet connection is down, so is your email. Wait a minute… why did we move our email to the cloud again? To prevent this scenario, our design would need to include:

  1. Properly configured AD FS infrastructure with SSL Certificates
  2. At least 2x AD FS web servers on separate links/ISP’s for HA
  3. Planned recovery from total loss of this site/infrastructure

Not a popular option for these reasons (complexity + dependency).

There are a couple of other considerations that might come into play. Most notably, the only solution here that supports the on-premises Multifactor Authentication Server is (unfortunately) AD FS. It is still possible to enable MFA for cloud-based applications using Azure AD MFA provider with the other options, but you do not have the ability to bring MFA to your network locally, without AD FS. Just something to be aware of.  On the flip side, it is worth noting that Azure Identity Protection (which requires additional licensing, e.g. P2) is not compatible with AD FS (because the authentication attempts must happen against Azure AD for Azure ID Protection reports to work).

Another consideration that applies only to PHS w/ SSO enabled: there may be a delay between, for example, disabling an account on-premises, and having that change updated in the cloud (because AAD Connect only synchronizes every 30 minutes by default). Furthermore, users who have passwords synchronized to Azure AD will technically have their cloud passwords set to never expire, and the password policies that apply on-premises will control when they need to update their password–but it is enforced on-premises only. Therefore it is possible, for example, to sign-in to cloud-based resources, even if the password on-premises has expired, because until the user changes the on-premises password, the old value will not be overwritten in the cloud.

There may be other small differences, but these are the noticeable ones that matter most to small businesses. I have summarized all of these points into this table for ease of reference:

Error: Remote Server returned ‘550 5.2.11 RESOLVER.RST.SendSizeLimit.Sender; message too large for this sender’

Please check the message send/receive limit. You are sending message which is larger than the allowed limit.

Change message size limit using powershell.

How to Change maximum Office 365 attachment size with PowerShell

Change message size limit using admin center.

How To Change Office 365 Message Size Limit Using Web Console

 

Error: Your message wasn’t delivered to anyone because it’s too large.

Please check the message send/receive limit. You are sending message which is larger than the allowed limit.

Change message size limit using powershell.

How to Change maximum Office 365 attachment size with PowerShell

Change message size limit using admin center.

How To Change Office 365 Message Size Limit Using Web Console

 

How To Change Office 365 Message Size Limit Using Web Console

Change Office 365 Message Limit for one mailbox

Step 1. Open Exchange Admin

Once logged in to your Office 365 portal click on Admin on then left menu bar and then Exchange to open the Exchange Admin

Step 2. Open the Recipients Mailbox Properties

Click on Recipients in the left side bar, click on the Individual Mailbox and then click on the edit icon.

Step 3. Change the Message Size Limit

Click on Mailbox Features and then scroll down to Message Size Restrictions.  Click on View details

Step 4. Change the Maximum Message Size

Change the Maximum Message size up to a maximum of 150000KB for Sent and Received message

Office-365-Maximum-Message-Size-Limit

Change Office 365 Message Limit for All New Accounts

Step 1. Open Exchange Admin

Once logged in to your Office 365 portal click on Admin on then left menu bar and then Exchange to open the Exchange Admin

Step 2. Change the Default Message Size Limit

In the mailbox view click on the … and then click on Set Default Message Size Restrictions.

Office-365-Set-Default-Message-Size-Restrictions