While testing out MSSQL 2012 Always On Failover Clustering in my lab, I stumbled upon a strange error which I have never seen before: “Updating permission settings for file [Shared drive]\[Mountpoint]\System Volume Information\ResumeKeyFilter.store failed”. This happened for all drives that was mounted as a mount point (folder) instead of a drive letter.
Continue reading “Permission error installing Failover Cluster instance”
I have never quite liked the way Microsoft wants me to use Windows Explorer. The standard settings are quite annoying to me, but I understand why they are as they are on end user versions of Windows. Joe User is stupid, usually more so than you might imagine possible, so it is important to protect him against himself. On a server on the other hand, I would think we should anticipate some minimal knowledge about the file system. A server user should be able to look at a system file without thinking: “Hmm, bootmgr is a file I haven’t seen before. I should probably delete it. And that big windows folder just contains a lot of strange files I never use. I’m deleting some of those too, it will leave more room for pictures of my cat!”. But no, it has the same stupid defaults as the home editions. Because of this, I have had to create a list of all the stuff I have to remember to change whenever I log on to a new server, lest I go insane and maul the next poor user who want’s me to recover the database he “forgot” to back up before the disk crashed. 
Trying to run the new-TestCasConnectivityUser.ps1 raises an error claiming that the password is not complex enough, or that the OU does not exist:
Continue reading “Creating test accounts for SCOM on Split Permissions”
I have been reading a lot about MSSQL 2012 lately, to get myself ready for when the developers and application admins find out about the new features and start nagging about having servers upgraded to the latest and (possibly) greatest. 
I am usually very skeptical when it comes to upgrading to a new version of enterprise software within the first 6 months of its release, especially so if the current version works perfectly fine as is. So far I haven’t read anything to quell my skepticism, but sooner or later I guess I have to face the music and start upgrading or migrating databases. The good thing though about reading documentation is the rediscovery of forgotten features and possibilities. Sometimes it is nice to just let the mind take a random road trip through the interwebs, just to find out were it winds up. This time, I got reacquainted with DML triggers and events, and remembered a long forgotten scheming plan to track who was tampering with MY databases, which is the main focal point of this post.
In the event log event id 12291 from SQLISPackage100 is recorded, together with event id 208 from the MSSQL Agent service:
In the MSSQL log for the job, the following error is recorded:
The package execution returned DTSER_FAILURE (1).
This was caused by some of the job tasks not having their database selections stored properly:
So the solution was simple, just select the proper databases and remember to save the maintenance plan afterwards 
There seems to be a widespread misconception in the IT community regarding Single Points of Failure: as long as you have N+1 redundancy in all your components, you no longer have a single point of failure. This is not necessarily correct, and can lead to a very bad day when you discover that your “bullet proof” datacenter or system design turns out to be one big basket with all your eggs in it. The fact of the matter is that adding redundancy to a component will only reduce the chance of failure, it won’t make it impossible for the component to fail. Take a MSSQL failover cluster for instance, be it Active-Active or the more common Active-Passive. Compared to a stand-alone server it offers far better redundancy, and it will limit maintenance downtime to a bare minimum. But on its own it is still a single point of failure, in fact it has several single points of failure: shared network/IP, shared storage and the cluster service itself to mention a few. I have seen all of the above fail in production, resulting in complete failure of the cluster. Especially on Win2003 and earlier, a poorly configured cluster could easily cause more problems than a stand-alone server ever would, but even if everything is set up and maintained properly, bad things will happen sooner or later.
Continue reading “Redundancy versus Single Points of Failure”
After having to look this up for the n’th time, I decided to document it for my self. If you are using the built in VPN client in Windows to connect to a VPN gateway, for instance your own home firewall for remote access, you have probably noticed that your local internet connection may stop working while you are connected to the VPN. All traffic is tunneled to the remote VPN gateway, which can have a detrimental effect on your internet connection throughput. And if like me, you haven’t bothered to set up the firewall/vpn gateway to allow this in the first place, all local applications will loose internet connectivity while you are connected to the VPN.
To work around this, you have to allow local network access in the VPN connection settings. Microsoft has chosen to call this setting “Use default gateway on remote network”. You will find a similar setting in most VPN clients, but they are usually labeled something like “Allow local access”. anyway, in Windows 7 you will find this setting under Networking, IPv4, Properties, Advanced:
The same setting is available for IPv6
DECLARE @AVG_FRAG float
DECLARE @MIN_PAGES int
SET @AVG_FRAG = 10
SET @MIN_PAGES = 1000
SELECT db.name, ips.index_type_desc, COUNT(*) as FragmentedIndexes
FROM sys.dm_db_index_physical_stats(null, null, NULL, NULL, NULL) ips
left join sys.databases db on ips.database_id = db.database_id
WHERE avg_fragmentation_in_percent > @AVG_FRAG and
ips.page_count > @MIN_PAGES
group by db.name, index_type_desc
order by db.name, index_type_desc
Lists the databases containing indexes and heaps with an average fragmentation percentage larger than @AVG_FRAG and how many indexes in the given database that are fragmented. Used to identify index issues at the instance/server level. @MIN_PAGES define the minimum size of the index. Small indexes are usually not affected by fragmentation and you can safely ignore them. The default limit in the script is set to 1000 pages (8000KiB), based on the recommendations from http://technet.microsoft.com/en-us/library/cc966523.aspx .
You may be unable to connect to a WebDAV share because of security constraints. More specifically, unable to use basic authentication to non-ssl shares. This is a very bad thing to do, as it implies sending the password in plain text over the network. Ergo it is disabled by default, but if you absolutely have to use it, this is how you enable it:
Change the value of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\BasicAuthLevel to 2.
The possible options are:
Se http://support.microsoft.com/kb/841215 for details.
You may get the following error when downloading or uploading a large file from a WebDAV share: Error 0x800700DF The file size exceeds the limit allowed and cannot be saved.
The default limit on Windows 7 is 50.000.000 bytes, or 47,68MiB if you will. That’s not very much if you are trying to download a 3GiB iso file or something like that. As the error message hints at, this is a configurable limit. It is defined in the following registry value:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\FileSizeLimitInBytes
Change it to a value suiting your needs. The maximum value is 4095MiB, or 0xFFFFFFFF.
You should also increase the FileAttributesLimitInBytes setting a bit. This setting determines how big a directory listing is allowed to be in bytes, which translates to how many files and subfolders you are able to list on screen. If you have directories containing more than 1000 sub-items, the view could be truncated. I have added an extra 0 to the default value.
Event 1006 is logged several times each day in the system event log with the message The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description. The details pane lists Invalid Credentials as the error description:
This error is most likely caused by a user session that is logged on to the machine with an expired domain password. The user name event property identifies the user in question. This situation typically arises when users stay logged on to a computer or server for several weeks at the time, long enough for a domain password expiry policy to force a password change. The user is prompted to change the password at the next login, but if the user never logs out, the session keeps running with the old credentials. The same error will occur if the users session is a disconnected or active remote desktop session.
Log out and log back in to trigger the password change dialog. If the password has already been changed on another computer or directly in the directory, just log back in with your new password.
If your own session isn’t the culprit, you can forcibly log out another user using Remote Desktop Services Manager (server only) or Task Manager. Be aware of the fact that this method will exit all programs without saving in the session you log off.