Office 365 – DTD is prohibited in this document issue


 

 

 

 Office365logo       SP2013logo

Got trouble Connection PowerShell to SharePoint online? This could be the resolution to your troubles.
I had this myself, or we had it in our Company tenant. This is what the issue was and this is how I fixed it:

When trying to connect to PowerShell for SharePoint Online, using the Connect-SPOService command, we got a error that did not tell us anything.

PS dtd error 1

The error is:
Connect-SPOService : For security reasons DTD is prohibited in this document. To enable DTD processing set DtdProcessing property on XmlReaderSettings to Parse and pass the settings into XmlReader.Create method.

Well, its almost a joke right…
When searching the web for information on this particular, I struck zero…all I could find related to the ISP and the default search provider something. I quickly dismissed them as unrelated.
Then after some time had passed, I found a similar issue, this seemed related and it was a connectivity issue same as mine (If I still had the link I would give credit to where credit is due). This fellow had resolved the issue by adding a missing DNS record.
This made me think, since our tenant has existed since way Before Office 365 existed (BPOS) perheps we were also missing some of the required DNS records?
I checked with my collegues, and apparently we were missing the record as well.

So, if you ever see or get the ‘DTD prohibited’ issue, remember to check the DNS for the following record:

Type: CNAME
Alias: MSOID
Target: clientconfig.microsoftonline-p.net
Info: Used by Office 365 to direct authentication to the correct identity platform More Information

After I added this to DNS, Connect-SPOService works just fine!

SPO-Connect

 

Microsoft’s official explaination on the DNS record:
What’s the purpose of the additional Office 365 CNAME record?

When you run a client application that works with Office 365 such as Lync, Outlook, Windows PowerShell or Microsoft Azure Active Directory Sync tool, your credentials must be authenticated. Office 365 uses a CNAME record to point to the correct authentication endpoint for your location, which ensures rapid authentication response times.If this CNAME record is missing for your domain, these applications will use a default authentication endpoint in the United States, which means authentication might be slower. If this CNAME record isn’t configured properly, for example, if you have a typo in the Points to address, these applications won’t be able to authenticate.

If Office 365 manages your domain’s DNS records,, Office 365 sets up this CNAME record for you.

If you are managing DNS records for your domain at your DNS host, to create this record, you create this record yourself by following the instructions for your DNS host.

 

References and Credits
Nope, not this time…Credits & many thanks to To all of you.

_________________________________________________________

Enjoy!

Regards

Twitter | Technet Profile | LinkedIn

Advertisements
  1. May 19, 2016 at 11:25

    Hi

    Could’t believe it when I got with this error on the SharePoint Client Browser , then later with with my favourite pnpCommandlets . I have now passed your advice to my client who manages DNS – weird it hasn’t been an issue on my tenant or another tenant I have recently worked on. We’re all based in the UK but then what does this mean in Azure .
    Thanks once again for another awesome post.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: