This post was most recently updated on August 26th, 2022.
2 min read.This was a peculiar case! A cloud-based “service account” (in quotes, since it’s really just a non-personal user account) on a tenant with ADFS enabled started suddenly getting this error while running console programs configured as scheduled tasks.
Connecting to site failed: '.', hexadecimal value 0x00, is an invalid character.
Cause of the error
Okay – so I found a reason for the issue and a solution, but I’m not sure about the underlying cause for the ridiculous error message. I do have a guess, though!
In this case, we didn’t get very much debugging information from the customer, and since the error was thrown on a SharePoint Online site instead of On-Premises, we didn’t get server logs either. That’s ok – educated guesses are still possible!
The client had ADFS in use, and their configuration had On-Premises AD server taking priority in the login process. However, for cloud accounts ([email protected] – in my example below, [email protected]) the authentication is supposed to happen against the Azure AD (since that’s where the account is actually located).
However, since the local AD took priority, it was supposed to manage redirection to the AAD for authentication. In a browser, this works – but within a programmatic solution (such as shown below), this process fails with that peculiar error!
public virtual bool CheckCredentials(string url, string username, SecureString password)
{
using (var ctx = new ClientContext(url))
{
try
{
var credentials = new SharePointOnlineCredentials(username, password);
ctx.Credentials = credentials;
ctx.ExecuteQuery();
return true;
}
catch (Exception ex)
{
// We end here, with "ex" containing the puzzling error message
return false;
}
}
}
It seems to me, that with ADFS in use, the local AD redirected the authentication request to AAD, which probably returned some meaningful error in response (since the password had expired), but the local ADFS was expecting to get response data as XML, and failed to handle this response (due to a mismatch of the response type, or whatever other reason).
For SharePoint’s Client libraries, this error was returned instead of the original one. My guess is that the original one was omitted by the local Active Directory.
Speculation, I know! But at least the solution below worked for me.
Solution
The fix for me was simple. The password for that “service account” (again, in quotes for a good reason) had expired. Since nobody ever used it for logging in (it was just used for the tasks), nobody had gotten any password-changing prompts.
Does this apply to you, however? Easy to find out!
To investigate the issue, try logging into Office 365 using your account and password. There’s a fair chance, you’ll be presented with this:
In our case, the issue was fixed after the password was changed and updated to the Credential Manager on the computer running the tasks.
If this didn’t help you, it could be something else too. I found a few pointers about issues with certain Exchange configurations, for example. I’m leaving these useful links for your reference here:
- http://2008release2en.blogspot.com/2013/08/gelost-ms-exchange-2013-owa-login.html
- https://social.technet.microsoft.com/Forums/en-US/5c9eef7e-b852-4ab9-affa-00a2ea29eb3f/exchange-2013-owa-something-went-wrong-out-of-office-in-outlook-server-unavailable?forum=exchangesvrclients
- http://www.deskdr.com/dr/exchange-2013-owa-something-went-wrong-out-of-office-in-outlook-server-unavailable.html
He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.
This is his personal professional (e.g. professional, but definitely personal) blog.
