Backup not starting

[tvveen]

We're receiving the following error:
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.

Can anyone help us?

[Mike Resseler]

Tim,

I believe this could be resolved by changing something in the XML document. But to be sure, I would ask you to contact support so they can help you. Document type definition validation (DTD) should not be done for this service, but for some reason you are requiring it. So please contact support, let us know the support case ID and the outcome after investigation with the engineers

Thanks
Mike

[JLundgren]

Hello Mike,

I had the same issue and have recently been in contact with Veeam Support, Case # 03154813.
The problem is solved in my case.

Regards,

JLundgren

[Mike Resseler]

Thanks Johnny! I just reviewed your case and it is not an easy one . It had nothing to do with DTD at all (which makes sense since I didn't understand why that message came anyway)

So Tim, please create a support case and let us know the case ID and the outcome

Thanks
Mike

[edwardm9]

Hi all - I had this issue as well and wanted to share my resolution. It was very odd and working with MSFT support resolved the issue. It was related to the fact that the tenant we were attempting to backup was federated or had remnants of being federated.

We went through the usual tshooting - trying the same tenant from different networks, from different machines, updating sharepoint modules, etc. We narrowed it down to the following behavior. For the tenant in question, attempting to connect with code like the following failed from everywhere with the DTD XML error. We were able to successfully connect using the same code to other tenants and thus Veeam O365 backup for Sharepoint was working for those other tenants.

$AdminURL = “https://client-admin.sharepoint.com”
$cred = get-credential
Connect-SPOService -Url $AdminURL -Credential $cred

The other odd piece was that, for the tenant in question, if you just issue the command connect-sposervice and then are prompted for URL and credential this works. In this manner connect-sposervice uses the web credential prompt, but the get-credential command uses the older windows style mechanism. Anyway the support engineer knew what this meant and we added the following lines to the hosts file. Note that the first line is the MSFT tenant name and the last line is the primary email suffix domain.

127.0.0.1 msoid.client.onmicrosoft.com
127.0.0.1 msoid.onmicrosoft.com
127.0.0.1 msoid.clientemailsuffix.com

A fiddler trace shows that attempting to login tried to reach the addresses we modified, and those attempts were being routed to the clients premises through their domain provider.

[Polina]

Hi Edward,

Thanks for posting!
Let me also add that we've just published a KB article on the "For security reasons DTD is prohibited in this XML document" error.

[edwardm9]

Awesome thanks! Much more concise than mine