One of our customers reported that the SQL Reporting Services would not start, in this case their DPM (Data Protection Manager) server, which would not allow them to run any reports.

When we attempted to start the service we would receive the following error and the service would not start:

In order to fix this we had to put in a registery entry which effectively increased the amount of time that the service would take to start before timing out:

1. Load up regedit.

2. Locate and then select the following registry sub key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control

3. In the right pane, locate the ServicesPipeTimeout entry.

If this does not exist follow steps a and b:

a. On the Edit menu, point to New, and then click DWORD Value. 
b. Type ServicesPipeTimeout, and then press ENTER. 
 
4. Right-click ServicesPipeTimeout, and then click Modify.

5. Click Decimal, type 60000, and then click OK.

6. Restart the computer.

After the server was rebooted the SQL Reporting Service was successfully started and the users could run their reporting in DPM. Hope it helps.

Recently we came across an issue on an Exchange 2010 environment where all mails sent via OWA and Outlook 2011 (MAC) were getting received as Plain Text mails externally even though we specifically had set OWA to send in HTML.

Internally Users could send HTML messages via OWA and they would get received by the users as HTML as we wanted. The first thing we did was to compare what transport rules were getting applied to external mail and not internal mail and visa versa. As a test we got a user to have the same transport rules that were getting applied when sending internally but apply this to any external address also, however the issue still remained so we had ruled that out.

The second thing we looked at was the send connectors, as they were set to send mail via Exchange Hosted Services so we wanted to rule out that anything was going wrong at this end. So we basically created a new send connector which would basically route mail via DNS MX records to a specific address space (i.e hotmail.com , domain.com) therefore bypassing EHS. We then tested again but the issues still remained.

The final thing we checked which revealed what the issue was to run the following exchange powershell “get-remotedomain | fl” . We then spotted that the content type was set to MimeText which “converts all messages to MIME messages that use text formatting” (i.e plain text).  We then changed the content type to mimehtmltext (Converts messages to MIME messages that use HTML formatting, unless the original message is a text message. If the original message is a text message, the outbound message is a MIME message that uses text formatting) by running the following command “get-remotedomain | set-remotedomain -ContentType MimeHtmlText”. Please Note You will have to alter the previous command if you have multiple remote domains so that you change the content type on the specific remote domain you want.

After the above change everything worked perfectly

Just to let you know Microsoft have released a hotfix to sort out an issue where users home folders were getting deleted whenever a users home folder path was change to a DFSR path within an AD user Object.

For full details of the symptoms see my previous blog ‘ http://support.risualblogs.com/blog/2011/01/24/offline-files-and-group-policy-causes-home-folder-deletion/’

The Hotfix is KB977611 and can be requested from the following location ‘http://support.microsoft.com/kb/977611’

Hotfix Symptoms Quoted from the above Microsoft KB Article.

“Consider the following scenario:

• As a domain administrator, you apply a Folder Redirection Group Policy object (GPO) in order to redirect a folder to a network share. For example, you redirect the Documents folder.
• You change the Folder Redirection GPO to specify a new network share. Additionally, the new network share targets the same physical location as the existing network share.
• When you change the Folder Redirection GPO, you click to select the Move the contents of <Folder_Name> to the new location check box.
• You apply the Folder Redirection GPO to the domain users and to the client computers.
• A domain user logs on to a client computer that is running Windows Vista or Windows Server 2008.

In this scenario, the domain user finds that the redirected folder is empty.
Notes

• This issue typically occurs when you redirect a folder to a Distributed File System (DFS) link.
• For more information about how to configure the Folder Redirection GPO, see the More information section.

”

We came across an issue recently where we deployed a TMG Server into a new site and configured it to upstream all connections to an ISA 2006 box.

All worked perfectly until users went to browse HTTPS and they were unable to when pointing there proxies to the new TMG Server. However if they pointed it directly at the upstream box HTTPS worked perfectly.

After looking in the TMG and ISA  logs all connections were getting allowed and no denies at all.

 The issue was a bug in TMG and has now been resolved in TMG SP1 Update 1 RU2

Just a quick script that may come in useful to you. The below Powershell script will delete IIS Log files older than 7 days that are in the “C:\inetpub\logs\LogFiles\w3svc1” directory. You can alter the script to how many days old the log files can be and also your IIS log location (Highlighted in red).

get-childitem -Path C:\inetpub\logs\LogFiles\w3svc1 -recurse | where-object {$_.lastwritetime -lt (get-date).addDays(-7)} | Foreach-Object { del $_.FullName }

Recent we came across an issue where certain users in our domain could not connect to Outlook Anywhere externally when connected via Direct Access.

The thing we found bizarre was that certain users could actually authenticate with exchange and another user who was practically identical couldn’t. Please note we had Kerberos constrained delegation set for Outlook anywhere.

When a broken user attempted to connect to exchange the following event was looged in the application log in UAG

Event ID 120

The S4U2Self Kerberos token for user Username with source IP address IP Address cannot be retrieved. Protocol transition failed. The application is Exchange 2010 on trunk TrunkName; Secure=1.

In the system log there were also Kerberos errors (Please not after Kerberos Logging has been enable on UAG server) and also the below errors were shown in Netmon.

KDC_ERR_PREAUTH_REQUIRED

KDC_ERR_C_PRINCIPAL_UNKNOWN

To Fix this we added our UAG server to the Windows Authorization Access Group and then straight away everything sprang into life and every user could connect to Outlook via Outlook Anywhere

I noticed a few posts from users searching for ways to find the serial number of their HP ProLiant servers. Below are a few ways to find this:

HP System Management Homepage:

HP Insight Diagnostics:

HP Serial Number Check Script:

http://h41111.www4.hp.com/hps/carepack/emea_middle_east/en/getserial.html

Problem

At a customer site that had critical updates to install on a few of their servers. When we attempted to download the updates we found that the download status bar would get stuck and not download:

We looked into the windowsupdate.log in the root of the Windows directory and found a lot of messages that related to the BIT (Background Intelligent Transfer) service:

2011-02-06    20:24:17:829     864    124c    DnldMgr    WARNING: Suspend failed with 0×80200002.  Continuing.
2011-02-06    20:24:18:204    10136    22ec    COMAPI    >>–  RESUMED  — COMAPI: Download [ClientId = WindowsUpdate]
2011-02-06    20:24:18:204    10136    22ec    COMAPI      – WARNING: Download call aborted
2011-02-06    20:24:18:204    10136    22ec    COMAPI      – WARNING: Exit code = 0x80240FFF; Call error code = 0x8024000B

Resolution 

After a bit of researching we found a very useful tool that is part of the Windows 2003 Support Tools pack:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=96a35011-fd83-419d-939b-9a772ea2df90&displaylang=en

The name of the utility is bitsadmin. This command line utility gives you control over the BIT’s jobs that are running such as the Windows updates.

First download both the msi and the cab file to the same folder, then run the msi file to install them (The download above will work on both 32 and 64 bit systems). Once installed go to the Start Menu –> Windows Support Tools –> Command Prompt

In the command prompt run the following command to see what jobs may be stuck:

bitsadmin /list /allusers

You will see an output similar to this:

What we need to do is kill off all of the jobs that are suspended and get Windows Update to start from scratch. To kill off the list of jobs put in the following command line:

bitsadmin /reset /allusers

As we want the Windows Updates to start from scratch it is also a good idea to delete the contents of the following folder:

C:\WINDOWS\SoftwareDistribution\Download

After you have done this re-launch Windows Update and the updates should download and install without any issues.

Summary

1. Run bitsadmin /list /allusers to see if there are any BITs jobs stuck (If not there download and install Windows Support Tools)

2. Run bitsadmin /reset /allusers to kill off all BITs jobs

3. Clear out contents of directory C:\WINDOWS\SoftwareDistribution\Download

4. Re-run the Windows Update Client

We recently encountered an issue were a Windows Server 2003 SP2 machine was running critically low on disk space on the C: drive. We deleted the temp files, dump files and cleared the Software Distribution\Download folder as stated in my colleagues post (http://support.risualblogs.com/blog/2009/10/14/running-low-on-disk-space-on-a-drive/). To free up some additional space, the C:\Windows\ServicePackFiles folder can be moved to another drive. Users are cautious of editing files in the Windows directory and rightly so, however the ServicePackFiles is safe to move. This folder contains the contents of the SP1/SP2 disc which means the disc does not need to be inserted when installing new Windows Components. Once the folder has been moved to another drive, the following Registry Keys need to be updated so Windows references the correct location for SP files, HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup:

ServicePackSourcePath and ServicePackCachePath

  Please see the below Exchange PowerShell command. It’s a nice, quick and simple way to find out the following information about your Exchange Databases

• Available Whitespace
• Log File Path
• Database Path
• Version of Exchange
• When last backup of exchange occurred

“Get-MailboxDatabase -status |  fl  Server,Name,AvailableNewMailboxSpace,edbfilepath, logfolderpath, Exchangeversion, lastfullbackup”