Log Parser issue with SharePoint claims user name special characters

Problem

I'm using Log Parser 2.2 to read IIS logs and import them to SQL Server. Everything works fine except the cs-username field: if it contains special characters, those get messed up during database import. As this is SharePoint web application and it uses external trusted provider, I cannot control nor get rid of the special characters in user names before they are stored in IIS logs.

So, the IIS logs contain hits with user names such as:

    #Software: Microsoft Internet Information Services 8.5
    #Version: 1.0
    #Date: 2016-10-01 07:27:28
    #Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) cs-host sc-status
    2016-10-01 07:28:15 10.0.2.4 GET /_layouts/images/advadd.png - 443 0ǵ.t|claims+idp|12345678 111.222.223.224 Mozilla/5.0 https://my.site.com/page.aspx my.site.com 200

And after Log Parser imports those to DB, user name has changed to 0ǵ.t|claims+idp|12345678

Same applies if I test outputting it to Data Grid with

    LogParser.exe "SELECT cs-username FROM f:\iislogs\dev3\*.log" -i:IISW3C -o:datagrid

--> I see 0ǵ.t|claims+idp|12345678 instead of 0ǵ.t|claims+idp|12345678.

 

Solution

As IIS Log files are stored using UTF-8, you need to add -iCodepage 65001 to the Log Parser command, like so:

logparser.exe file:AnalyticsQuery.sql -i:IISW3C -o:SQL -database:AnalyticsDB -server:sqlserver -iCodepage:65001

And of course remember to set your table column as nvarchar or other n-type.

SQL Server: Log Shipping backup job fails

Problem

After configuring Log Shipping, the first job that runs is the transaction log backup. However, it keeps on failing with very generic error:

Executed as user: DOMAIN\sqlagent1. The step failed.

No matter what you do, it just won’t log anything else, e.g., configuring the Job step to log to file just ends up with empty log file. Also the log table contains no rows for this specific step.

Solution

I finally tried executing the sqllogship.exe command from the failing Job step on the SQL server:

"s:\Program Files\Microsoft SQL Server\130\Tools\Binn\sqllogship.exe" –Backup <GUID> -server SQL-1

and it displayed me dialog that .NET Framework 3.5 was required on the server. After installing that from “Add Roles and Features”, the Job finally executed without issues.

How to configure SharePoint + SQL on Azure VM to use Internal Load Balancer

Task

While creating SharePoint 2016 MinRole farm in Azure with altogether 14 servers, it took me a while to understand how to configure SQL Server connection on SharePoint servers. In more simple farms without SQL Server AlwaysOn Availability Groups it was straightforward to simply set SQL Alias using cliconfg tool on each SharePoint server. However now that there would be Internal Azure Load Balancer (ILB) via which all traffic would flow from SharePoint servers to SQL Server, this SQL Alias wasn’t working.

Trying to point SQL Alias prodsql to the IP address of the ILB just didn’t work, but as soon as I pointed prodsql to one single SQL Server everything worked nicely.

Solution

As many times, the solution was simple, but for some reason I was just too stuck to the “always use SQL server alias” thought to realize, that this time I in fact needed to remove the SQL Alias from all SharePoint servers and instead create DNS A record that points from prodsql to the ILB IP address.

Case closed.