Latest Posts

Important information about your Office 365 single sign-on deployment

No comments:
“Dear Administrator,

In order to provide your organization with uninterrupted access to Office 365 and Microsoft Azure Active Directory (Azure AD), you need to ensure your certificate for the domain(s) mydomain.com is renewed and updated in Azure AD right away.”


This alert may raise a few hair strands if you are new to ADFS, or just seeing the alert for the first time. You are indeed receiving this alert because Microsoft was not able to automatically check for updates on your ADFS token signing certificates in, hence unable to update them in Azure AD. There are other possible reasons like AD FS server’s federation metadata is not published externally, or simply because are using a 3rd party STS. I’ll focus this article only for ADFS scenarios. 


If you’ve received such alert from MSFT about a possible incorrect configuration of your ADFS for one or more federated domains. To ensure your users keep enjoying the office 365 services uninterruptedly, you should check the following from your Primary ADFS Server.


1. ADFS Certificates

ADFS certificates can be checked from the ADFS Management Snap-in, or PowerShell (get-adfscertificate). Please check the following to confirm that the certificates are valid and can be automatically updated before expiry. All ADFS certificates should be currently valid i.e. Not Expired. 

Service Communication certificates:

Service Communication certificates need to be replaced manually. I'll write another article for the steps.




















Token signing and decrypting certificates

For these certificates, the AD FS property AutoCertificateRollover should be set True. This ensures AD FS will automatically generate new token signing and token decryption certificates before the old ones expire. Token Decrypting and Token signing certificates are self-signed. New certificates are generated before the expiry of current ones if you turn AutoCertRollover True in your ADFS Properties. Newly generated certificates are first set secondary before they are automatically promoted to primary certificates, 5 days before the expiry of old certificates.  

Get-AdfsProperties | select *Cert*

Administrator: Windows Azure Active Directory Module for Windows PowerSheII 
utoCertificateR0110ver 
ertificateDuration 
ertificateGenerationThresh01d 
ertificatePromotionThresh01d 
ertificateR0110verInterva1 
urn : oasis: names : SAML : 2.8: ac:classes: TLSClient, 
urn :oasis: names :SAML : 2.8: ac:classes :XSB9... } 
. True 
365 
. 728


To save yourself from dealing with a possible ADFS Certificate related alert in the M365 admin centre, you should change the "CertificateGenerationThreshold" is set to more than 30, for example, 35. 

Set-AdfsProperties -CertificateGenerationThreshold 35


2. ADFS Federation Metadata

The AD FS federation metadata should be accessible publicly. This helps Microsoft alert (or not raise a false alarm) about token signing or decrypting certificates due for expiry. Check that your federation metadata is publicly accessible by navigating to the following URL from a computer on the public internet (off of the corporate network):
https://(your_FS_name)/federationmetadata/2007-06/federationmetadata.xml where (your_FS_name) is replaced with the federation service hostname your organization uses. 




If the metadata is publicly accessible, from home office or 3G/4G hotspots, the page will look like below.  If the page does not load, check for network connections being blocked on your firewall.



Read More

Un-Federating a domain in Office 365

No comments:
Usually, un-federating a domain is pretty straight forward. You run the Convert-MSolDomainToStandard cmdlet from PowerShell Console on the ADFS Server. However, there may be situations when you can't access into the ADFS server, and you get a similar error  -

Convert-MsolDomainToStandard -DomainName vermasandeep.in -PasswordFile C:\Temp_Password_File.CSV -SkipUserConversion $False 


What to do now? How to unfederate the domain without fixing the ADFS issue first?

If you know ADFS Server is completely down or inaccessible for any reason, you can still convert the domain to 'standard' use below steps -

You can use the following cmdlet to convert the domain to 'managed'. This can come handy when you want to remove a domain from Microsoft 365 (formerly Office 365) tenant as soon as possible.

Set-MsolDomainAuthentication -DomainName –Authentication Managed


Step 1: Connect to Microsoft 365 / MSOL Service using PowerShell

connect-msolservice


Step 2: Verify the domain's current authentication method

get-msoldomain -DomainName vermasandeep.in


Step 3: Convert the Domain's method to 'Managed'

Set-MsolDomainAuthentication -DomainName vermasandeep.in –Authentication Managed


Step 3: Verify the domain's new authentication method

get-msoldomain -DomainName vermasandeep.in

Simple!

Read More

Azure AD Connect On-Demand Sync

No comments:

If you've just installed Azure AD Connect or upgraded from a different directory sync engine like FIM, MIM or even the ancient DirSync, one of the first things you realize as an admin is that the sync engine is MUCH faster and consistent than the previous versions. Most of the time, the changes sync automatically without you having to do any manual override. However, there still may be some cases when you'd like to force a directory synchronization cycle IMMEDIATELY. How do you do it in the Azure AD connect? The PowerShell cmdlets you used earlier have changed. Welcome to the new world. 
If you use AAD Connect Server, here's how you can use a forced synchronization - 

To initiate a Delta Sync, open Windows PowerShell and run:
Start-ADSyncSyncCycle -PolicyType Delta

To initiate a Full Sync, open Windows PowerShell and run:
Start-ADSyncSyncCycle -PolicyType Initial

If the commands are not available, try to load up the below PowerShell module:
Import-Module "C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync\ADSync.psd1"
Read More

Get Computer name using PowerShell

No comments:
How to find your computer's host-name? What users are you logged in as? Sometimes this information is what you need when you are invited to troubleshoot an issue. How to find basic information about your computer in a handy way? Use PowerShell!

How to find your computer's hostname in 3 easy ways?

# Checking current computer name using PowerShell
Hostname

OR

$env:computername

OR

gwmi win32_computersystem


Bonus! 
How to change a computer name using PowerShell?

# Rename a computer -
$(gwmi win32_computersystem).Rename("NewCompName")

This one would need:
1) Local Admin Credential
2) Domain controllers must be available

Some more tips available here -  like Adding a computer to the domain using PowerShell.
Powershell is cool, huh!


Read More

Export a list of all users in Office 365

No comments:
Some time ago, someone asked me how to export user information from office 365. My answer was simple he could export the user details (technically, mailbox details) from the Exchange Admin Center (that ellipse icon on the toolbar), or use PowerShell.



While the GUI method is all easy and fine, it is quite a limited in functionality. The GUI will not let you export all the information you may want. For example, exporting proxy addresses, or exporting the guest accounts. In these scenarios, you'll need to use Windows PowerShell. The command you can use can look something like below -

# Export Office 365 use data (MSOLUSER)

# Connect to MSOL Service. You will be prompted to enter an office 365 admin username and password.
Connect-msolservice
# Get a list of ALL users 
$MSOL_users = Get-msoluser -All | Select-Object DisplayName,FirstName,LastName,Password,PreferredLanguage,UsageLocation,UserPrincipalName,UserType, @{L = "ProxyAddresses"; E = { $_.ProxyAddresses -join ";"}} 
# Export the results to a CSV file!
$MSOL_users | Export-Csv -Path C:\Temp\MSOL_Users.csv -NoTypeInformation

Bingo! Yes, it is that simple.

If you have never used PowerShell to connect to Office 365,  you'll need to do a one-time setup of configuring PowerShell to work with office 365. You can see the instructions here.
Read More

Compare office 365 plans - Office 365 E1 Vs E3

No comments:



You'd think Microsft already must have published the differences between all their subscriptions clearly, but at the time of writing this article, it hasn't. Period. At least there aren't many resources which clearly tell what's the difference!
So, as simple as it may sound, it's not that easy to find a reliable comparison of Office 365 E1 plan Vs Office 365 E3. A log of people want to save on licensing cost by replacing some E3 licenses with E1 but they do not know what features will they miss while doing that. So, I decided to write this article. Hopefully, you will find it helpful.

E3 gives you a bigger mailbox, unlimited archive, litigation hold, unlimited OneDrive etc. It has some other features too which are not available in E1 mentioned below. For E3 users using Office ProPlus today, you can apply S1 (i.e. E3 + ProPlus). This will put some limits on the mailbox, OneDrive etc. based on the E1 plan and remove access to E3-only features which are not available in E1.

Feature
E1
E3
Flow for Office 365
Yes
Yes
Microsoft Planner
Yes
Yes
Microsoft StaffHub
Yes
Yes
Microsoft Teams
Yes
Yes
Office Mobile Apps for Office 365
Yes
Yes
Office Online
Yes
Yes
PowerApps for Office 365
Yes
Yes
Skype for Business Online (Plan 2)
Yes
Yes
Stream for Office 365
Yes
Yes
Sway
Yes
Yes
Yammer Enterprise
Yes
Yes
Exchange Online
  Plan 1: 100 GB mailbox + Archive combined
  Plan 2: 100 GB mailbox + Unlimited Archive
Plan 1
Plan 2
Microsoft Forms
Plan 1
Plan 3
SharePoint Online
  Plan 1: 1TB OneDrive Storage
  Plan 2: Unlimited OneDrive Storage, DLP, In-place Hold
Plan 1
Plan 2
To-Do
Plan 1
Plan 2
Azure Rights Management
-
Yes
Office 365 ProPlus
-
Yes
Data Loss Prevention
-
Yes
Litigation Hold
-
Yes
eDiscovery, Content Search
-
Yes


So, that's it. Now go ahead, swap those licenses. If you need some automation on it, I will soon post a script. Keep checking this space. :)
Read More

Federate a domain in Office 365 | Setting up Single Sign On

No comments:

Image result for single sign on office 365

When you setup ADFS for your domain, you can use Single-Sign-On (SSO) for user authentication. It lets your users access corporate applications/resources like Office 365 with his/her network credentials. If they are using domain-joined computer, they sign-in automatically without having to provide user credentials at all. This magic happens after you federate the domain with Azure AD or Office 365. To do so, follow the below steps.
Prerequisites - You'd need Azure AD Module for PowerShell installed on your primary ADFS server. You will need to provide Global Admin account's username and password when prompted for credential.
Go to your Primary ADFS Server and connect to your Azure AD Tenant.
  1. On the Primary ADFS server, open an Administrator PowerShell window and import the MSOnline module
Import-Module MSOnline
  1. Connect to your Azure AD Tenant
Connect-MSOLService
Sign in with a Global Admin account in the credential pop-up

  1. Once you are connected to your Azure AD Tenant, let’s make sure your domain is currently recognized as a “Managed” domain.
Get-MsolDomain -Domainname

      4. Run the command to convert your domain.
Convert-MsolDomainToFederated -DomainName <domain.com> -SupportMultipleDomain

     5. Run the following PowerShell cmdlet to confirm the domain is converted:

If you see the Authentication is set to Federated, you should start observing Single-Sign-On in a few minutes. When you sign in to Office 365, it’ll start redirecting you to your ADFS sign-on page.

Read More

Letting group owners manage synchronized DLs in single tenant multi exchange hybrid office 365 scenarios

No comments:
In single tenant multi-exchange hybrid environments, Office 365 design can make the synchronized groups non-editable by the groups 'owners' via Outlook, especially if you are not writing back attributes to local ADs. In such environments, after migrating a user to Exchange Online, group membership administration job fall on the IT Teams' (Wintel/AD/Exchange/O365 etc.) shoulders. It is not only inconvenient for the group owner who struggling to manage his 'own' groups, it becomes a BIG headache for the IT teams. It is one of those which have a potential to increase the IT helpdesk tickets quite significantly. Losing control over their groups frustrates the group managers, which now have to depend on someone else to manage their groups after migrating to the cloud. They may even associate it with overall office 365 migration experience, not for the good reason. The problem exists only for the synchronized DLs. The fix is out of your hands, the problem is mostly rectifiable.

What can you do in such situations? You want to delegate the group management to their owners but definitely don't want to give them any admin rights into Exchange. Below have couple suggestions, none of them are ideal. Each has its own merits and demerits:

1. Convert all groups to cloud-based groups. [Not Recommended]
2. Dedicate a resource to do in on the owner's behalf. [Better then cloud-based option]
3. Have group owners edit the memberships directly in the AD. - DSQuery
%systemroot%\system32\rundll32.exe dsquery.dll,OpenQueryWindow [Better than other two options, Recommended]

Cloud-based groups

Cloud accounts do not have this problem. Converting some groups to 'cloud only' complicates the environment because you can no longer keep AD as the source of group creation and management (remember, we are talking no write-back scenario). If you use some groups for more than just Exchange, e.g. for delegating special permissions in the local domain, you'll have a tough time keeping the two copies consistent (one on-prem and other in the cloud) now that cloud ones need to be updated manually or via a script.

Dedicate a resource

Dedicate a team of resources to manage groups on the owner's behalf. It is not ideal but still better than managing cloud-based groups. It needs user education and awareness and they have to rely on the resource team for making changes. Some organizations will add this additional work of managing groups on the existing teams.

Using DSQuery

DSquery is a built-in command line tool for Active Directory. It was introduced with Windows Server 2003 but is still available in modern Windows computers & servers. If you want to find a user quickly in a local AD domain from the command prompt, you can use this utility on any domain-joined PC even as a normal user. Of course, you can't change anything unless you have got some permissions assigned to your account. But hey, the group managers do have permissions over their groups, right? hell yes!

Using this utility, you can have the group owners edit the memberships directly in the AD, which will sync up to Azure AD / O365 on the next AAD connect synchronization cycle.

The utility is fairly easy to use even by a non-IT person. Just enter the string I mention below in the "RUN" cmd (Windows + R) or Command Prompt. Admins can save a .bat file for the group managers on their Desktop to help them access this easily. 

How to access it? Just open Run Command window, Enter the string below and press Enter
%systemroot%\system32\rundll32.exe dsquery.dll,OpenQueryWindow


Viola!

Caveat: The DSQuery utility will work only when the manager is in the corporate domain, or when connected to it via VPN/Direct Access.



I understand all the options are only workarounds only some of you may already be aware of them. 
Read More

Avoid email delivery delays. Update your Office 365 MX Records| 451 4.4.62 Mail sent to the wrong Office 365 region. ATTR35

No comments:

Image result for mx records Exchange online

Microsoft is putting constraints on the MX record and smart host requirements Office 365. It only supports an MX record in the format "YourSmtpDomain-com.mail.protection.outlook.com." (notice mail.protection.Outlook.com!). It does NOT support any other, legacy entries for example, mail.messaging.microsoft.com. (notice Microsoft.com)

Office 365 assigns an MX DNS record to each domain. This MX record is unique and helps you route mail to the region and datacentre in which the tenant is located. Older DNS formats such as mail.eo.outlook.com, mail.messaging.microsoft.com, and mail.global.frontbridge.com are no longer supported. If you are pointing your MX records to these deprecated DNS entries, you need to make changes to your public DNS (MX Records). Failure in doing so by 25th May, 2018 will result in and deferred delivery of email.

If mail your email is deferred for this reason, you receive the following error message:  451 4.4.62 Mail sent to the wrong Office 365 region. ATTR35.

Check if you are affected

A ) If you have configured your mail routing directly through EOP \ Office 365, i.e. you use the DNS records that point to Office 365 in your MX record:
  • For each of your SMTP domains, including sub-domains, check your published MX record to verify that it matches the record that Office 365 assigned only (like *. mail.protection.outlook.com ). The ‘*’ looks similar to your smtp domain. You can use NSLOOKUPResolve-DNSName, or third-party tools such as Mxtoolbox.com. 
  • We recommend that you have only a single MX record pointing to EOP. In some cases. However, Office 365 already has extreme redundancy at every level, and multiple MX records can actually make mail delivery less reliable in this case.  

B) If you use Exchange in your on-premises environment, verify that the smart host value in the Send connector that routes mail to Office 365 does NOT use mail.messaging.microsoft.com, mail.global.frontbridge.com, or an Office 365 IP address.

C) If you use another provider for spam filtering or you have configured any mail routing through use of a "smart host" that is sending mail to Office 365 directly and not through your MX record, check the following:
  • You should check any services that route mail directly to your Office 365 tenant. For example, if you use a third-party filtering service, you should sign in to that service and verify the routing destination that is provided to the service, which is known as a "smart host." 
  • You should also check any email-generating applicationsservers, or devices that are under your control that route mail directly to Office 365 or that "SMTP-relay" through Office 365 as unauthenticated mail. For more information, see attached document.
  • For each smart-host configuration or send connector or application SMTP server setting, you must use only the host record that Office 365 assigned to your tenant. i.e. MX record for your domain. E.g. YourSmtpDomain-com.mail.protection.outlook.com.

If your MX record(s) and smart host settings don’t contain incorrect values, then there is no action you need to take.

Read More

Default MDM in Office 365 for the beginners

No comments:
To begin with, there are two types of device management tools available in Office 365 – ‘ActiveSync Mobile Device Mailbox Policies’ and ‘Mobile Device Management in Office 365’. You can use these any of these two methods for out of the box device management. You can also subscribe to Microsoft Intune, which is a great EMM solution available at a premium. But let's keep this conversation focused on ActiveSync and M365 MDM only. We'

Exchange ActiveSync is the same technology which enables mobile phone users to access their email, calendar, contacts, and tasks, and to continue to access this information while they're working offline. ActiveSync Policies works on exchange-based services and are designed to offer protection for EXO content on the mobile device. There is no control over other Office 365 related Content such as OneDrive for business data, Skype for business or even Office mobile which brings along Word, Excel, OneNote and PowerPoint to the small screen. This is where O365 MDM comes to picture. These additional apps are covered under O365 MDM.


What is MDM for Office 365

MDM for Office 365 is a ‘simplified’ version of Microsoft Intune that helps organizations secure and manage their mobile devices used by licensed Office 365 users. Per your wish, we can create MDM policies with settings that can help you control access to the organization’s Office 365 email and documents for supported mobile devices and applications. If a device ever gets lost or stolen, it can be remotely wiped which removes any corporate and organizational information from it.




There are two flavours of device remote wipe. First is Remote Wipe (full remote wipe) which sets the device to factory defaults thereby removing ALL information form it including user’s contacts, pictures etc. Second is Selective Wipe (only available by O365 MDM / Intune) which gives us the liberty to remove just corporate information from it but keeping the user’s personal data intact.  

Why Office 365 MDM over ActiveSync policies?
  • Block uncompliant devices
  • Block Jail-broken or illegally unlocked phones
  • Device Compliance Reports

If you are ready to start piloting O365 MDM for a few users, there will be a few prerequisites:

Prerequisites:
  DNS records:
DNS records should be configured for MDM first. You must create two CNAME Records in public DNS Zone to get started.
           
TYPE
Host Name
Points to
TTL
CNAME
enterpriseregistration.company_domain.com
enterpriseregistration.windows.net
3600
CNAME
enterpriseenrollment.company_domain.com
enterpriseenrollment.manage.microsoft.com
3600

  Security policy:
Every mobile managed device must bear a Device Security policy which identifies the rules that the device has to comply with. You could request a simple device policy which mimics the current ActiveSync Policy or choose something else. For example, we can help prevent data loss if a user loses their device by creating a policy to lock devices after 5 minutes of inactivity and have devices wiped after 3 sign-in failures. These policies can be changed according to requirements at all the time.

  Security groups:
Every user whose device should be protected under a policy will need to be identified as a member of a discrete security group synchronized to office 365.
e.g. Email: MDM@domain.com
Group Name: MDM* (any name)

Ready to pilot? 
Once you have got the domains DNS updated, and Security group synced to Office 365, device security policies can be attached to it. See Security Policy options in Appendix A.

IMPORTANT:
         Just like ActiveSync policies, NOT ALL mobile platforms support all features of device security policies equally. You can find what’s covered per mobile OS here.
         The users you select as MDM security group members may lose access to services and device shall be forced into the Device Enrollment process. Access to data is restored once a device is enrolled. Explained here.  
         Policies and access rules created in MDM for Office 365 will override any Exchange ActiveSync mobile device mailbox policies and device access rules for the users. Which means, after a device is enrolled in MDM for Office 365, any Exchange ActiveSync mobile device mailbox policy or device access rule applied to the device will be ignored.

Appendix A


Device Security Policy Selection:
  Require a password
  Prevent simple passwords
  Require an alphanumeric password:
  Password must include at least 
  character sets
  Minimum password length:
  Number of sign-in failures before the device is wiped:
  Lock devices if they are inactive for this many minutes:
  Password expiration:
  Remember password history and prevent reuse:
  Store up to how many previous passwords:
  Require data encryption on devices:
  Prevent jailbroken or rooted devices from connecting
  Require managing email profile (required for selective wipe on iOS)
  If a device doesn't meet the requirements above, then...
  Allow access and report violation
  Block access and report violation
  Require encrypted backup
  Block cloud backup
  Block document synchronization
  Block photo synchronization
  Block screen capture
  Block video conferences on device
  Block sending diagnostic data from devices
  Block access to the application store
  Require a password when accessing the application store
  Block connection with removable storage
  Block Bluetooth connection

Appendix B


MDM Device Security Options in Office 365

Setting Name
Windows Phone 8.1+
IOS 7.1+
Android 4+
Require a password
Prevent simple password
Require an alphanumeric password
Minimum password length
Number of sign-in failures before device is wiped
Minutes of inactivity before device is locked
Password expiration (days)
Remember password history and prevent reuse
Require data encryption on devices
Encrypted by default
Device cannot be jail broken or rooted
Email profile is managed
Require encrypted backup
Block cloud backup
Block document synchronization
Block photo synchronization
Block screen capture
(Samsung Knox only)
Block sending diagnostic data from device
Block video conferences on device
Block access to application store
Require password when accessing application store
Block connection with removable storage
Block Bluetooth connection
CameraEnabled
RegionRatings
MoviesRatings
TVShowsRating
AppsRatings
AllowVoiceDialing
AllowVoiceAssistant
AllowAssistantWhileLocked
AllowPassbookWhileLocked
MaxPasswordGracePeriod
PasswordQuality
SystemSecurityTLS
WLANEnabled



Read More