Category Archives: Windows Server 2008 R2

Internet Explorer 8 continually asking users to log into web sites in Terminal Services (2008 R2)

Ran into a super painful problem about 3 weeks ago. When users were logged onto a Terminal Server (Server 2008 R2) and running Internet Explorer 8 (Why, you ask, would I allow IE to run in Terminal Services? Normally I wouldn’t but the client’s app needs to be run within IE) any time they tried to download a file, or open a link that moved them to a new tab or window, the site “forgot” who they were and prompted them to re-authenticate.  This happened on many different sites, and not just on the app I mentioned.

We started down the normal troubleshooting path, allowing the site in Pop-up blocker, adding the site to the Trusted Sites list, lowering the security on the Trusted Sites list to “Low”, enabling Computability Mode, etc. Nothing would allow the file to be downloaded without having to re-login to the site.

As we continued testing, we removed all Group Policies that were locking down the Terminal Server, we created new users with fresh profiles, and double checked registry and file system permissions, again nothing would resolve the problem.

Finally, we came across this blog post over at the MSDN site, Here. Turns out, that when a new tab is opened, it starts running under a different process, combine that with users running on a Server 2008 R2 without “Power Users” permissions, like in the case of Terminal Services, and it creates a situation where the new process does not have permission to access the cookie that was stored by the other running process. This is not the case on Windows 7, as users without “Power Users” permissions don’t experience this same problem.

Internet Explorer changes it’s behavior of where it stores cookies and other data depending on the permissions for the user running the process. Any application which launches a new tab, in turn launches a new process and this will not have permission to access data like cookies from the process which launched it. Since the users are in a locked down environment, this Internet Explorer behavior should be turned off.

The registry value that we needed to change was located here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN

We needed to create a new DWORD called “TabProcGrowth” and set it’s value to 0.

The reason we are setting this value at HKLM and not HKCU is so that every users who uses this machine will have this setting applied to them. I’m far too lazy to change it and every user’s HKCU level.

After making this changed we were able to log in with new test users, and existing users alike and verify that we were no longer seeing the problem!

Getting System State Only Backups from Server 2008 / 2008 R2

If you’re like me you’re pretty crazy about backups. I hate not having backups, it never happens that you have an error or a data loss after a successful backup, it’s always after the backup fails. That’s why I always go the extra step and backup core components with their specific tools and then backup those backups with another 3rd party backup software. In server 2000/2003 I used to use NTBackup to make 2 overlapping system state backups, one for Monday, Wednesday, Friday, and one for Tuesday and Thursday. That way if Active Directory ever crapped out on me I’d have the last two days worth of system state backups, and in the original Microsoft form to boot. (it always easiest to do the restore with Microsoft tools, ever get stuck between two vendors swearing it’s the other guy’s fault? )

Anyway, so when Server 2008 came out I wasn’t happy with the fact that I had to either backup the entire C: volume, or that I had to backup to another volume other than the once i was taking a backup of, or that the command line option wasn’t automated. Sometimes you’ve got servers in a rack that only have 1 volume, and there’s not room for a USB drive, or if you’re like me you’re backing up with a 3rd party tool and you just want to keep the native format backups on the server as a spare copy. I ended up doing a bit of research and this is how you get it done:

First you’ve got to enable the ability to backup to the same volume you’re making a backup of. In Microsoft KB 944530 it gives you instructions on how to create a registry entry that enables the ability to backup to any volume. Here is the Location and Key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup\
Name: AllowSSBToAnyVolume
Data type: DWORD
Value data: 1

Or You can download it here: AllowSSBToAnyVolume

Once that’s been done, reboot and then you’ll be able to run a Windows Backup to any volume. Now the next time I do is create two batch scripts, one for MWF, and one for TTh, but again I’m crazy.

MWF’s Backup Batch Script:
Rmdir c:\systemstatebackups\mwf /s /q
Mkdir c:\systemstatebackups\mwf
Wbadmin start systemstatebackup –quiet –backuptarget:c:
Xcopy /s /e /c /h /y c:\windowsimagebackup\*.* c:\systemstatebackups\mwf\*.*
Rmdir c:\windowsimagebackup /s /q

and TTh’s Backup Batch Script:
Rmdir c:\systemstatebackups\tth /s /q
Mkdir c:\systemstatebackups\tth
Wbadmin start systemstatebackup –quiet –backuptarget:c:
Xcopy /s /e /c /h /y c:\windowsimagebackup\*.* c:\systemstatebackups\tth\*.*
Rmdir c:\windowsimagebackup /s /q

Schedule these to run on their proper days and there you have it, the last two days worth of system state only backups, ready to be picked up by a 3rd party backup software, or to be used to restore system state in the event of Active Directory corruption or deletion. It’s maybe a little bit unnecessary, but I’d rather have them and not need them than need them and have to deal with Symantec backup exec support trying to restore a lost CEO user account at 3 in the morning.

Attached Files:

Getting the impossible-to-use Microsoft Tools for SharePoint 2010 Farm backup to work

So it’s easy enough to get Share Point Central Administration to backup your farm, but it involves logging in every day to click the backup button, which can get tedious. I wanted a way to automate it but of course nothing was easy, after about two weeks to trying this that and the other thing, I came up with a little cheat sheet. It should be noted that I’m not a Share Point or SQL admin, and in fact I’m pretty new to working with either of them, so if you see something that could be improved on, please let me know.

The first time around in our test environment we didn’t install Share Point properly, and we tried to change the service accounts running Share Point through the Central Administration site. I’m not sure if it was bad luck, or something else, but the whole damn thing came crashing down, so please RTFM when installing new-to-you software. We  ended up going back, doing a little more planning, and performed a fresh install. I’ve decided to include some of those planning notes as pre-reqs before we go into getting the backup to work, as you’ll run into permissions problems if they’re not taken care of.

Pre Requisites Notes

Service Accounts:

svcSQL – This account is used to run all SQL related services, regardless of server.

svcSharePoint – This account is the account specified during SharePoint installation, also known as the “farm account” or “timer account” (don’t ask, I don’t understand either)

svcScheduledTask – This is the account under which the schedule task runs, when configuring the task make sure to use this account.

Installation of Applications

Okay, so when you install SQL make sure to use the svcSQL account to run all of the services.

When you install SharePoint, make sure to use the svcSharePoint account as the Farm account when installing. Also make sure to point all of your SQL needs to the SQL server and not a local database.

Assign the following permissions to the SQL databases for each service account:

User: svcSharepoint
Server Instance: SQL_SERVER\SQL_INSTANCE
Server Instance-Wide Role(s):
--dbcreator
--public
--securityadmin

Database Specific Role(s):
-SharePoint_AdminContent_{GUID}
--db_owner
--Public
--SharePoint_Shell_Access

-WSS_Content_Application_Pools
--db_owner
--Public
--SharePoint_Shell_Access

-SharePoint_Config
--db_owner
--Public
--SharePoint_Shell_Access

-WSS_Content_Application_Pools
--db_owner
--Public
--SharePoint_Shell_Access

-WSS_Content_{GUID}
--db_owner
--public

-WSS_Search_SQL_SERVER
--db_owner
--public

User: svcScheduledTask
Server Instance: SQL_SERVER\SQL_INSTANCE
Server Instance-Wide Role(s):
--Public

Database Specific Role(s):
-ALL Databases
--db_backupoperator
--public
--SharePoint_Shell_Access

Actual Backup Procedure

Now that the software is installed correctly we can take backups, if the software is not installed correctly forget about backups you’ll be lucky that central administration doesn’t implode. This is probably one of the most convoluted backup procedures you’ll ever see. Because of the combination of Batch scripts, and trying to call 1 Power Shell script from another, in combination with the fact that the Task Scheduler has a hell of a time with quotes, you end up with this, which is a scheduled task that runs 3 batch files, two of which contain Power Shell commands.

First, Create a new shared folder on the backup server, in this example we called it “data” give Full Control permissions to each service account (all three)

Then, Create a batch script called “cleanup” and put the following in it (adjust for LOCAL path)

rmdir C:\Data\SharepointBackups /s /q
mkdir c:\data\sharepointbackups

Next, Create a new Power shell script called “FarmBackup” (notepad file saved as .ps1) with the following lines (adjusted for UNC path):

Add-PSSnapin Microsoft.SharePoint.PowerShell
Backup-SPFarm -Directory \\BACKUP_SERVER\Data\sharepointbackups -BackupMethod Full

Next, Create a new batch script called “LaunchPowerShell” and put the following in it: (adjust for LOCAL path)

%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -command "& 'C:\Data\FarmBackup.ps1' "

Next, Create a new scheduled task that runs with the following settings on each tab:
General Tab:
-Run Whether use is logged in or not
-Run with highest privileges
Triggers Tab:
-Weekly – setup with proper days and times
Actions Tab:
-Create a new action, Run a Program, and run the Cleanup.bat file
-Create a 2nd action, Run a program, and enter the following command (adjusted for LOCAL path) in the Program/Script field:
D:\data\launchpowershell.bat

Run each of the following first to verify that they work before running a test job:

Cleanup.bat
Launchpowershell.bat
FarmBackup.ps1

Failures on either mean that the job won’t run.

Finally don’t forget to backup the C:\Data\SharepointBackups folder with some backup software.