Solving the `For security reasons DTD is prohibited in this XML document.’ PowerShell Error
This is more a Todd Klindt (@ToddKlindt) post than a me post, but hey – he was on vacation. I was trying to run some PowerShell on my new-ish tenant and was getting an error Todd and I had worked past before. Just a simple:
$adminSiteUrl = "https://sympmarc-admin.sharepoint.com"
Connect-PnPOnline -Url $adminSiteUrl -Credential sympmarc
…was giving me an error like this:
Connect-PnPOnline : For security reasons DTD is prohibited in this XML document. To enable DTD processing set the DtdProcessing property on XmlReaderSettings to Parse and pass the settings into XmlReader.Create method. At line:3 char:1 Connect-PnPOnline -Url $adminSiteUrl -Credential sympmarc~~~~~~~~~~~~~ CategoryInfo : NotSpecified: (:) [Connect-PnPOnline], XmlException FullyQualifiedErrorId : System.Xml.XmlException,SharePointPnP.PowerShell.Commands.Bas e.ConnectOnline
The problem was a combination of my new Office 365 tenant and my ISP, NOT the PowerShell, of course.
I figured out what the initial issue was by running Fiddler and capturing the traffic when I ran the Connect-PnPOnline
cmdlet. Here’s what I saw:
HTTP/1.1 401 Unauthorized Content-Type: text/plain; charset=utf-8 Server: Microsoft-IIS/10.0 X-SharePointHealthScore: 4 X-MSDAVEXT_Error: 917656; Access+denied.+Before+opening+files+in+this+location%2c+you+must+first+browse+to+the+web+site+and+select+the+option+to+login+automatically. SPRequestGuid: 8c8dfa9e-0055-0000-498e-df43e63fdd9e request-id: 8c8dfa9e-0055-0000-498e-df43e63fdd9e MS-CV: nvqNjFUAAABJjt9D5j/dng.0 Strict-Transport-Security: max-age=31536000 SPRequestDuration: 52 SPIisLatency: 0 X-Powered-By: ASP.NET MicrosoftSharePointTeamServices: 16.0.0.9124 X-Content-Type-Options: nosniff X-MS-InvokeApp: 1; RequireReadOnly P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI" WWW-Authenticate: IDCRL Type="BPOSIDCRL", EndPoint="/_vti_bin/idcrl.svc/", RootDomain="sharepoint.com", Policy="MBI" Date: Thu, 15 Aug 2019 19:05:44 GMT Content-Length: 0
HTTP/1.1 200 OK Server: nginx Date: Thu, 15 Aug 2019 19:05:45 GMT Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Connection: close Expires: Thu, 15 Aug 2019 19:15:45 GMT Cache-Control: max-age=600 X-Frame-Options: DENY 372 url="http://finder.cox.net/main?ParticipantID=96e687opkbv4scrood8k84drs6gw5duf&FailedURI=http%3A%2F%2Fmsoid.sympmarc.com%2FFPUrl.xml&FailureMode=1&Implementation=&AddInType=4&Version=pywr1.0&ClientLocation=us";if(top.location!=location){var w=window,d=document,e=d.documentElement,b=d.body,x=w.innerWidth||e.clientWidth||b.clientWidth,y=w.innerHeight||e.clientHeight||b.clientHeight;url+="&w="+x+"&h="+y;}window.location.replace(url); 0
I was getting an HTTP/1.1 401 Unauthorized
– but I knew my credentials were correct and I had the right permissions. The big clue was the URL, which pointed to http://finder.cox.net
. Obviously, that wasn’t the tenant I was working with, so what was up?
Well, Cox is my ISP right now and it was trying to be helpful. It tries to do DNS lookups for me and if it can’t find the site I’m trying to reach, it gives me a “helpful” message like this:
The PowerShell cmdlet was trying to parse the “helpful” page from Cox, and of course it had no idea what that page meant. The cmdlet was expecting to hear back from SharePoint, not Cox.
It turned out there were two issues:
- I hadn’t added a domain to my new-ish tenant yet. So while I was fine using it as [email protected], there was no way for PowerShell to “hook into” the tenant correctly.
- Once I added my domain to my tenant, I was missing a CNAME entry for
MSOID
in my DNS records at my registrar.
Here’s what the CNAME record needs to be:
Type: CNAME
Name: msoid
Content: clientconfig.microsoftonline-p.net
Once I took care of both the issues above, everything was copacetic.
In trying to track down the problem, I found several articles which should have helped me get to a resolution, but somehow they didn’t make sense to me. Now that I understand the issue better they make total sense, but I figured I’d do a post in case my take on it might be useful for someone.
I had the same issue with Virgin Media and changing the DNS settings to use Google DNS solved the problem.
yes this is a problem with many ISP providers…. Verizon as well. changing DNS to Open DNS or Google fixes this
just another comment, if you switch your laptop Wifi to use alternative DNS and you go to an airport or Microsoft office where they redirect you typically won’t be able to connect and you won’t know why. Change back to dynamic DNS, authenticate and then switch it back.