Dom Cosgrove Blog

When you try to put your VMware virtual image into full screen on Windows 7 you may find that you get a blank black screen. Even if you change the screen resolution on the guest OS, to match that of your host OS you still get a blank screen.

The issue is that the VMware display drive has not been configured for Accelerated 3D Graphics. To resolve this issue, shut down the VM, then under VM > Virtual Machine Settings > Display check the Accelerate 3D Graphics check box and select OK. You should now be able to restart your VM and go into full screen mode.

So in the past I’ve download Virtual Machines that have a US keyboard as the input type or when I built the windows instance I forgot to change the keyboard settings. As a result when I have passwords with the ampersand symbol (@) in them, I need to use the Shift + 2 (“) keyboard stroke. So hey you can live with this setting, but I quite like having my keyboard and regional settings configured correct on the server. So this is easy enough through Control Panel > Region and Language settings. So you change your Format to English (Ireland) so that the date time is correct. You change your location for your locale setting to Ireland. You then change your Keyboard and Languages to English (Ireland) – Irish. You test typing your password in notepad and are happy that changes have been made. You then log off your computer or reboot and go to log back on… wait a minute you try your new keyboard settings and you still have to use Shift + 2 to log in. You go and open notepad again and hey presto your keyboard settings are still in English (Ireland) – Irish. What gives!?!

The solution is actually under the Region and Language > Administrative tab. There is a section for the Welcome screen and new user accounts, click the Copy Settings… button, you’ll notice that the Input Language for the Welcome Screen and the New User Accounts is still English (United States) – US. This is not what we want. Select both the check boxes to copy your current settings to the Welcome Screen and New User Accounts and click OK. Log off and back on and there you have it you can log on using the expected keyboard behaviour.

The following steps may help if you get an error when opening Office documents through MS Office Web Applications from a SharePoint Document library.

Word Web App cannot open this document for viewing because of an unexpected error. To view this document, open it in Microsoft Word.

Error Id: 68d8674b-53ac-407c-bfd7-9ef2a2c16611, 201116105124532

1. If you are running the SharePoint / Office Web Apps on a VM that also has the domain controller, you’ll get this error. This is not a supported configuration for a production environment. As this is typical for a demo / development VM, then you can run the following PowerShell:

   $e = Get-SPServiceApplication | where {$_.TypeName.Equals(“Word Viewing Service Application”)}
   $e.WordServerIsSandboxed = $false
   $e.WordServerIsSandboxed
   

   #(Please use the below script for PowerPointServiceApplication – You need to enter “Y” for the answer of each cmd)
   Get-SPPowerPointServiceApplication | Set-SPPowerPointServiceApplication -EnableSandboxedViewing $false
   Get-SPPowerPointServiceApplication | Set-SPPowerPointServiceApplication -EnableSandboxedEditing $false
   

   In the server’s c:\windows\system32\inetsrv\config\applicationHost.config
   Add the line below in the end of the dynamicTypes.
   <add mimeType=”application/zip” enabled=”false” />
   

   IISRESET
   

2. If you are seeing events with an ID of 3760 (shown below), you have not given the service account running the Office Web Application Services sufficient access. Ensure that the account has the required permissions.

Reference:

http://blogs.msdn.com/b/opal/archive/2009/11/16/installation-notice-for-sharepoint-2010-public-beta.aspx

Don’t use service account names with more than 20 characters! Why… read on!

Recently, I was working on updating the Windows SharePoint Service Help Search Accounts. The issue was that when the DEV, UAT and production farms where originally built the same service accounts were used for each environment. This is NOT best practice, so I went about changing DEV and UAT, leaving Production using the original accounts. The process of updating the service accounts is simple enough using STSADM:

stsadm –o spsearch –farmserviceaccount [domain\serviceaccount] –farmservicepassword [password]

stsadm –o spsearch –farmcontentaccessaccount [domain\serviceaccount] –farmcontentaccesspassword [password]

An issue arose where we used the original service account post-fixed with the environment e.g.

When trying to update the service accounts I kept getting the following message:

Basically, saying that the account being provided is not valid. If I did the same update through the Central Administration I got the following message:

The username and password entered are not valid.

After several rounds of changing the password, recreating the account and trying manually set the service account, it was discovered that SharePoint uses the sAMAccountName rather than the UPN when it passes credentials. The sAMAccountName has a 20 character limit for backward compatibility.

The work around is simple keep the service account names to less than 20 characters. An alternative approach, one that I’ve not tested yet is to use the following format for the account [service account]@[domain.com]. Anyway I hope that this will save you some time, I wish I had known this limitation before I embarked on updating the accounts.

Today, I was building a SharePoint 2007 demo environment using a set of scripts that I’ve used numerous times before to configure and provision the SharePoint Web applications. I made some slight adjustments to the settings to match my clients naming convention e.g. User Names, Web Application Names, Database etc. Something I’d done many times before.

I then went to navigate the SSP Administration site and got access denied no matter what account I used, SPFarm, SPAdmin, SSP Service Account, Local Administrator. I couldn’t understand it! I even deleted the SSP and recreated it doing it manually. Again I got access denied. I checked the database permissions and the AppPools, they seemed to be configured correctly.

I did some Google searches and came across Faraz Khan blog post that seemed to be getting the same issue as me. Faraz suggested creating a new Application pool, but I did not understand why I would have to, again I’d used the scripts a number of times before.

Reading through the comments I noticed that Scott had valid reason why I was experiencing this behaviour:

“DO NOT call you SSP the same name as the AppPool you use for the SSP Admin Site.

The SSP actually uses its name to create an AppPool for use under the Office Search site.

If your SSP Admin AppPool is the same name then MOSS sets it to use the timer svc account.”

I had configured the script to create a SSP called “SharedServices” and the Application Pool called “SharedServices” as per the customer request. Low and behold after deleting the MySites and SharedServices Applications, changing the application pool to be “Shared Services AppPool” everything worked as expected.

Now I know, this is nothing new and I’m sure that many people have had similar experiences, especially if they don’t use the default SSP name “SharedServices1″, but I thought that I would blog about it as I spent 2 hours trying to troubleshoot something that could have been easily avoided.

Thanks again to Faraz and Scott.

This is more for self-reference than anything else, but may come in handy for others out there.

When debugging an application in Visual studio I was setting a break point at a specific line of code. When running the application in debug mode, the breakpoint becomes a hollow red circle with a warning that says, “The breakpoint will not currently be hit. No symbols have been loaded for this document.”

One of the first things I checked was that the application was being built in debug verses release mode. It was. I also deleted the obj & bin folders.

Other things tried included:

• Deleting the ASP.Net temporary files;
• Rebuilding the project;
• Devenv.exe /ResetSettings
• Ensure that dll referenced in the GAC that are part of your custom solution are deleted;
• Copy the pdb file to the GAC where you assembly lives (C:\windows\assembly\GAC_MSIL\ <assembly_version_number>__<assembly_public_token_key>\Namespace.Project.dll)

The solution that worked for me in this instance was:

1. While debugging the application, click on Debug > Windows > Modules
2. The Modules window will show all the modules that have been loaded for the project;
3. By the module where the breakpoint is not found it will likely say that the Symbol file cannot be found or opened.
4. You can right click the module and browse to your PDB file.

Issue

When copying files to the GAC I occasionaly get the following message in the Visual Studio OutPut window on my development VPC:

Failure adding assembly to the cache: Access denied. You might not have administrative credentials to perform this task. Contact your system administrator for assistance.

Also I cannot see any assemblies in the GAC through Windows Explorer, while it is this state.

Background

When developing features for SharePoint, it is common practice to deploy only the Signed Assembly to the GAC, rather that re-deploying the whole SharePoint solution. Personally depending on the project I use one of two mechanisms:

WSPBuilder – Copy to GAC

WSPBuilder is my tool of choice for increasing productivity while developing SharePoint Solutions. One of the functions of WSPBuilder is Copy to GAC, which does exactly as the name suggest:

PostBuild Task
Some clients don’t allow WSPBuilder to be installed or they prefer a more custom project structure. In these cases I tend to use Project Post Build Tasks. You can use the Edit Post Build… function to add parameters to your post build command, as shown below. I tend to use the GACUtil command to copy the assembly to the GAC and the iisapp.vbs to recycle the application pool. A sample script is show below. This is required to ensure that the Just In Time (JIT) compilation occurs again.

"%programfiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin\GacUtil.exe" /if "$(TargetPath)" /nologo
"%systemroot%\system32\iisapp.vbs" /a "SharePoint – 9000" /r

Resolution

Although I cannot actually explain what is causing this issue, I found that if you restart the Indexing Service through the Windows Services Management Console, the problem is resolved.

If anyone has an explanation as to why this occurs I would be grateful.

If like me you’ve recently updated to Windows 7 (which generally I find a real improvement over Vista) you may have difficulties downloading products from the MSDN site using the Microsoft MSDN File Transfer Manager (TFM). Now I have to be honest I’m not sure if this is an issue with Windows 7 or Internet Explorer 8 (IE8). My gut feeling is it is a issue with IE8. Either way if you are having issues downloading files from the MSDN download site, then you need to manually download and install it from:

Microsoft MSDN File Transfer Manager

Also if your Corporate Group Policy requires you to have Administrative privileges to install ActiveX controls then you can use the above link to download and install.

There is an alternative download manager from Akamai, for those not using Internet Explorer or FireFox on Windows:

Akamai Download Manager.

Note: FTM is implemented as an ActiveX control and is a 32-bit application, so you may need to run your 64-bit browser in 32-bit mode.

More information can be found on the File Transfer Manager Help pages.

If you are experiencing the following symptoms:

While assisting a client in moving content from one environment to another for testing purposes, it was noticed that the site of the stsadm backup file was considerably larger than the Content Database size as defined in the stsadm enumsites report.

As can be seen in the from the out put of the enumsites, the StorageUsedMB for the HRTemp site collection is reported to be 158.4 MB. However the size of the backup file is 3.1 GB.

<Sites Count="5">  <Site Url=http://portal Owner="domain\spadmin" ContentDatabase="WSS_Content"StorageUsedMB="1.7" StorageWarningMB="0" StorageMaxMB="0" />  <Site Url="http://portal/teamsite/hr" Owner="domain\spadmin"  ContentDatabase="WSS_Content_HR2" StorageUsedMB="3171.1" StorageWarningMB="0" StorageMaxMB="0" />  <Site Url="http://portal/teamsite/HRTemp" Owner="domain\spadmin"  ContentDatabase="WSS_Content_Temp" StorageUsedMB="158.4" StorageWarningMB="0" StorageMaxMB="0" />  <Site Url="http://portal/teamsite/it" Owner="domain\spadmin" ContentDatabase="WSS_Content_IT" StorageUsedMB="8840.7" StorageWarningMB="0" StorageMaxMB="0" />  <Site Url="http://portal/teamsite/research" Owner="domain\spadmin" ContentDatabase="WSS_Content_Research" StorageUsedMB="14.5" StorageWarningMB="0" StorageMaxMB="0" /></Sites>

Once the files were removed from the site collection recycle bin the backup file was reduced to the expected size.

It is therefore important to ensure that files are deleted and removed from the recycle bin properly before executing a stsadm backup as files in the recycle bin for the site collection will also be backed up and this will not be reflected in the enumsites report.

Note: You can disable the recycle bin thus purging the recycle bin using the setproperty method of the stsadm command. Beware that this property is for the Web Application and not the site collection, and will as a result empty (delete) the recycle bins for all site collections in the web application. This is OK for testing purposes, but not recommended in production environments.