One of my clients mentioned that he follows people in the newsfeed who weren’t employed any more.
Occasionally we disable the this kind of users in the Active Directory but don’t delete them.
It seems that DirSync doesn’t filter disabled accounts.
As part of the user provisioning process in my company every user account gets an Office 365 license.
2 days ago in the after noon I’ve created an new user account, synced it with DirSync and applied an new Office 365 E1 license.
When I’ve tried access the SharePoint Online website via ADFS SSO, I received an error message like this:
For those who couldn’t attend SharePoint Conference 2014 including me, the guy from Absolute SharePoint Blog has published a script to download all slides and videos of the presentations at SPC2014.
It could happen that the directory sync service (DirSync) doesn’t sync the users UserPrincipalName correctly.
I had an issue where the UserPrincipalName from a user in the Office 365 windows azure directory has been made based on the user’s sAMAccountname. This wouldn’t be problem if as long the sAMAccountname is the as same as the UserPrincipalName, but as you can guess this is not everywhere the case.
When deploying a published SharePoint 2013 on-premise installation or a Office 365 installation or a SharePoint Online installation, it’s highly recommended to update your Microsoft Office 2013 installation.
The purpose of this article is to show the intention and implemention of the most common modifications for the ADFS login page.
Out of the box the login form should look like this:
The f.e. is by default the page url, this can confuse the user, due they expect something like “your login” or “Office365 Login”.
In addition to my last script showing how to manage the user licenses in Office365 I’ve written a new script for assign, remove or replace the access rights in the office365 portal.
The script has the same structure as the license management script, feel free as always to copy and alter this script or asking me questions about it.
This is part two of my experience in handling the password change office365 architecture issue.
Last time I’ve built a simple script to notificate the users about the status of their passwords. In the mean time we (me and another employ of the “vbl Informatik”) built a simple website for the office365 users to change their password.
Today I experienced an exotic behaviour, a client couldn’t access his Office365 page due he wasn’t able to login on the ADFS authentication prompt.
After googling and binging (just kidding, NERD) I found a simple solution.
To alter the Exchange owa policies you can access them Using the Office365 administration site and navigate to the Exchange section. In the default policy editor are only limited options available.