Problem:
In Microsoft SQL Server 2005, you receive the following error message when you run a maintenance plan:

Execution failed. See the maintenance plan and SQL Server Agent job history logs for details.

In the log file of the maintenance plan, the following error message is logged:

Failed:(0) Alter failed for server 'ComputerName\\InstanceName'.

Cause:
This error occurs if you set the Allow Updates option to 1. If you run a trace in SQL Server Profiler when this problem occurs, the following statement is captured in the "SQL:BatchStarting" and "SQL:BatchCompleted" event classes.

EXEC sys.sp_configure N’user options’, 0 RECONFIGURE

Solution:
Set the allow updates option to 0 before you run a maintenance plan in SQL Server 2005.
To set the allow updates option to 0, run the following statement.

sp_configure 'allow updates', 0
reconfigure with override

________________________________________

TechNote Written by: Brad Maust, PlanetMagpie Consulting Services
July 27, 2008

Problem:
While using the Outlook Client from Microsoft Dynamics CRM, a message appears in the Task Manager saying "Connection to CRM Lost."  The user finds that they are still connected; all the integration features in the Outlook Client still function.

Cause:
This is caused by a rare bug in CRM authentication for IIS.

Solution:
In order to remove this error message, you must reconfigure your IIS settings.

• Go to IIS > Microsoft Dynamics CRM > _imgs.
• Right-click the _imgs folder and click Properties > Directory Security.
• Under Authenticate and Access Control, click Edit.  Check "Enable anonymous access".

TechNote Written by: Will Pritchard, PlanetMagpie W3 Services
April 7, 2008

Problem:
When using a Cisco 2801 Integrated Service Router with a SIP telephony system, International calls may not go through. This may be due to the router not being configured properly to recognize the call type.

Troubleshooting:
To troubleshoot this, on the 2801 do the following to enable debugging:

1. Telnet to the router and enter privileged mode.
2. Enter the following commands:
   1. Config terminal
   2. No logging console
   3. Logging buffer 99999 debug
   4. Service timestamps debug datetime msec
   5. End
   6. Debug isdn q931
   7. Debug voice ccapi inout
   8. Debug ccsip message
   9. Clear log

Dial the international number from a SIP telephone station. After the call has failed, hang up and enter the following command:

1. Undebug all 
2. Show log

View the log file and find the section with the international number that was dialed as follows:

----- ccCallInfo IE subfields -----
cisco-ani=4085551212
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=0
dest=011449708807125
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFF
cisco-rdn=
cisco-rdntype=0
cisco-rdnplan=0
cisco-rdnpi=0
cisco-rdnsi=0
cisco-redirectreason=-1

Search a little lower in the log and you’ll see a section similar to the following:

Calling Party Number i = 0x2180, '8005551212'
Plan:ISDN, Type:National
Called Party Number i = 0x91, '011449708807125'
Plan:ISDN, Type:International

This tells you the relevant classification information. Here we can see that the number is recognized as International and it is using the ISDN plan; however if we search a little lower in the log we see the following:

*Nov 3 00:48:17.320: ISDN Se0/1/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8592
Cause i = 0x809C - Invalid number format (incomplete number)
*Nov 3 00:48:17.324: //9509/5B428671B6A7/CCAPI/cc_api_call_disconnected:
Cause Value=28, Interface=0x64C77424, Call Id=9509
*Nov 3 00:48:17.324: //9509/5B428671B6A7/CCAPI/cc_api_call_disconnected:
Call Entry(Responsed=TRUE, Cause Value=28, Retry Count=0)

And a little lower still we see the following:

*Nov 3 00:48:17.332: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 484 Address Incomplete

The important messages here are highlighted. These tell us that the PSTN does not like the information it is getting from the SIP gateway on Interface ISDN Serial0/1/0:23. Enter the following to view the running configuration:

1. Show run

Search for the Serial ISDN Interface similar to the following:

interface Serial0/1/0:23
no ip address
isdn switch-type primary-ni
isdn incoming-voice voice
no cdp enable

Solution:
You must map an address with 011 as the starting characters to this interface and classify the call type. To do this, enter the following while in privileged mode:

1. conf t
2. int serial 0/1/0:23
3. isdn map address ^011.* plan unknown type international
4. end

This has just created a mapping for all numbers beginning with 011 to stop using the ISDN plan and to be classified as international. The running configuration for the serial interface should now look similar to the following:

interface Serial0/1/0:23
no ip address
isdn switch-type primary-ni
isdn incoming-voice voice
isdn map address ^011.* plan unknown type international
no cdp enable

After this mapping is added, international calling should complete successfully.


Tech Note Written by: PlanetMagpie IT Consulting Services
November 3 , 2005

Problem:
When a user in your Exchange Server organization sends meeting requests, tasks, or standard email messages to a group of users or one user in particular, they receive the following message:

Your message did not reach some or all of the intended recipients. 

    Subject: Subject of Message 
    Sent: MM/DD/YYYY H:MM AM/PM 

    The following recipient(s) could not be reached: 

    John Doe on MM/DD/YYYY H:MM AM/PM 

    The e-mail account does not exist at the organization this message was sent to. Check the e-mail address, or contact the recipient directly to find out the correct address. 

    <yourexchangeserver.yourdomain.com #5.1.1>

The user listed, “John Doe” in this case, is not the user the message was sent to and is a user that is no longer with the company and whose account has been deleted or disabled.

Cause:
This NDR occurs because the user, "John Doe", is listed as a delegate on the mailbox the appointment, task, or message was sent to and the user account, "John Doe", has been deleted or disabled.

Solution:
In order to work around this issue a proper user removal policy will need to be put in place which will allow you to completely avoid this problem in the future. Before deleting a user from Active Directory or disabling their user account you can run the following LDIFDE command to find all users that have been delegated access as well as list any mailboxes on which delegated access has been granted.

ldifde -f nameofoutputfile.txt -d "ou=desiredou,dc=yourdomain,dc=com" -l name,publicDelegates,publicDelegatesBL -r "(|(publicDelegates=*)(publicDelegatesBL=*))"

Using this information you can first remove the delegate permissions on users mailbox's that have a user account listed in their delegate permissions that are about to be deleted or disabled. If the user that is about to be deleted or disabled is also listed in the “Send On Behalf” permissions this will need to be removed as well before removing or disabling the user account in Active Directory.

If for some reason you have deleted the users Active Directory account before removing the delegate information you will not be able to remove the delegate permissions on a users mailbox. In order to remove the permission and the "Send On Behalf" permission you will first have to recreate the user account and email account using the same userID and email address as before. After this is done you can go in and remove the delegate as well as the "Send On Behalf" permissions if necessary. 


Tech Note Written by: PlanetMagpie Consulting Services
May 10, 2006

Problem:
Email replies sent to local email addresses after a domain change or email server conversion do not reach their intended destinations. Outlook receives an NDR (Non-Delivery Report) message with the following text:

"Delivery has failed to these recipients or distribution lists: The recipient’s email address was not found in the recipient’s email system."

Email works fine when sent to external addresses or newly addressed local recipients.

Cause:
Email objects created after the email conversion cannot automatically connect to pre-conversion objects in the same directory.

Solution:
Each "stale" email object must have a manual connection made between its old X.500 address and the new email object. Afterward, the Exchange Address Book must be forced to renew all its address connections.

Solution must be adjusted to the specific situation, so the full procedure is not posted here. Please contact PlanetMagpie for further specifics.

TechNote Written by: Brad Steffen, PlanetMagpie Consulting Services
April 8, 2008

Microsoft Office Communication Server 2007 R2 servers require certificates for several authentications between servers. SharePoint servers do too. These certificates require keys in order to maintain their security.

This post will give a solution for a cert error that pops up occasionally: When OCS or SharePoint fails to detect your cert's private key.

1. When setting up a new certificate for Office Communication Server 2007 R2 or SharePoint, you may receive this error.
   
   "CertEnroll::CX5090Enrollment::p_Install Response: ANS1 bad tag value met. 0x8009310b (ASN: 267)"
   
   
   This error is most likely caused by a missing Private Key on the certificate you're attempting to install.
2. In order to resolve this issue, access the MMC for certificates.
   
   
   Select the certificate you are trying to install and view its Properties. Select the Details view and copy the Serial Number you find there to Notepad.
   
   
3. Once you have it in Notepad, remove the blanks between the numbers. So it looks like this:
   
   

    

4. Once that's done, run the command certutil to append this now-corrected Private Key to the certificate. Enter the command as follows:
   
   "certutil –repairstore my (insert serial Number)"
   
   An example screenshot is below.
   
   
5. Once this repair finishes running, the certificate will be ready to use in your installation.

Save this private key, along with its relevant cert name, in another location. Just in case OCS or SharePoint prompts you for it again.

Problem:
After being connected to a server in a foreign domain, you try to connect to the server by typing \\servername in run and click OK. You receive the following error:

"\\ServerName is not accessible. You might not have the right permission to use this network resource. Contact the administrator of this server to find out if you have access permissions"

"The referenced account is currently locked out and may not be logged on to."

If you type "net use /d *" at the command prompt, and confirm you would like to remove all connections, and try to connect to the server again, you receive the same error, and do not get the chance to enter any credentials. You view the domain account being used and discover that the account is neither locked out, nor is the password expired.

Cause:
This typically occurs when you are connected to a server in another domain, and the credentials you are using in that domain have been updated. It is also possible for this to occur, when the computer is frequently connected to, and disconnected from the physical network. The reason the error message is displayed is that the computer is attempting to connect to the server with invalid credentials.

Solution:
To successfully reconnect to the server, open a command prompt and type the following:

"net use \\ServerName\IPC /u:Domain\UserName"

After pressing enter, you will be prompted for as follows:

"The password or user name is invalid for \\ServerName\IPC."

"Enter the password for ‘Domain\UserName’ to connect to ‘ServerName’:

Enter the password for the account used, and you will receive:

"Command Completed Successfully"

After doing this, go to Start>>Run, and type \\ServerName, and click OK and you will be able to connect to the server.

 

Tech Note Written by: PlanetMagpie Consulting Services
February 6, 2006

Problem:
A Word 2007 document is received with changes you made data still visible, despite your deleting them with Track Changes beforehand. The document displays redlined text, sensitive information you thought you removed, etc.

Cause:
This is caused by hidden data being preserved in Word. Comments, Tracked Changes, the author's name...Word sometimes preserves all these until each are specifically deleted. Or cleared.

In order to purge a Word document of its hidden data, you must check several areas of the document's structure to make sure what you deleted stays deleted.

Solution:
You may not need to use all these steps every time. Try each in order, and stop when they work in removing the hidden data.

1. Edit the Document's Properties (Author Information, Comments, etc.)
   To edit a document's Properties, click the Office Button (top left). Select Prepare > Properties. A Document Properties Toolbar will display, showing fields for Author, Title, Subject, Keywords, Category, Status and Comments. Delete or edit any information shown.
2. Remove Tracked Changes Manually
   To turn Track Changes on/off, click the Review tab. Click the down arrow on Track Changes. Click Track Changes in the below menu to turn tracking on or off.
   Tracked changes in a document remain, even after you've turned Track Changes off. Each must be accepted or rejected in order for Word to delete them.
   
   
   1. To manually Accept or Reject a change, click Accept or Reject under the Changes group on the Review tab. Then click Next to jump to the next tracked change.
   2. To accept all changes, click the down arrow under Accept in the Changes group. Click on Accept All Changes in Document.
   3. To reject all the changes, click the Reject down arrow. Select Reject All Changes in Document.
3. Use the Document Inspector to Wipe All Hidden Data
   This is the most severe step to removing any and all hidden data. If you think hidden data might still be lingering, use this.
   
   
   1. Open the Document Inspector. Click on the Office Button. Select Prepare > Inspect Document.
   2. Select all options in the Document Inspector (like the screenshot below). Click Inspect.
      
      
   3. If any items are found, you will be given the option to remove them. Click Remove All to remove all hidden data for each item. Once you're done, click Close and save your document.

________________________________________
Tech Note Written by: PlanetMagpie Network Support Team
January 16, 2009

Problem:
When setting mailbox size limits such as "Issue Warning", "Prohibit Send", or "Prohibit Send & Receive" using Exchange 2003 System Polices or by setting a limit directly on a user’s account in Active Directory, it is not possible to set a size limit greater than 2097151KB due to a restriction in the GUI. If you try to enter a number larger than 2097151 you receive the message:

"The value for 'Issue warning at (KB)' is not valid. Specify a value from 0 through 2097151."

One may argue that it would never be necessary to set a limit great that 2GB for a mailbox, however, the reality is that in today’s email enabled world mailboxes are getting larger and larger, plus it is hard to argue when Google is giving away mailboxes with 2.5GB of space!

As a consultant one of the my problems with not being able to set a limit great than 2097151 has been in situations where I have came into a company to re-architect their Exchange system and half the company has reasonably sized mailboxes and the other half have mailboxes as large as 15GB, yes, you heard me right, 15GB!!!! Sometimes management is unwilling to force these people to cleanup their mailboxes overnight so it is a long process. In these situations I certainly do not want those users mailboxes getting any larger than they are already so I set a limit just above the current size of the mailbox to make it painful for them to keep so much mail and eventually they give in and cleanup their mailbox.

Solution:
Mailbox storage limits cannot be set above 2097151 using the GUI, however, using the tool ADSIEdit a mailbox storage limit larger than 2097151 can be set. ADSIEdit is a very powerful tool and should be used with extreme caution!

Using ADSIEdit to Modify System Policies Mailbox Storage Limits

1. Add ADSIEdit to the MMC and bind to the domain using the Configuration well known naming context.
2. Navigate to the Services Container, MicrosoftExchange, ExchangeOrgName, AdministrativeGroups, AdministrativeGroupName, & click on the Policies folder. 
3. In the right hand side of the ADSIEdit window find the name of the policy you want to modify and double click on it.
4. Scroll through the list of attributes until you see the attribute you want to modify, the attributes in question are:
   mDBStorageQuota: Issue warning at (KB)
   mDBOverQuotaLimit: Prohibit Send at (KB)
   mDBOverHardQuotaLimit: Prohibit Send and Receive at (KB)
5. Double click the attribute you are going to modify and enter a size limit of your choice, keep in mind that limits are in KB, once you are finished simply close ADSIEdit and you are done.

Using ADSIEdit to Modify Mailbox Storage Limits on a Single User

1. Add ADSIEdit to the MMC and bind to the domain using the Domain well known naming context.
2. Navigate to the location of the user account that you want to modify.
3. In the right hand side of the ADSIEdit window find the name of the policy you want to modify and double click on it.
4. Scroll through the list of attributes until you see the attribute you want to modify, the attributes in question are:
   mDBStorageQuota: Issue warning at (KB)
   mDBOverQuotaLimit: Prohibit Send at (KB)
   mDBOverHardQuotaLimit: Prohibit Send and Receive at (KB)
5. Double click the attribute you are going to modify and enter a size limit of your choice, keep in mind that limits are in KB, once you are finished simply close ADSIEdit and you are done.

Tech Note Written by: PlanetMagpie IT Consulting Services
December 9, 2005

Problem:
When migrating a mailbox from one data store to another using the Move Mailbox function in the Exchange Tasks Wizard and the move fails for some reason, it is possible that the new mailbox will be created and left in a disconnected state in the destination database. When an attempt is made to purge the mailbox from the data store, the operation fails and the following error is displayed:

"The operation cannot be performed because this mailbox was already reconnected to a existing User. ID no c1048af9"

Cause:
When moving a mailbox from one data store to another, Exchange actually creates a mailbox in the new store, copies all information from the source box to the target box, then upon successful completion, the source box is removed. All sensitive account identification information is also moved in the process. Sometimes when a move fails (due to something such as a login timeout, etc), the process cannot finish and the target mailbox is created in the new store, but it is not complete. Exchange did not finish the task so the source mailbox remains and is fully operational. The target mailbox also remains, but is disconnected. The mailbox is tied to the same DN and thus cannot be purged in the traditional fashion.

Resolution:
To remove the failed mailbox, simply run the Mailbox Move operation again to the same target data store. The move operation will fail because it sees that a mailbox with the same name as the one being created exists. Before ending the process, Exchange will remove the duplicate mailbox from the target store. After this has been completed, a new Mailbox Move operation can be completed.


Tech Note Written by: PlanetMagpie IT Consulting Services
August 10, 2005

Problem:
The MOM SQL management pack produces no results when using the all failed logins by count. While All Successful Logins by Count produces meaningful results.

Cause:
The MOM SQL script (All Failed Logins by Count.rdl) queries for Event ID 17055 with description of 18452. The error number 18452 ( Login failed for user '%ls'. Reason: Not associated with a trusted SQL Server connection) does not exist, hence produces no results.

Solution:
The error number 18452 ( Login failed for user '%ls'. Reason: Not associated with a trusted SQL Server connection) is not produced in some cases. Therefore the MOM SQL script must be customized to capture the desired error number. There are several failed login error numbers one may wish to capture. For SQL server 2000, it is referenced on MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_syserrors2_7bsp.asp

There are few ways to edit the MOM scripts. One method is to login into the reporting manager web root -- Locate the report "All Failed Logins by Count" -- Choose the properties tab -- select "Edit" and open it with a text editor. Locate the word 17055 and you will see the error number 18452 as part of the query argument. You may change the error number to a desired number or you can use wild card to capture several error descriptions at the same time. The syntax would be as follow. %1845[26]% This will capture error description of 18452 and 18456.


Tech Note Written by: PlanetMagpie IT Consulting Services
November 11, 2005

Problem:
In the event log of your domain controllers in a Windows 2000 or Windows 2003 domain you are receiving several of the following error messages with Event ID 11 generated by the KDC.

There are multiple accounts with name ServiceClass/host.domain.com of type DS_SERVICE_PRINCIPAL_NAME

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Cause:
This error can be caused when the Service Principal Name (SPN) has been registered incorrectly for a service running on a server. Each service that uses Kerberos authentication needs to have an SPN set for it so that clients can identify the service on the network. The SPN is registered in Active Directory under a user account as an attribute of the user account called a servicePrincipalName.

The above error typically indicates that ServiceClass/host.domain.com has been registered as an SPN on more than one Active Directory User Account. This typically happens when a service is set to start with a different service account and setSPN is used to add the new SPN but the old SPN is not removed. In general, only one SPN should be set for each service. Multiple SPNs can cause clients to connect to the wrong system or the ticket may be encrypted with the wrong key.

Solution:
To enable the service to authenticate properly, you need to make sure that the service has only one SPN. In order to do this first we need to find which accounts have the duplicate SPNs and then delete one of them. The easiest way to determine which account the ServiceClass SPN should be registered under is to identify the service account under which the service starts. For instance if the service class & hostname is MSSQLSvc/hostname.domain.com then logon to hostname.domain.com and verify which account SQL Server services are using to start with, this is the account that the SPN should be registered to.

To generate a list of accounts that the SPNs are registered to, run the following command at the command prompt.

1. From the domain controller, open a command prompt and then type the following string:
   ldifde -f domain.txt -d "dc=domain,dc=com"
2. Open the text file in Notepad and then search for the SPN that is reported in the event log.
   ServiceClass/host.domain.com
3. Note the user accounts under which the SPN is located and the organizational unit the accounts reside in...the userPrincipalName should be located directly above the servicePrincipalName registration as in the example below.
   userPrincipalName: useraccount@domain.com
   servicePrincipalName: ServiceClass/host.domain.com

Use one of the following options to delete the account SPN registrations from the accounts that should not contain registrations to ServiceClass/host.domain.com. (i.e. Typically any accounts containing an SPN registration for SeriviceClass/host.domain.com that services are not explicitly starting with)

Using ADSIEdit

1. Add ADSIEdit to the MMC and bind to the domain using the Domain well known naming context.
2. Navigate to each user account you previously documented as having a duplicate SPN registration and right click the account and select properties.
3. Scroll through the list of attributes until you see servicePrincipalName, double click servicePrincipalName and remove the duplicate SPN registration and click on OK and exit ADSIEdit.

Using SetSPN

1. From the command prompt type the following command and hit enter. setspn -D ServiceClass/host.domain.com:Port AccountName

Tech Note Written by:  PlanetMagpie Consulting Services
June 2, 2005

Problem:

Windows Server 2008 R2 Service Pack 1 included many updates and security patches. Among them was KB2667402, a security patch for protecting Terminal Server against Denial of Service (DoS) vulnerabilities.

However, after applying this patch, remote access via Remote Desktop Protocol (RDP) will fail under certain conditions. Effectively cutting the administrator off from the server once SP1 is fully applied.

Solution:
This problem stems from a version issue with the KB2667402 included in Service Pack 1. It has older binaries which cause the disruption in RDP.

In order to resolve the issue, make sure you have access to the Windows server via another method than RDP before applying Service Pack 1. For instance, LogMeIn.

If RDP fails, you will need to uninstall KB2667402 using your alternate access method.

Microsoft has released a patch which will download after the SP1 update and resolve the KB2667402 issue. Search for KB2667402 and install the updated version. Reboot, and test RDP again.

Tech Note Written By: Larry Garcia, Network Engineer
July 13, 2012

Problem:
After PGP is loaded onto a Dell E6420-model laptop, the operating system fails.

Privacy-minded customers sometimes install a Symantec product called PGP (stands for "Pretty Good Privacy") on their computers. PGP protects important files by encrypting them before transmission occurs. A public key is used for decryption once the files arrive at their destination.

PGP is commonly used to:

• Encrypt emails, so their contents are not visible to anyone else during send.
• Encrypt whole hard disks for complete data protection.

When PGP is installed on a Dell E6420-model laptop, the operating system fails to load upon reboot.

Cause:
This is a confirmed issue with the PGP software below version 10.1. It is discussed by users and the developers here: http://www.symantec.com/connect/forums/dell-e6420-and-pgp#comment-5583361

Solution:
Symantec is aware of the issue and has a fix available. However, it's only available to users who first call into Symantec Tech Support and report the issue. Users can call Symantec tech support at 800-634-4747, where they'll be given instructions on how/where to download the fix.

PGP 10.1 Service Pack 3 contains an upgrade that will prevent this issue from occurring in the first place.

If you haven't installed PGP on your computer yet (and plan to), make sure you have version 10.1 Service Pack 3 or later.

Tech Note Written by: Dennis Stroble, Network Engineer August 5th, 2011

Problem:
Your spam continues to rise in volume. Customers report they are receiving spam emails with your email addresses in the headers. Company policy is not to give email addresses out, yet they are found by spammers.

Cause:
You have unprotected email addresses listed on your website. Spammers are harvesting these emails using bot scanners. These are small, automatically-run applications which scan an entire website for the email structure (Name@Company.com).

Solution:

1. Remove any unnecessary emails from your website. Replace with contact forms, using Javascript or .NET.
2. Encode any remaining emails using an HTML encoder application. PlanetMagpie provides one such application free, located here:
   
   PlanetMagpie Email Encoder
   
   This application translates an email address into an HTML-based language format spammers can't harvest. The resulting code is put in place of the email address in the website's HTML link.

NOTE: In order to avoid any chance of spammers harvesting your email by directly looking at your website, change the text of email links to avoid listing the full address. For example, don't put, "Email me at EmployeeQ@CompanyX.com" on the site. Instead, write, "Email Mark Here."

________________________________________

TechNote Written by: PlanetMagpie W3 Services
September 2, 2008

Originally posted on the "Outlook by the Sound" blog, November-December 2006.

Problem:
A user experiences continuous problems with the SharePoint Services (free version) logon screen. It keeps popping up as the user navigates between documents. The user is able to continue by clicking either "Okay" or "Cancel," but the popup window persists. The URL is in the Trusted Zone, and set to "Logon with current username and password."

The server group reported that SharePoint Service Pack 2 is installed, and the server has been rebooted. The logon request window persists.

Cause:
The user and their clients may have encountered a bug in how Internet Explorer handles Windows Integrated Authentication. If the links used are "shortname" (i.e. http://sharepoint/), Internet Explorer will transparently pass the current Windows account/password context to the web server. However, if the links used are FQDN (Fully Qualified Domain Names, i.e. http://sharepoint.yourdomain.com), Internet Explorer will force an authentication prompt.

Solution:
Relative links will keep the original DNS name (and domain extension if provided) used to connect to the portal or top-level site. Hard links override whatever was used initially with whatever was provided in the link. In the case of an FQDN hard link, this will cause a new authentication challenge from Internet Explorer.

Additional information:
http://support.microsoft.com/?id=815141

TechNote Written by: Brad Steffen, PlanetMagpie Consulting Services
December 18, 2006

Problem:
The 4 internal SQL server databases that manage the information about client databases hosted by SQL Server 2005 ("master" databases) became corrupted. When we couldn't recover the corrupted databases, we tried restoring from the nightly backup routine. Upon restoring, we found that the backups contained no new information past August 1st, 2008.

Cause:
The underlying cause of this was two similarly-named database files in use on the same server. DB1 and DB2, for example. During maintenance, these database files were swapped, DB1 going into DB2's place and vice versa.

Data entry then continued on DB2 (the wrong file), and the nightly backup routines backed up DB1 instead. No new data was saved; the backups were essentially frozen in time.

When the "master" databases broke down, the backup/restore jobs for all of the SQL databases kicked in and began restoring all databases. Restoring DB1's older data over DB2. Erasing new data input to DB2 in the process.

The problem here wasn't so much the corrupted internal database; it was the lack of up-to-date backups in the restore. This wasn't discovered until it was too late, however.

Solution:
At this point, the server was shut down for repair. We moved the available backups to a new SQL server. Once the new server was in place, we re-input data changes since August 1st, using employee backups.

Recommendation: During database maintenance, files can be moved around on SQL servers. Files with similar names, even if stored in different locations, can cause complications like this. Check all database names to avoid confusion in the future.

________________________________________
Tech Note Written by: Brent Taylor & Will Pritchard, PlanetMagpie W3 Services
November 21, 2008

Problem:
After you install Microsoft SQL Server 2005 Service Pack 2 (SP2), you use a clean-up task in SQL Server 2005. However, the clean-up task does not delete database maintenance plan reports. Additionally, you receive an error message that resembles the following:

Error: 2006-12-06 16:52:39.92
Code: 0xC002F210
Source: Maintenance Cleanup Task 1 Execute SQL Task
Description: Executing the query "EXECUTE master.dbo.xp_delete_file 1,N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\sdtest.txt' " failed with the following error: "Error executing xp_delete_file extended stored procedure: Specified file is not a Maintenance Plan report file." Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
End Error Warning: 2006-12-06 16:52:39.92 Code: 0x80019002 ... The package execution failed ... The step failed.

Cause:
This problem occurs because the first line of the report contains the following text:
NEW COMPONENT OUTPUT
The "xp_delete_file system" stored procedure examines the first line of the report to determine whether it's a database maintenance plan report or not. If the first line reads, "NEW COMPONENT OUTPUT," the "xp_delete_file system" stored procedure cannot recognize the report as a database maintenance plan report.

Solution:
To resolve this problem, obtain Cumulative Update Package 2 for SQL Server 2005 Service Pack 2. The Microsoft Knowledge Base article on how to obtain Cumulative Update Package 2 is here:

936305 (http://support.microsoft.com/kb/936305/) Cumulative Update Package 2 for SQL Server 2005 Service Pack 2

Workaround: To work around this problem, delete the first line of the report if the first line is, "NEW COMPONENT OUTPUT." The report will be deleted the next time you use the clean-up task.

________________________________________

TechNote Written by: Brad Maust, PlanetMagpie Consulting Services
July 27, 2008

Problem:
Could not view all the templates available in Microsoft Visual Studio 2005 after installation.

Cause:
Visual Studio 2005 does not always install the Web Application projects during setup, even though they are mentioned on the list of component installations. If this occurs, even installing Visual Studio 2005 SP1 may not complete the template installations.

Solution:
Install the following Microsoft utilities to provide the missing components.

1. VS80-KB915364-X86-ENU.exe:
http://download.microsoft.com/download/8/0/8/8086c312-16b1-4e54-a4cc-80a6c171112e/VS80-KB915364-X86-ENU.exe

2. WebApplicationProjectSetup.msi:
http://download.microsoft.com/download/9/0/6/906064ce-0bd1-4328-af40-49dca1aef87c/WebApplicationProjectSetup.msi

________________________________________

Tech Note Written by: Shagun Kakkar, PlanetMagpie W3 Services
October 10, 2008