Symptom: When trying to install the Microsoft Online Services Sign-In Assistant (Windows Azure Active Directory Module for Windows PowerShell) to manage Office 365 or Windows Azure, you receive the following error:
In order to install Windows Azure Active Directory Module for Windows PowerShell, you must have Microsoft Online Services Sign-In Assistant version 7.0 or greater installed on this computer.
Solution: Try installing the latest version of the Microsoft Online SErvices Sign-In Assistant.
If you still receive the error after installing the Sign-In Assistant, make sure you are using the latest installer for the Microsoft Online Services Module for Windows Powershell.
If you still receive the error after trying both installers, try installing the Beta version of the Windows Azure Active Directory Module for Windows PowerShell.
Synopsis: One of the biggest problems I have seen with Office 365 is ease in accessibility to all of the Office365 resources. As pointed out on many of the Microsoft forums, SharePoint, CRM, Skydrive, etc. do not automatically complete a single-sign on request when browsing the website.
Problem: When a user browses https://mydomain.sharepoint.com for example, the user is prompted to enter in their email address. What a user expects is that they should automatically be logged in and see sharepoint when navigating to https://mydomain.sharepoint.com Additionally, for whatever reason, users cannot remember the website address to https://mydomain.sharepoint.com Instead, they want to do something like http://sharepoint.mydomain.com
Solution: Create name branded "fancy URLs" that will complete an idp claim to give the user a true SSO experience.
http://owa.mydomain.com
http://sharepoint.mydomain.com
http://skydrive.mydomain.com
http://crm.mydomain.com
Solution:
Open up Internet Explorer
Navigate to https://mydomain.sharepoint.com
Press F12 to open up the developer tools console (I am running IE 11, the console looks way different than previous versions of IE)
Scroll down and select the icon that looks like a little WiFi antenna
Click the green play button
Type in your email address as you would to login to sharepoint ([email protected])
You should be redirected to your ADFS server and inside the network console, you should see a link like https://sts.mydomain.com/adfs/ls/?.................. Copy this link into notepad.
Remove the extra stuff from the debug console Before After
Remove everything from cbcxt=..... to wa=wsignin1.0
Remove the ct%3D1386214464%26 and bk%3D1386214464%26 parameters
Next, open up another new notepad document named index.html and paste the following text into it
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><title>CRM</title>
<meta http-equiv="refresh" content="0; url=https://sts.mydomain.com link goes here" /></head>
<body>
</body>
</html>
Replace https://sts.mydomain.com link goes here with your new smart link and save the document.
Upload the index.html file to one of your your webservers
Create a new A record called sharepoint.mydomain.com pointing to your webserver
Now when a user browses http://sharepoint.mydomain.com, the user will automatically be redirected to your secure ADFS Proxy and authenticate automatically.
You will need to repeat the steps above for each of the Office 365 products your company uses. The federated addresses do change, so you will have to follow all of the steps over again for each Smart Link you wish to create.
If you are on the enterprise plans of Office 365 (E4 for example), your users may be eligible to use Microsoft's enterprise social network called Yammer. This article will cover a few questions I was curious about when rolling out Yammer as well as what to expect.
If you are eligible for the Yammer service, click on the Yes, activate Yammer Enterprise for my network
Click on the Activate Yammer Enterprise button
You will be redirected to a screen where you see a loading bar. Grab a can of pop/coffee/tea/water and come back.
Click on the Create Yammer Account link once Yammer Enterprise has been provisioned.
Type in the same email address you use for your Office 365 Admin credentials
If successful, you should see the screen below:
Check your email and click on the Complete Signup button
Type in your information and click the Next button
Click Next on the who do you work with page, or spam your colleagues to sign up as well.
Join or create any groups you would like and then click Next
Optionally, add a profile picture and click Save & Continue
Click on the 3 dots in the top right corner and select Network Admin
Welcome to your Yammer Enterprise Admin portal! Here you can manage all aspects of Yammer for your organization.
Lastly, if you go back to your Office 365 Admin portal, you should see a link that will redirect you to the Yammer.com website.
FAQ
Does Yammer support single-sign on or ADFS?
Currently, Yammer does not support this integration at this time.
Will Yammer find users previously signed up with email addresses from @mydomain.com?
Yes
Does Microsoft have plans on continuing to integrate Yammer and Office 365?
Yes, Microsoft has announced they would like deeper integration with Office 365, more specifically with functionality in SharePoint. Quarter 4 of this year (2013) was their deadline for the first integration, and we have seen they have started to deliver. However, there are no specific dates yet of when users will be 100% synchronized between the two systems.
When I activate Yammer on Office 365 for my organization will it email all of my users to create profiles?
No, they will have to manually join or you will have to manually send them invites to create a separate Yammer account.
Symptom: After changing the samAccountName (User Principal Name (UPN)) of a user in your on-premise Active Directory environment, run the DirSync tool to update the user on Office 365 (or wait 3 hours) [and have verified the user's new UPN synchronized in the Office 365 admin portal], the user is presented with the following error when trying to sign into Outlook, SharePoint, CRM, etc. on Office 365.
Sorry, but we're having trouble signing you in Please try again in a few minutes. If this doesn't work, you might want to contact your admin and report the following error: 80041034.
Solution: This turns out to be an issue with ADFS (Active Directory Federated Services), caching user account attributes, which prevents a successful login. Here are a couple of solutions to solve this issue:
Try reupdating/repairing party trust with Office 365.
Login to one of your ADFS servers.
Click Start, All Programs, Windows Azure Active Directory, and then select Windows Azure Active Directory Module for Windows PowerShell.
Execute the following command to connect to Microsoft's online services (when prompted, type in your Office 365 Administrator credentials)
Connect-MSOLService
Execute the following command to update federated trust
Try temporarily disabling Local Security Authority (LSA) credential caching on your AD FS servers (note this can increase the load on your ADFS and AD DS servers)
Login to each of your ADFS servers and complete the following steps
Click Start -> Run -> regedit to open up the registry editor
Note: This guide is deprecated. AD RMS is now supersceeded by Azure Information Protection. If you have previously used this guide, review the following guide on Migrating from AD RMS to Azure Information Protection.
Those that have the following tiers of Office 365 are entitled to use Microsoft's AD Rights Management Service to help secure their documents:
SharePoint Online Enterprise (E1),
SharePoint Online Enterprise (E3 & E4),
SharePoint Online Midsized Business
Here is a list of compiled questions I wanted to know when trying AD RMS for Office 365.
What is AD Rights Management Services?
Active Directory Rights Management Services (AD RMS) is an information protection technology that works with AD RMS-enabled applications to help safeguard digital information from unauthorized use. Content owners can define who can open, modify, print, forward, or take other actions with the information. http://technet.microsoft.com/en-us/library/cc771234(v=ws.10).aspx
Are their any examples of using AD Rights Management Services?
Office 365 did a pretty good job covering the concept of using AD RMS as well as how to use AD RMS. You can find the full tutorial here, however their official YouTube video covering this has been embedded below:
How do I deploy or enable AD Rights Management Services for Office 365?
By default, in a pure Office 365 environment, we can get 3 RMS Templates in Windows Azure Rights Management. If we have an on-premises server running Active Directory Rights Management Services (AD RMS), we can get more via import a trusted publishing domain (TPD). So, without on premise server, we just can get default 3 Templates.
I enabled AD RMS for Office 365, but I don't see any options in Office 2010. How do I get Office 2010 to use AD RMS?
Since you are more than likely on the E4 tier, I would highly recommend downloading Office 2013 from your Office 365 portal and installing that. Office 2013 from the Office 365 portal comes preconfigured to work more fluidly with AD RMS. However, if you need to use Office 2010, you can complete the following steps as documented on the following technet article: http://technet.microsoft.com/en-us/library/jj585031.aspx#sectionSection1
Can people outside my organization open protected documents with AD RMS (not apart of my domain)?
Short answer, Yes. Long answer, they are required to create a Microsoft account using their email address (Gmail, AOL, Yahoo, etc) to authenticate themselves. Below are some screenshots of the registration process; I have copied them from the following technet article for archival purposes: http://blogs.technet.com/b/rms/archive/2013/08/29/the-new-microsoft-rms-is-live-in-preview.aspx
How can an Office 365 customer purchase Microsoft Rights Management Services (RMS)?
Active Directory RMS is already included in the Office 365 Enterprise E3, and E4 plans and the Education A3 and A4 plans. RMS is also available as an add-on in the E1 and A2 plans. Consumption of rights-protected content is free. A license is required to protect content.
Today a coworker logged into one of our Office 365 Admin Portals and noticed that the Forefront Online Protection for Exchange (FOPE) link was removed to manage mail flow rules. After searching the entire admin panel, turns out Microsoft removed access to FOPE and has instead integrated a new "mail flow" area to manage the Exchange rules. While this is all good and fine, would have been nice to get an email saying the changes to the portal were going to be done.
Any who, here is where you can now begin to create/edit/delete your mailflow rules (note, all previous rules were automatically migrated from Forefront Online Protection for Exchange (FOPE) to what is now called Exchange Online Protection (EOP).
Login to Office 365 Admin Portal
Click on Admin -> Exchange
Select the mail flow link on the left
On the rules tab, you can now manage all of the mail rules as you would have done in FOPE.
In the picture below, you can see some of the rules that were automatically moved from FOPE over to Microsoft's new system (Migrated FOPE Policy Rule ID: xxxxxx).
Synopsis: Employee leaves on personal matters for a month and their department lead requests for mail to be forwarded to their manager. Typically, mail forwarding would be setup inside of the Exchange console, however, in this case, Exchange is managed by Office 365 (not a hybrid exchange deployment) and the users are being federated to Office 365 via ADFS. When trying to enable mail forwarding, as outlined in the this help document by the Office 365 team http://community.office365.com/en-us/wikis/exchange/how-to-forward-email-in-office-365.aspx, I would receive an error message.
Symptom: When enabling mail forwarding for the user inside of the Office 365 Exchange portal, I received the following error message:
The action 'Set-Mailbox', 'EmailAddresses', can't be performed on the object 'Firstname Lastname' because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.
Solution:
Personally, I think this is a bug in Office 365, but they say it is because we are on premise (if all of exchange is managed by them, how can they not enable mail forwarding?). Any who, the work around is to manage the user's mailbox and set forwarding up as if they would. See the steps below to achieve the same result:
Login to your Office 365 admin portal.
Click on the Admin dropdown and select Exchange
Once in the Exchange portal, click on your username and select Another user...
Type in the mailbox you want to edit and click ok
On the "Managing on behalf of" screen, select Forward your email
Scroll down to forwarding and type in the email address of the user you want all emails to go to and click start forwarding. You can optionally select if you want to leave a copy for the user's mailbox or have them silently forwarded.
This morning I woke up to a nice ADFS issue which prompted Outlook to keep prompting for my credentials and my phone to prevent connectivity to Office 365. Since we are federated and sign-in was not working, I tried logging into Office 365 via the web. When trying to sign in to Office 365's webmail or portal, I was greeted by the following error:
Sorry, but we're having trouble signing you in.
Please try again in a few minutes. If this doesn't work, you might want to contact your admin and report the following error: 80041317.
Additionally, inside of event viewer on my ADFS server (not the proxy), I was seeing the following events:
Event ID: 111
The Federation Service encountered an error while processing the WS-Trust request. Request type: http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue
Additional Data Exception details: System.Security.Cryptography.CryptographicException: MSIS3135: The signature is not valid. The data may have been tampered with. at Microsoft.IdentityServer.Service.Tokens.MSISRsaSignatureCookieTransform.Decode(Byte[] encoded) at Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ApplyTransforms(Byte[] cookie, Boolean outbound) at Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(XmlReader reader, SecurityTokenResolver tokenResolver) at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ReadToken(XmlReader reader) at Microsoft.IdentityModel.Tokens.SecurityTokenElement.ReadSecurityToken(XmlElement securityTokenXml, SecurityTokenHandlerCollection securityTokenHandlers) at Microsoft.IdentityModel.Tokens.SecurityTokenElement.GetSecurityToken() at Microsoft.IdentityServer.Service.SecurityTokenService.MSISSecurityTokenService.GetOnBehalfOfPrincipal(RequestSecurityToken request, IClaimsPrincipal callerPrincipal) at Microsoft.IdentityServer.Service.SecurityTokenService.MSISSecurityTokenService.BeginGetScope(IClaimsPrincipal principal, RequestSecurityToken request, AsyncCallback callback, Object state) at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.BeginIssue(IClaimsPrincipal principal, RequestSecurityToken request, AsyncCallback callback, Object state) at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.DispatchRequestAsyncResult..ctor(DispatchContext dispatchContext, AsyncCallback asyncCallback, Object asyncState) at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.BeginDispatchRequest(DispatchContext dispatchContext, AsyncCallback asyncCallback, Object asyncState) at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.ProcessCoreAsyncResult..ctor(WSTrustServiceContract contract, DispatchContext dispatchContext, MessageVersion messageVersion, WSTrustResponseSerializer responseSerializer, WSTrustSerializationContext serializationContext, AsyncCallback asyncCallback, Object asyncState) at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.BeginProcessCore(Message requestMessage, WSTrustRequestSerializer requestSerializer, WSTrustResponseSerializer responseSerializer, String requestAction, String responseAction, String trustNamespace, AsyncCallback callback, Object state)
Event ID: 184
A token request was received for a relying party identified by the key 'fed.mydomain.com:443/adfs/services/trust/2005/usernamemixed', but the request could not be fulfilled because the key does not identify any known relying party trust. Key: fed.mydomain.com:443/adfs/services/trust/2005/usernamemixed
This request failed.
User Action If this key represents a URI for which a token should be issued, verify that its prefix matches the relying party trust that is configured in the AD FS configuration database.
Event ID: 371
Cannot find certificate to validate message/token signature obtained from claims provider.
User Action Check that Claim Provider Trust configuration is up to date.
After a long conversation with Microsoft, the end result was somehow federation between Microsoft and our ADFS servers was severed. Here is how we fixed it.
Remote desktop to your ADFS server (not the proxy)
Open the Windows Azure Active Directory Module for Windows PowerShell as an administrator
If you are old to ADFS, this was formerly called Microsoft Online Services Module
Execute the following command:
Connect-MsolService
Type in your Office 365 admin credentials. I highly recommend you use a cloud based user called [email protected] in the case you cannot federate.
Execute the following command:
Update-MsolFederatedDomain
Type in the domain name you federate to office 365 (yourcompany.com).
Successfully updated 'yourdomain.com' domain. message when done.
This command will break federation (essentially turn it off) to Office 365. This will not lose your mailboxes, settings, etc.
Execute the following command:
Convert-MsolDomainToFederated
This command will re-establish federation to Office 365
Execute the following command:
Update-MsolFederatedDomain
This command will update URLs or certificate information within AD FS and Office 365.
Note: If you have multiple domain names being federated, please use the following command: Update-MSOLFederatedDomain -DomainName mydomain.com -supportmultipledomain
Next, I restarted my proxy server, reran the ADFS wizard to ensure the proxy could communicate to the primary ADFS server, and waited a minute or so.
At this point, authentication began to work properly again.
As you have probably found out, Microsoft no longer provides a traditional installer for Microsoft Office 2013. Additionally, you also probably know that the installer they do provide sucks down the installation files on each PC via the internet, which takes forever to deploy and install Office in an enterprise environment. That being said, here is the solution on how to deploy Office 2013 in an Enterprise environment! 🙂
Download the Office Deployment Tool for Click-to-Run
Select a folder for it to extract the setup.exe file to
Navigate to the folder you made is step 2.2 via Windows Explorer and edit the configuration.xml file with your favorite text editor (notepad, notepad++, etc.)
Remove any text inside the configuration.xml file and use the following code:
Note: I used the 32-bit client installer instead of the 64-bit build. The reasoning behind this is Microsoft advises to stay on the 32-bit build to ensure compatibility to browser plugins that have not been written for the 64-bit office build.
What this code will do is deploy a 64-bit version of Office 365 Professional Plus, automatically accept the EULA when prompted, and log installation progress to a text file called OfficeSetup.txt to your temporary files folder.
NOTE: If you want to download the 32-bit version of Office 365 Professional Plus, simply change the OfficeClientEdition="64" attribute above to OfficeClientEdition="32"
Save configuration.xml and minimize your text editor, we will come back to this file later.
Next, open up a command prompt and navigate to the folder you made in step 2.2
Now, we will download the necessary files from Microsoft used to deploy Office internally on our network. To do so, execute the following command:
setup.exe /DOWNLOAD
You should now see a folder called "Office" once the files have successfully completed.
Create a network share where these files can be grabbed from during an installation. Once done, open up your text editor with the configuration.xml file.
Add the following attribute to your <Add OfficeClientEdition="64"> line:
SourcePath="\\server\share\Office"
So the entire line should look something like <Add OfficeClientEdition="32" SourcePath="\\server\share\Office">
Now make a new file called deploy.bat inside of your folder we created in step 2.2
Once the command has executed, Office 365 Professional Plus should automatically be deployed on the machine! The last step is for the user to login to their profile and activate Office 365 using their Office365 credentials.
Hope this helps! If anyone finds a better solution, please let me know and I can update the guide 🙂
If you receive the error when configuring the Microsoft Directory Synchronization Tool to communicate with Office 365:
"Access to the registry key 'HKEY_LOCAL_MACHINE\Software\Microsoft\MSOLCoExistence' is denied"
Make you you right click and run the tool as an administrator 🙂
Microsoft Online Service Directory Synchronization Configuration Wizard in the Configuration step. The error