Category Archives: Troubleshooting

Office 365 Shadow Tenants – Sorry, you can’t add domain.com here because it’s already in use

Sorry, you can’t add domain.com here because it’s already in use. If you own the domain.com domain and want to manage it, you have a couple of options.

 

This issue has come up a number of times with my clients. We are unable to add and verify production domains to a production tenant, because someone in the orgainization has used the company email address and signed up for a trail PowerBI (etc..) accounts. Because of the way that Office 365 is setup, when you sign up for those trials, a shadow tenant is created and your domain is locked (unverified) to that tenant. In my example, I have opened a trail for PowerBI, using an email address (kelsey.epps@office365testing.org) that hasn’t been registered with my production Office 365 tenant. Now, when I try to add the domain (office365testing.org) to my production Office 365 tenant, I get the error below (in red and screen shot). This is because the shadow tenant that was created for PowerBI trial is using that domain.

In order to resolve this, you will need to do an admin takeover of the shadow tenant and then release the domain so that it can be registered to your Office 365 tenant. This involves you opening another trial to PowerBI, taking admin ownership and verifying the domain in the shadow tenant, removing the domain from the shadow tenant and then adding and verifying it into your tenant.

 

Sorry, you can’t add domain.com here because it’s already in use. If you own the domain.com domain and want to manage it, you have a couple of options.

 

 

Follow these instructions to remove the domain from the Shadow tenant and add it to your production tenant.

 

Navigate to https://powerbi.microsoft.com/

 

Enter your email address (that includes that domain that you can’t add to your Office 365 tenant). My example is office365testing.org

 

Click ‘Use it free’

 

A confirmation email will be sent to your account. Click the link to verify the email address.

 

 

Enter your First Name, Last Name and a password. Click Start

 

The PowerBI setup process will kick off and your account will be added to the Shadow Tenant


 

Click the Office 365 waffle (app launcher)

Click the Admin Icon

 


 

This will take you to the admin take over webpage

Click ‘Yes, I want to be the admin’

 

Add the verification TXT record to your external DNS. Mine happens to be hosted on GoDaddy, so there are instructions for GoDaddy on the page.

 

 

Once the TXT record is added to public DNS, give it some time for replication. This is generally completed within 30 minutes, but can take up to 72 hours.

Click ‘Okay, I’ve added the record’

 

The process will now go out and verify that the TXT record supplied is added to public DNS. Once completed, your account will be added as the admin for the shadow tenant.

 

Click ‘Go to the Office 365 homepage’ or login to https://portal.office.com with your account.

Once logged into the Office 365 Admin Portal, click Users -> Active Users

This will show you all the people that have opened trail accounts of PowerBI

 

In order to remove the domain, so that we can register it in the main tenant, you need to edit the users and change the UPN to the onmicrosoft.com domain (in my example – office365testingorg.onmicrosoft.com). This is required because none of the users can have the office365testing.org domain in use, if we want to remove the domain from this tenant. It’s recommended that you update all the users and then your admin account.

Double click a user and change the UPN to the domain.onmicrosoft.com address

Click Save

 

You may receive a warning. Click Yes

Repeat for all the users

Let your users know they still have their trial accounts, but the user name is now changed. This will allow them to remove their data.

 

Edit your admin account the same way

Click Yes to the warning

Click OK and sign out of the shadow tenant

Sign back in with the new user name (user@domain.onmicrosoft.com)

 

Click Domains and select the domain you want to remove (this is the domain that you want to add to your production tenant)

 

With the domain selected, click ‘Remove domain’

Click Yes

The domain will be removed from the shadow tenant and is not free to add to your tenant (give the process some replication time across the Microsoft backend servers).

Logout of the shadow tenant

 

Login to your production tenant where you were getting the error adding the domain with your admin account and try to add the domain again. This time it should work without giving you the error. Please note that you will have to verify ownership again by adding the TXT record into public DNS.

 

Login to the production tenant – https://portal.office.com

Navigate to domains

Click
+ Add domain

 

Click ‘Let’s get started ->’

 

Add the newly released domain from the shadow tenant

Click Next

 

Verify domain ownership. Since I use GoDaddy, the process will allow me to sign into my GoDaddy account and verify, or use a TXT record in public DNS. Since I am lazy, I will just sign into GoDaddy and let automation rule my life. 😉

 

Success (and I forgot to screen shot the page before clicking next) … The domain is now verified and added to your production tenant. Step through the rest of the steps and now when viewing the domains in the production tenant, you will see it there and verified.

 

 

Thanks for visiting and reading my posts. I am always looking for more ideas. Please comment or email me with what you would like to see.

Kelsey Epps Office365 MVP

Email Me Follow me on Twitter Connect with me on LinkedIN

 

 

 

 

 

 

 

 

 

List and Export the Admin Roles Assigned to Users in Office 365 with PowerShell

If you didn’t know, you can use the Office 365 Admin portal to view and create views of all the admin roles in Office 365 and who is assigned to each of those roles. This is good for a quick reference, but sometimes we need that data in a workable format (CSV). The following step-by-step will show you how to list and export the admin roles assigned to users in Office 365 with PowerShell. This is done with the Get-MsolRoleMember command in PowerShell

 

Connect to Azure Active Directory with PowerShell

Enter the command $role = Get-MsolRole -RoleName “Company Administrator”

Enter the command Get-MsolRoleMember -RoleObjectId $role.ObjectId | Export-CSV c:\directory\filename.csv

This will export all the members of the Company Administrator (Global Admin) group.

 

If you want to export from the other built-in groups, a list is provided below. You can always view the roles by entering the command Get-MsolRole

 

Name Description
Compliance Administrator Compliance administrator.
Exchange Service Administrator Exchange Service Administrator.
Partner Tier1 Support Allows ability to perform tier1 support tasks.
Company Administrator Company Administrator role has full access to perform any operation in the company scope.
Helpdesk Administrator Helpdesk Administrator has access to perform common helpdesk related tasks.
Lync Service Administrator Lync Service Administrator.
Directory Readers Allows access to various read only tasks in the directory.
Directory Writers Allows access read tasks and a subset of write tasks in the directory.
Device Join Device Join
Device Administrators Device Administrators
Billing Administrator Billing Administrator has access to perform common billing related tasks.
Workplace Device Join Workplace Device Join
Directory Synchronization Accounts Directory Synchronization Accounts
Device Users Device Users
Partner Tier2 Support Allows ability to perform tier2 support tasks.
Service Support Administrator Service Support Administrator has access to perform common support tasks.
SharePoint Service Administrator SharePoint Service Administrator.
User Account Administrator User Account Administrator has access to perform common user management related tasks.

 

Thanks for visiting and reading my posts. I am always looking for more ideas. Please comment or email me with what you would like to see.

Kelsey Epps Office365 MVP

Email Me Follow me on Twitter Connect with me on LinkedIN

Finding and Changing the Primary AD FS 2.0 Server in an AD FS 2.0 Farm with PowerShell

PowerShell can be used to quickly identify the primary server in an AD FS 2.0 farm. When you deploy AD FS 2.0 and setup with a default install, it will use Windows Internal Database (WID). In this setup the WID database on the Primary AD FS server is a read/write copy. All the Secondary AD FS server(s), in the farm, have a read only copy that is synchronizes from the Primary.

 

  • Run this command to view the role of the server and see who it’s synchronizing the database changes from.

    Get-ADFSSyncConfiguration

 

Command run on an AD FS Primary Server

 

Command run on an AD FS Secondary Server

 

 

In the event that you lose the Primary AD FS server in the farm, you can move the role to any Secondary Server in the same farm. This again is done through PowerShell with a simple command.

 

  • Run this PowerShell command on the Secondary AD FS server that you want to make Primary AD FS server.

    Set-AdfsSyncProperties -Role PrimaryComputer

And then

  • Run this command to view the current role. It should change to PrimaryComputer

    Get-ADFSSyncConfiguration

 

 

 

Now that the Primary role is moved you must update all the other Secondary servers, if you have more than two Secondary servers in the farm.

 

  • Run this PowerShell command on the other Secondary AD FS servers so that they now sync with the new AD FS Primary server

    Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName FQDN of ADFS Primary Server

 

Thanks for visiting and reading my posts. I am always looking for more ideas. Please comment or email me with what you would like to see.

Kelsey Epps Office365 MVP

Technical Consultant

Concepps Group

Email Me Follow me on Twitter Connect with me on LinkedIN

 

 

 

 

 

 

Your Organization Could Not Sign you into this Service

 

Signin

 

 Your Organization Could Not Sign you into this Service. 

 

I ran across this error when I was troubleshooting for a client. They are using TMG 2010 to publish ADFS to the internet. When I checked the logs on the ADFS server, I can see that the client is hitting the ADFS server and that Authentication is successful.

The resolution for this case was to verify the setup of the TMG server. Use my BLOG post for the correct settings.

Publishing ADFS 2.0 using Threat Management Gateway 2010

 

Microsoft has also noted that there can be additional issues with the same error message. They published these KB articles to address the issue.

“Your organization could not sign you in to this service” error and “80041317” or “80043431” error code when a federated user tries to sign in to Office 365

and/or

How to update or to repair the configuration of the Office 365 federated domain

 

Thanks for visiting and reading my posts. I am always looking for more ideas. Please comment or email me with what you would like to see.

Kelsey Epps

Office 365 MVP

Email Me Follow me on Twitter Connect with me on LinkedIN Facebook Me

REPLAY – Back to Basics: Setting Up Office 365 – Lync and Learn

Thank you to everyone who attended my Lync and Learn Session. In case you missed it, you can view the Lync recording here or watch the video below. Look for more Office 365 webcast sessions by following the Office 365 Technical blog.

http://community.office365.com/en-us/blogs/office_365_technical_blog/archive/2012/12/12/back-to-basics-setting-up-office-365-lync-and-learn.aspx

Back to Basics: Setting Up Office 365 – Lync and Learn

 

Thanks for visiting and reading my posts. I am always looking for more ideas. Please comment or email me with what you would like to see.

Kelsey Epps

Office 365 MVP

Email Me Follow me on Twitter Connect with me on LinkedIN Facebook Me


Back to Basics: Setting Up Office 365 – Lync and Learn

I am excited to announce that I am going to be doing a Lync and Learn session for the Microsoft Office 365 User Community.

 http://community.office365.com/en-us/blogs/office_365_technical_blog/archive/2012/12/12/back-to-basics-setting-up-office-365-lync-and-learn.aspx

 Audience:

Office 365 for professionals and small businesses
Office 365 for enterprises

Lync and Learn is an online session led by Office 365 Product Managers and Community Grid members. Lync and Learn sessions address different Office 365 subjects and scenarios and is beneficial to anyone who wants to learn more and expand their knowledge of the Office 365 suite. View past Lync and Learn sessions here.


Office 365 provides convenience in the cloud through a great set of productivity and collaboration tools. In this Lync and Learn session, Kelsey Epps will provide some convenience of his own through helping us set up Office 365. We’ll get back to the basics and dive into setting up Office 365. In this Lync and Learn Webcast we will cover the following:

  • Sign-up for the trial
  • Adding a domain and verifying it
  • DNS records
  • Create Users and Assign licenses
  • Setup Desktop PC for User
  • Accessing Office 365 Services from the Desktop and Internet
  • Purchasing Additional Licenses
  • Open a service request

Kelsey Epps is a Senior Systems Engineer with a background in Microsoft Clustering, Exchange Server, Lync Server and Windows Server.

Download the calendar invite below and join us on December 20th at 10:00 AM Pacific Time for this great session.

Interested in being our next Lync and Learn presenter? Learn how to join the Office 365 Grid and become an Office 365 Lync and Learn presenter.

———————————————————————————————————————————————————

Presenter: Kelsey Epps, Technology Consultant with HP and Concepps Group, and Office 365 Grid member.

Date/Time: Thursday December 20th, at 10:00 AM Pacific Time. (1 Hour presentation)

Live Meeting Information:
Join online meeting
https://join.microsoft.com/meet/v-joshto/F00T8BQY
Join by Phone
+18883203585
Find a local number

Conference ID: 27579341
Forgot your dial-in PIN? |
First online meeting?
[

Unable to Setup your Office 365 Mailbox with Outlook

We get this question all the time. People are trying to setup mailboxes from their Office 365 Account, but it’s just not working. There are a number of reasons for the problems, but most of the time it boils down to the three listed below.

Here is the most common screen shot error. This is usually an issue with DNS


Here is the second most common screen shot error. This one is clearly password.


 

Troubleshooting

Check to make sure that your user (with the issues) has an active Exchange License assigned to their account. This is done through the Microsoft Online Portal

As you can see this user has a license properly assigned.


Check to make sure that the user is filling out the Outlook prompt correctly. The first two are pretty straight forward, but the password can throw some people off.

Your Name: Keep it neat and enter the display name on the account

E-mail Address: Your Office 365 email address

Password: Your Office 365 password. Most of the time when an account is setup, the users will forget (or don’t know) to login to the portal and change their password. Until that password is changed from the default one, Outlook will not setup correctly.


Since we know that Outlook relies on an Autodiscover DNS record lets verify that we can ping. If setup correctly when you ping autodiscover (from the internal network) or autodiscover.domainname.com (from the internet), you should get name resolution to autodiscover.outlook.com. We have verified that the DNS entries are correct in our public DNS, yet when we ping autodiscover or autodiscover.domainname.com, it tells me Ping request could not find a host.



The cause of the issue is a result of running split brain DNS. The resolution to this issue is to add the autodiscover CNAME record to your internal DNS server. Since your workstation is connected to the internal DNS server and it has a zone that matches your internet zone, you will never reach the public DNS server. For this reason, the CNAME record for Autodiscover needs to be added to the internal DNS server.


Once the CNAME record is added to the internal DNS server, the workstation can now resolve the name correctly.


Once Name resolution is cleared up, Outlook will now setup your account correctly.

 

 

Thanks for visiting and reading my posts. I am always looking for more ideas. Please comment or email me with what you would like to see.

Kelsey Epps

Office 365 MVP

Email Me Follow me on Twitter Connect with me on LinkedIN Facebook Me