We are currently looking for an exceptional 1st line support engineer to expand our team. An excellent communicator, you will be experienced in desktop hardware and software with proven troubleshooting skills.

Microsoft SharePoint Foundation 2010 Service Pack 1 (SP1) was recently released through Microsoft Update. Since SharePoint Foundation 2010, patching SharePoint is a two-step process. The updated binaries are first installed and then PSCONFIG must be completed to update the SharePoint databases.

The Technical Bit….

Without completing PSCONFIG, you might experience unexpected SharePoint search failures and all backups may stop working on the affected server.

The Following errors may be found in the server application log:
Log Name: Application
Source: Microsoft-SharePoint Products-SharePoint Foundation Search
Event ID: 70
Task Category: Gatherer
Level: Error
User: CONTOSO\spsearch
Computer: CONTOSO-SERVER.contoso.local
Description:
The mount operation for the gatherer application 37ad8233-57f1-47b1-873e-6a91d0f1bc36 has failed because the schema version of the search administration database is less than the minimum backwards compatibility schema version supported for this gatherer application. The database might not have been upgraded.

Log Name: Application
Source: Microsoft-Windows-Backup
Event ID: 521
Level: Error
User: SYSTEM
Description:
The backup operation that started at ‘?2011?-?07?-?06T02:12:07.198000000Z’ has failed because the Volume Shadow Copy Service operation to create a shadow copy of the volumes being backed up failed with following error code ’2155348129′. Please review the event details for a solution, and then rerun the backup operation once the issue is resolved
You can also run the following commands to determine if you need to complete the update process with PSCONFIG:
• Launch an elevated (Run as Administrator) SharePoint 2010 Management shell from start, All Programs, Microsoft SharePoint 2010 Products, SharePoint 2010 Management Shell.
• Once the shell opens, type the following command followed by enter:
(get-spserver $env:computername).NeedsUpgrade
• If the result of this command is True, then you need to complete the steps below. If the result is False then no further action is needed, if you are encountering similar events the cause will most likely not be resolved by the following steps.

The Fix….

To complete the SharePoint service pack process you need to follow the same steps Below.In order to update the SharePoint databases, you must manually run the PSconfig utility. To run the utility:
1. Open an Administrative command prompt.
2. Change directory to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN
3. Run PSConfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures

Note: The Companyweb site will be inaccessible while the command is running. It is best to run the command after business hours. The amount of time the command takes to run will vary on the size of the database and the speed of the machine. On a reference machine with 8 logical processors, 32GB of RAM and a 2GB content database, the command took approximately 5 minutes to execute.

You receive error code 0x8007F0DA when using the Windows Update Web site or the Microsoft Update Web site to install updates.

The Technical Bit….

What is causing the issue?
This issue occurs if Windows Update or Microsoft Update cannot verify the update.inf file.

The Fix….

regsvr32 /u softpub.dll /s
regsvr32 /u wintrust.dll /s
regsvr32 /u initpki.dll /s
regsvr32 /u dssenh.dll /s
regsvr32 /u rsaenh.dll /s
regsvr32 /u gpkcsp.dll /s
regsvr32 /u sccbase.dll
regsvr32 /u slbcsp.dll /s
regsvr32 /u mssip32.dll /s
regsvr32 /u cryptdlg.dll /s

net stop cryptsvc
cd %systemroot%\system32
ren catroot2 catroot2old
net start cryptsvc

The Microsoft Knowledge Base Article….

http://support.microsoft.com/kb/958050

You receive an Event ID 1827:
CREATE DATABASE or ALTER DATABASE failed because the resulting cumulative database size would exceed your licensed limit of 4096 MB per database.

The Technical Bit….

This occurs because the SBSMonitoring database is close to the 4096mMB size or exceeded it.

The Fix….

There are 2 options
Shrink Database
Please follow these steps:
Step 1: Download the following file to the server you are going to be working on:
1. http://cid-d5fe25afb6c3615f.skydrive.live.com/self.aspx/.Public/updateSBSMonitoring.sql
2. I recommend you save the file to an easy to access path, such as c:\windows\temp.
Step 2: Complete a backup of the SBSMonitoring Databases
1.Open Services from Administrative Tools, Services
2.Accept the UAC prompt
3.Find and stop the SQL Server (SBSMONITORING) service.
4.Make a copy of the files in the following folder:
C:\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\Data
5. Once the file backup is completed, start the SQL Server (SBSMONITORING) service.
Step 3: Proceed to run the following set of commands to implement the improvements
Open an Administrative Command Prompt (Run As Admin)
Type the following command, substitute the path to the updateSBSMonitoring.sql file as needed (We recommend that you do NOT copy & paste this command directly from the blog post):
Sqlcmd -S %computername%\SBSMonitoring -E -i c:\windows\temp\updateSBSMonitoring.sql
2.Success will show an output like this:
Changed database context to ‘SBSMonitoring’
(1 rows affected)

Replace with a blank database
If you do not want to keep monitoring data, please follow these steps;
1. Run services.msc.
2. Stop SQL Server(SBSMONITORING) service (To be able to unlock monitoring database files)
3. Change the name of those 2 files in case you will use them in the future or delete them when all ok:
C:\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SBSMonitoring.mdf
C:\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SBSMonitoring_log.ldf
to
C:\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SBSMonitoring-bak.mdf
C:\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SBSMonitoring_log-bak.ldf
4. Download http://cid-6ca40dd0d4c9caa6.skydrive.live.com/self.aspx/.Public/sbsmonitoring.zip file.
5. Unzip the zip file and copy those two files to C:\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\Data\ folder
6. Start the SQL Server(SBSMONITORING) service

An issue has recently been discovered with iSCSI on ESXi 5.0 which is resulting in very slow boot times for the ESXi 5.0. In ESXi 5.0, the iSCSI boot-up code has been modified to retry 9 times (versus no retry in 4.x) when running iSCSI discovery and login for the configured target
Symptoms
• ESXi 5.0 experiences a delay when booting during the the software-iscsi step.
• After the boot process completes, the sysboot.log file contains entries similar to:
[01:57:50.925338] sysboot: software-iscsi
[02:28:22.330320] sysboot: restore-paths
• After the boot process completes, the syslog.log file contains entries similar to:
iscsid: cannot make a connection to 192.168.1.20:3260 (101,Network is unreachable)
iscsid: Notice: Reclaimed Channel (H34 T0 C1 oid=3)
iscsid: session login failed with error 4,retryCount=3
iscsid: Login Target Failed: iqn.1984-05.com.dell:powervault.md3000i.6002219000a14a2b00000000495e2886 if=iscsi_vmk@vmk8 addr=192.168.1.20:3260 (TPGT:1 ISID:0xf) err=4
iscsid: Login Failed: iqn.1984-05.com.dell:powervault.md3000i.6002219000a14a2b00000000495e2886 if=iscsi_vmk@vmk8 addr=192.168.1.20:3260 (TPGT:1 ISID:0xf) Reason: 00040000 (Initiator Connection Failure)

The Technical Bit….

This issue occurs because ESXi 5.0 attempts to connect to all configured or known targets from all configured software iSCSI portals. If a connection fails, ESXi 5.0 retries the connection 9 times. This can lead to a lengthy iSCSI discovery process, which increases the amount of time it takes to boot an ESXi 5.0 host.

The Fix….

To minimize the amount of time the boot process spends discovering iSCSI targets, you can reduce the number of network portals and the number of targets.

To list the current number and configuration of an ESX host’s network portals, run the command:

esxcli iscsi networkportal list

The output is similar to:

vmhba34:
Adapter: vmhba34
Vmknic: vmk6
MAC Address: 00:1b:21:59:16:e8
MAC Address Valid: true
IPv4: 192.168.1.206
IPv4 Subnet Mask: 255.255.255.0
IPv6:
MTU: 1500
Vlan Supported: true
Vlan ID: 10
Reserved Ports: 63488~65536
TOE: false
TSO: true
TCP Checksum: false
Link Up: true
Current Speed: 10000
Rx Packets: 656558
Tx Packets: 111264
NIC Driver: ixgbe
NIC Driver Version: 2.0.84.8.2-10vmw-NAPI
NIC Firmware Version: 0.9-3
Compliant Status: compliant
NonCompliant Message:
NonCompliant Remedy:
Vswitch: dvSwitch0
PortGroup: DvsPortset-0
VswitchUuid: 26 46 30 50 c0 cf df 1e-52 ef ab d7 a2 ab 96 f9
PortGroupKey: dvportgroup-78003
PortKey: 1731
Duplex:
Path Status: active

Note: This is an example of one network portal (HBA34).

To list currently running targets, run the command:

vmkiscsi-tool -T vmhba#

The issue is well understood by VMware engineering and a patch is already being tested. This will fix this issue. Here is no  ETA for the patch which contains this fix yet. Unfortunately, there is no tunable parameter for the 9 iterations; it is hard-coded. The only workaround is to drastically reducing the number of targets and VMkernel ports per host, & ensure that all VMkernel ports on the host are able to log into all targets successfully.

Unable to Get Maximum Speeds from a BeThere ADSL 2+ Line on a Draytek 2800 Router

The Technical Bit….

A BeThere ADSL2+ line uses different settings to other ISP’s when setting the ADSL connection up with Routers,  The major setting differences are VPI/VCI are 0/101 (instead of 0/38) and they use MPoA instead of PPPoA.  The also use an INP (Impulse Noise Protection )setting of 2 instead of 0,0.5 or 1.  The setting of 2 is not supported by the Draytek 2800 but is however supported by the 2710, 2820 and later models.

The Fix….

The only fix available is to replace your router to a newer model. For further information go to:-
http://www.draytek.co.uk/support/kb_vigor_inp.html

After updating your server or workstations with Windows Updates, you are no longer able to start the Shadow Protect backup service.

When starting the service manually you get an error similar to:

Error: Access violation at 0x0039646F (tried to write to 0x9C70D0EA), program terminated.

The Technical Bit….

After extensive troubleshooting we’ve identified that the Microsoft patch KB2533623 is the cause of the issues.

Obviously there is a clash between the Shadow Protect service and this new security patch from Microsoft.  We’re liaising with Storage Protect to try and identify the issue at the root cause.

The Fix….

Simply uninstalling this will allow the service to restart again, though you will need to reboot the computer first to allow the service to return to full operation.

We’ll update with a revised fix when we hear more from Storage Craft.

The cupcake seemed to go down very well this with the team, especially Andrew who seemed to get a little over excited!

A Windows 7 or Vista workstation using Outlook 2007 or 2010 can’t resolve the Autodiscover address for an Exchange server.  Therefore the Offline Address Book (OAB) and Out Of Office (OOO) aren’t working, even when Outlook has been manually configured for the RPC over HTTPS settings

The Technical Bit….

Microsoft Exchange 2007 and 2010 both use a system called Autodiscover to allow for automatic configuration of Email clients, including Outlook 2007 and 2010.  However Outlook also relies on this method for connectivity to the Exchange Offline Address Book, Out Of Office settings and various of sub functions of Exchange.

In certain cases whilst the Exchange server and DNS records for Autodiscover have been correctly setup, using either A or SRV records.  Some windows workstations using Outlook 2007 or 2010 can’t correctly access the Autodiscover DNS records.

First, to clarify it is a problem with the DNS lookup of the Autodiscover records we’ll do a manual lookup:
Open a command prompt
Type ‘Nslookup’.
Then type ‘set type=all’
Then enter the DNS record for your server, if it’s an A record it’ll be ‘autodiscover.domain.com’, if it’s an SRV record it will be ‘_autodiscover._tcp.domain.com’.
This should then return the expected result.  If it doesn’t this indicates a DNS problem not the problem specified above.

Second, we’ll test the Autodiscover record through Outlook, using the ‘Test Email Autoconfiguraiton’ option.

To do this, follow the below:
Hold down ‘CTRL’ and then right click the Outlook icon in the Taskbar
The Outlook menu will appear, select ‘Test Email Autoconfiguration’ from the list, a pop up box will appear.
Untick the two ‘Guesssmart’ options.
Then enter your email address and password in the fields and press test.
This test can take a little while, but it will eventually present a result.

If the result is that the Autodiscover DNS record can’t be found, often with the error 0x80072EE7 and it’s only happening on some Windows workstations whilst others work fine, it could well be this problem.

The Fix….

Open the registry on the local workstation and navigate the below section:
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\ Outlook\AutoDiscover
Then delete the below registry entries. NOTE: it’s always a good idea to backup the registry first before making changes!
“ExcludeHttpRedirect”
“ExcludeHttpsAutodiscoverDomain”
“ExcludeHttpsRootDomain”
“ExcludeScpLookup”
“ExcludeSrvLookup”
“ExcludeSrvRecord”

You mail also find another as below, delete this as well:
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\ Outlook\AutoDiscover\RedirectServers
”autodiscover.domain.com”

Close the registry and then restart Outlook, it should now function correctly, to confirm this rerun the ‘Test Email Autoconfiguration’ with Outlook as per the above instructions.