AD finduser project

Hi there.
I was just working on a project where we had to find user information by searching for SMTP address, or username, or GUID.
So instead of adding a paramter for everything I thought the script can find out itself if I have provided an SMTP address or an GUID. And if you work with Office 365/Azure AD you might have already received notifications about certain user accounts from MS and they provide the GUID, or here called Immutable, in a different format.

So the outcome of my thinking and lazyeness providing parameters all the time can now be found on CodePlex (https://adfinduser.codeplex.com/).

Examples:
finduser.ps1 userA
finduser.ps1 user.A@domain.com
finduser.ps1 5Gz/Z7McHEWGzHdUTs5Kuw==
finduser.ps1 67ff6ce4-1cb3-451c-86cc-77544ece4abb
finduser.ps1 "{67ff6ce4-1cb3-451c-86cc-77544ece4abb}"

The script can work with remote Active Directories as well as with AD LDS servers, just see the 2 lines you have to activate or to deactivate.

Feel free to use it and to adapt. You can also add some more error handling if you like.

Microsoft Azure AD Sync - Push sync and change execution schedule

Microsoft Azure Active Directory Sync Services

If you have worked before with DirSync for Office 365 and your are now switching to Azure AD Sync you might have noticed that the Start-OnlineCoexistenceSync command is gone.

Instead of you can executed this command

C:\Program Files\Microsoft Azure AD Sync\Bin\DirectorySyncClientCmd.exe


or you into the Task Scheduler and run the task from there. 


The Microsoft Azure Active Directory Sync Services tool can be downloaded from
http://www.microsoft.com/en-us/download/details.aspx?id=44225

Happy Syncing!

Message: This account can't be used to access Outlook.com

Today I ran into an issue accessing the Office 365 Outlook Web Access.

First of all, I made the Office 365 setup for a new tenant. The school of my kids decided to test Office 365, right now they are on Google and they want teach the kids more then one cloud application.

For ADFS we already have a Windows Server 2012. So ADFS works great but the MSOL powershell commands are not working with 2012. But only this server has a public certificate, and the URL is used for other services as well. So I just added ADFS 2.0 to another server, moved the signing cert over and started the MSOL powershell commands. Then I just played copycat to get the relying party settings over to the 2012 ADFS server. After ADFS done I installed and ran DirSync. To verify my doing I went to http://outlook.com/domain.org and after ADFS authentication: BUMMER!

"This account can't be used to access Outlook.com"

So I did some web search, but nothing really helpful came up.
So I compared the relying party settings between the ADFS 2.0 server and the 2012 server and found that I missed to configure the hash algorithm to SHA-1. If it is SHA256 you will see the message above.

I suppose this is only one reason when you see that message because the message is kind of generic.

Office 365: Rich coexistence failure because DirSync cannot write back to local AD

DirSync makes it very easy to populate all user account etc from the internal AD to Office 365. Error during exporting and syncing user data are reported via emails, so you can follow up on that.
For rich coexistence DirSync writes certain attributes back to AD, e.g proxyaaddresses.
Errors are not reported and you have to find them in the DirSync's "unofficial" UI.

If you see there "Insufficient access rights to perform the operation.” then the user MSOL_AD_SYNC does not have permissions to write those attributes.
This can happen because you assigned permissions on the user level and you have disabled the "include inheritable permissions from this object's parent" option.

From there you have two options; enable the option to use inheritance or add the permissions manually to each account.

Office 365: Off-boarding a mailbox

On-boarding a mailbox to Office 365 is a quite simple to do with the Exchange Management Console. But how to off board a mailbox. So you might ask why should I do that, well just to be prepared, just in case you have to.

First create a powershell session to O365:
$cred365= Get-Credential
$CloudSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $cred365 -Authentication Basic -AllowRedirection -WarningAction SilentlyContinue
Import-PSSession $CloudSession -Prefix 365

Now run the move request:
New-365MoveRequest -Outbound -Identity 'user@domain.com' -RemoteHostName mail.domain.com -TargetDeliveryDomain domain.com -RemoteCredential $credOnP -RemoteTargetDatabase 'Mailbox Database 041637xxxx'


Afterwards you can find the new move request in EMC under your Office 365 tenant in "Move requests".

Office 365 DirSync 64bit based on FIM 2010

Office 365 for 64bit servers (2008 and 2008 R2) is here.

http://community.office365.com/en-us/w/sso/555.aspx


Still best practice is to have at least one of those servers for a setup with federated identities and Exchange rich-coexistence:
- ADFS server (plus ADFS proxy oder TMG or similar)
- DirSync server
- Exchange 2010 Hybrid server

btw: If you try to install DirSync 64bit on a Windows 2008 R2 DC you will see this message.

And it has still the same "scary" error about MSOLCoExistence registry key. Run the config wizard with elevated rights.

Error: Access to the registry key 'HKEY_LOCAL_MACHINE\Software\Microsoft\MSOLCoExistence' is denied.

Office 365 password change for webmail-only remote users

Recently a question came across my mind about password change for remote users if they are only use OWA.
So might they work from home with their personal computer. A password change is then not enforced and a password change via CTRL-ALT-DEL will not change the AD password.

In a setup with federated identities those users will still see a URL for password change in OWA, but they cant access it. And of course they do not have a password on O365 at all (may a very long random password as we know it from Smart Card only users).   So my idea was to search for a option to define a alternative URL, but no luck. MS Online confirmed that there is no option today to define such an URL.

Okay, so what. Let's go and a grab the IISADMPWD from Windows 2003 IIS and tell the user the new URL to change the password.I would like to have them changed their password every 43 days (or whatever) . IISADMPWD works, even it is not supported anymore, also with IIS 7. But I found one catch. If you are using a ADFS proxy server, which is usually not a domain member and located highly protected in a DMZ, then IISADMPWD cannot be used to change the AD passwords.
So might I can extend IISADMPWD with an web service running on the ADFS server. Lets see if I get this done before end of this year.

Office 365 limits - Exchange online vs Exchange on-premise

I like Office 365 and I encourage every organization to at least consider it seriously.
So none of my points is against Office 365 but I think a few things should be known. All is public information, but hard to get a comprehensive view.
I know that I am limited: in time, in money, in material, in knowledge, get allowance, etc. pp.
So your on-premise Exchange setup has limits to, mailbox size, size of an email, size of attachments, number of recipients in one email and so on. Some are set by an administrator, others are predefined or are technical limitations. And your smart users have probably already figured out how to work around. :-)

Notes:
- Cloud services features and available resources are changing frequently. So take that list as an start point, but not as a final and complete list.
- And by the nature of cloud services you give up (good or not) a lot of your administrative burden and permissions.
- And some limitations are less important if you still have a on-premise Exchange, e.g. for fax gateway integration, Blackberry BES
- Before you start a pilot or start the migration take some time to write up a service description of your on-premise messaging environment with all the different views: end-user, mobile end-user, administrators, auditors, change management
- All information is in regards to Office 365 E plans (http://www.microsoft.com/en-us/office365/buy-midsize-enterprise.aspx?WT.z_O365_ca=Buy_how-to-get_en-us#fbid=9hDlNaUhDNH)


Features:
- No public folders available and cloud users do not have access to on-premise public folders
- No delegation access between cloud users and on-premise users
- No S/MIME support in OWA, even not you install the SMIME ActiveX control manually
- S/MIME certificates are not synchronized to O365 via Dirsync, OL GAL export works but is a unmanaged and end-user driven tasks
- Access to O365 Exchange is over HTTP RPC and web services, if you have a MAPI only application that will not work with O365
- OWA 2003 cannot access free/busy information from cloud users
- ActiveSync does not support certificate based authentication
- Exchange 2003 organization must be in native mode, not in mixed mode for Hybrid server setup


Exchange related:
- More network bandwidth for Internet access
- Groups with over 15.000 members not sync
- Dynamic groups ignored
- 25 GB storage limit for each mailbox, wit E Plan 2 users can store more data in personal archive
- You cannot move mail box items larger than 25 MB to O365.

- Inbox folder: 20,000 items
- Sent Items folder: 20,000 items
- Deleted Items folder: 20,000 items
- Calendar: 5,000 items
- Contacts: 5,000 items
- Message limit 25 MB (OWA 10MB)
- Size of a single mailbox item ??

Lync related:
- Lync Online does not work with room-based conferencing systems
- must have a different SIP domain (real coexistence is not available)


SharePoint related:
- 20.000 user limit (hope to see that increased soon)
- no federation search




Find more at
http://community.office365.com/en-us/f/183/p/1541/5095.aspx
http://www.microsoft.com/download/en/details.aspx?id=13602

Office 365 magic auto logon to webmail

The standard way to logon to Office 365 Outlook (webmail) is via https://login.microsoftonline.com. Than you type the username (MS Online ID) and if you are configured with a federated identity the password field will grayed out and you will see another "button" to proceed to login via your ADFS server logon, where you might have to type the same username again. Technically nothing wrong with that, I just think it is to complicated for users to do this all the time.

So first I was thinking to write a webpage what is using integrated or basic authentication for user authentication and performs then a look up in Active Directory to get the UPN and etc. Create the login URL including the MS Online ID . STOP. Way to complex thinking. At the end I analyzed a bookmark to O365 webmail and voila after I few modifications and shortening

I came up with

https://www.outlook.com/owa/?exsvurl=1%24&delegatedOrg=ServiceDomain&ll-cc=en-US&realm=FedDomain

ServiceDomain is e.g. cryptolive.onmicrosoft.com

FedDomain is e.g. crypto-live.org

Now you can create a desktop shortcut or a start menu entry or add it as a link on a portal or add this via GPO to all your users favorite bookmarks or ....

[Update: Even much easier to just access https://outlook.com/crypto-live.org]