ConfigMgr and Microsoft Store for Business Sync Fails

I ran into a odd problem when trying to setup the connection between Configuration Manager and the Microsoft Store for Business. I completed all steps mentioned at: microsoft dot com /sccm/apps/deploy-use/manage-apps-from-the-windows-store-for-business, however the sync would fail. In the WsfbSyncWorker.log I found this error: System.IO.IOException: This security ID may not be assigned as the owner of this object.

Alert Widget Static Column Width

Update 2/10: This issue appears to be fixed in 2012 R2 UR5.

A while back I ran into an issue with creating some dashboards for SCOM.  Specifically, the issue came along when working with the Alert Widget.  I ran into the issue where columns in the Alert Widget would get very wide and one column could fill up an entire screen, rending the rest of the view essentially useless.  This is due to the “Auto” width feature in the widget.  While it is great to have Auto as an option, it isn’t always appropriate for all columns.

SQL 2008 SP2 Slipstream Issue


Now that SP2 for SQL 2008 has been released it is time to update our SQL 2008 slip-streamed installation files. The slipstream process is the same, but I did run into one bug once the process was completed. There appears to be a bug that when you have a slip-streamed version of SQL 2008, the installation cannot be run from a network drive when .NET 4 has been installed. The following error may be received when attempting to launch setup.exe.

SQL Server: Create Login (Case Sensitive) Issue


I discovered an issue the other day when trying to add logins to a SQL Server with the collation of Latin1_General_BIN.

The T-SQL Command used was:
CREATE LOGIN [DOMAIN\username] FROM WINDOWS

The error I was receiving was:
Windows NT user or group ‘DOMAIN\username’ not found. Check the name again.

However, the username was very much valid. What I then found if I changed the format to DOMAIN\Username (capital U) it began to work. However, on other servers (with same collation), it rejected the capital U and wanted a lowercase U. After doing some digging, it appears that at least with the Latin1_General_BIN collation (not sure about other collations, I would expect other case-sensitive collations would inhibit similar results) that Master remembers logins how they are created the first time for a specific server and must continue to be entered using the same case going forward. This appears to be true even if you delete the login and try to re-create it, it still wants the original case (Master appears to cache is indefinitely).

When working with logins on a Latin1_General_BIN SQL Server make sure to be consistent when typing the case for logins. If you can’t figure out what the correct case is supposed to be, it appears if you add the login with the GUI, it will auto change it to be the format that master remembers.