Troubleshooting MS Office Install issues (MSI & Click-to-Run)

Here’s a shortlist of some useful troubleshooting techniques, divided into two sections according to the two main types of MS Office Installations:

MSI: “Traditional” Windows installer
Click-to-Run: Office 365 installed MS Office

MS Office MSI Install Troubleshooting

“Verbose logging” is a setting that exposes more information during the installation process. It will capture “warning” as well as “error” messages that provide us with clues to your problem. To do onetime verbose logging:

Diagnosing When Setup Stops Responding At times, Office Setup stops responding (hangs), and you do not receive any error message. The best thing to do in this situation is to restart your computer, and run Office Setup again with complete verbose logging turned on (with one additional option). To do this, start Office Setup. To do so, follow these steps:

  1. Click Start, and then click Run.
  2. In the Open box, type the following command line, and then click OK:

pathSetup.exe /L*v! C:Verboselog.txt

Note that Path is the full path of your Office source location.

To enable Windows Installer logging yourself, open the registry with Regedit.exe and create the following path and keys:

HKEY_LOCAL_MACHINE\SoftwarePolicies\Microsoft\WindowsInstaller

Reg_SZ: Logging Value: voicewarmupx

The letters in the value field can be in any order. Each letter turns on a different logging mode. Each letter’s actual function is as follows for MSI version 1.1:

v – Verbose output
o – Out-of-disk-space messages
i – Status messages
c – Initial UI parameters
e – All error messages
w – Non-fatal warnings
a – Start up of actions
r – Action-specific records
m – Out-of-memory or fatal exit information
u – User requests
p – Terminal properties
+ – Append to existing file
! – Flush each line to the log
x – Extra debugging information. The “x” flag is available only on Windows Server 2003 and later operating systems, and on the MSI redistributable version 3.0, and on later versions of the MSI redistributable.
“*” – Wildcard, log all information except for the v and the x option. To include the v and the x option, specify “/l*vx”.

Note This should be used only for troubleshooting purposes and should not be left on because it will have adverse effects on system performance and disk space. Each time you use the Add/Remove Programs tool in Control Panel, a new Msi*.log file is created.

When looking through the MSI logs we will typically want to look for a value 3 entry in the logs. Windows installer returns codes during the install which will indicate if a particular function was successful or not.

Value 1 = Success
Value 2 = Cancel
Value 3 = Error

Note: make sure to turn off verbose logging after you are done.

Enable verbose logging before collecting the log files.

  1. Click on Start -> All Programs
  2. Accessories -> RUN
  3. Type reg add HKLMSOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /t REG_DWORD /d 3
  4. Click on OK.

Now try to install Microsoft Office 2016 to get the error message so that the log files get created.

Follow the steps below to access the ‘Temp’ folder.

  1. Click on Start -> All Programs
  2. Accessories -> RUN
  3. Type %temp%  -> Click on OK

The following are the log files that may be present in the %windir%temp folder (c2r is for Click to Run):

Bootstrapper*.log
c2r_*.log
C2RIntegrator*.log
Firefly*.log
Integratedoffice.exe_c2r*.log
Interceptor*.log
*.exe.log
*_c2rdll*

For MSI, “Normal”, installations the log files will look like MSI****.LOG

Further References:
http://support.microsoft.com/kb/2545723 – “Fix Its” to turn logging on and off
http://blogs.technet.com/b/odsupport/archive/2010/12/30/trouble shooting-office-installation-failures.aspx Office 2003-2010, analyse log
http://support.microsoft.com/kb/223300 – “Fix It” enable XP, Server 2003-8
http://support.microsoft.com/kb/826511 – help interpretting logs
http://technet.microsoft.com/en-us/library/cc978342.aspx

MS Office Click-To-Run Install Troubleshooting

The following steps show you how to enable verbose logging to help you troubleshooting Office 365 install/update failures.

To enable verbose logging, launch cmd as administrator and run the following command:

reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /t REG_DWORD /d 3

ULS log file is created both in the %temp% folder and the %windir%\temp folder.  The file name is of the following format:

<machinename>-<date>-<time>.log

For example Keith-201420141610-1434.log.  Once these logs have been retrieved and analyzed, verbose logging should be disabled by running the following command from an administrative command-prompt:

reg delete HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /f

The log output is in ULS format.  Opening the log file in Excel will help you with filtering the data.  First, you want to look for is the term “unexpected”.  You can look for “Fail” and /or “Error”

When Attempting to Install Office 365 Directly from the Office Portal

Most end user issues with installing/activating Microsoft Office 365 from the Office Portal are proxy/firewall related.  Follow the steps above to review log files.

Process Monitor and Fiddler are also great tools to use for troubleshooting Office 365 ProPlus installation and activation errors. If possible, try to test using a less restricted proxy/firewall.  If the activation is successful on another network, you may need make adjustments to your proxy/firewall settings.

The following article can help you with determining the IP address and URL exceptions you might need to add:

Start by white listing or adding exceptions for the IP addresses and URLs under “Office 365 ProPlus”.  If you continue to have problems, add the URLs under the “Office 365 portal and identity” section.

If still have problems, try the following:

MS Office MSI Install Troubleshooting

“Verbose logging” is a setting that exposes more information during the installation process. It will capture “warning” as well as “error” messages that provide us with clues to your problem.

To do onetime verbose logging:

Diagnosing When Setup Stops Responding At times, Office Setup stops responding (hangs), and you do not receive any error message. The best thing to do in this situation is to restart your computer, and run Office Setup again with complete verbose logging turned on (with one additional option). To do this, start Office Setup. To do so, follow these steps:

  1. Click Start, and then click Run.
  2. In the Open box, type the following command line, and then click OK:

pathSetup.exe /L*v! C:Verboselog.txt

Note that Path is the full path of your Office source location.

To enable Windows Installer logging yourself, open the registry with Regedit.exe and create the following path and keys:

HKEY_LOCAL_MACHINE\SoftwarePolicies\Microsoft\WindowsInstaller

Reg_SZ: Logging Value: voicewarmupx

The letters in the value field can be in any order. Each letter turns on a different logging mode. Each letter’s actual function is as follows for MSI version 1.1:

v – Verbose output
o – Out-of-disk-space messages
i – Status messages
c – Initial UI parameters
e – All error messages
w – Non-fatal warnings
a – Start up of actions
r – Action-specific records
m – Out-of-memory or fatal exit information
u – User requests
p – Terminal properties
+ – Append to existing file
! – Flush each line to the log
x – Extra debugging information. The “x” flag is available only on Windows Server 2003 and later operating systems, and on the MSI redistributable version 3.0, and on later versions of the MSI redistributable.
“*” – Wildcard, log all information except for the v and the x option. To include the v and the x option, specify “/l*vx”.

Note This should be used only for troubleshooting purposes and should not be left on because it will have adverse effects on system performance and disk space. Each time you use the Add/Remove Programs tool in Control Panel, a new Msi*.log file is created.

When looking through the MSI logs we will typically want to look for a value 3 entry in the logs. Windows installer returns codes during the install which will indicate if a particular function was successful or not. Value 1 = Success Value 2 = Cancel Value 3 = Error

Note: make sure to turn off verbose logging after you are done.

Enable verbose logging before collecting the log files.

  1. Click on Start -> All Programs
  2. Accessories -> RUN
  3. Type reg add HKLMSOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /t REG_DWORD /d 3
  4. Click on OK.

Now try to install Microsoft Office 2016 to get the error message so that the log files get created.

Follow the steps below to access the ‘Temp’ folder.

  1. Click on Start -> All Programs
  2. Accessories -> RUN
  3. Type %temp%  -> Click on OK

The following are the log files that may be present in the %windir%temp folder (c2r is for Click to Run):

Bootstrapper*.log
c2r_*.log
C2RIntegrator*.log
Firefly*.log
Integratedoffice.exe_c2r*.log
Interceptor*.log
*.exe.log
*_c2rdll*

For MSI, “Normal”, installations the log files will look like MSI****.LOG

Open the command prompt (run as administrator), and use the following command to import the manual proxy settings from IE:

netsh winhttp import proxy source=ie

Now rerun the install/update

To reset winhttp back, run the following command:

netsh winhttp reset proxy

Most failed installs directly from the Office portal that are proxy related, usually fail pretty quick and usually with an error like this:

“Sorry, we ran into a problem Go online for additional help. Error Code: 30174-4.”

Or When attempting to update a client that is looking to the Office portal for updates will get something like this:

“Something went Wrong: We’re sorry, we ran into a problem while downloading updates for Office. Please check your network connection and try again later. Error Code: 30088-28 or 30088-27”

Using the built-in Windows Problem Steps Recorder to document user woes

I’m re-introducing the Windows PSR (Problems Steps Recorder) as one of those cool tools we come across, get distracted, forget about, and then come back to as “wow that’s hot”.

Problem Steps Recorder (PSR.exe), is shipping on all builds of Windows 7, Windows 8, Windows 8.1, Windows 8.1.1, Windows Server 2008 R2, Windows Server 2012 & Windows Server 2012 R2. Unfortunately, there is no equivalent Microsoft provided program available for Windows Vista, Windows XP, or other Microsoft operating systems prior to Windows 7. This feature enables the collection of the actions performed by a user while encountering a crash or running through the things they are trying to do, so that we as Consultants, Developers, Support Technicians & Admins can figure out what exactly is going south.

To begin creating their documentation, the user would press the Start Record button.

They would then begin going through the steps that took them towards their question or problem. At any point during this process, they can press the Add Comment button to highlight a problem area and add comments. Once they are done, they click the Stop Record button. Once they stop recording, a Save As window appears letting them browse to the location they want to save the documentation. A zip file is created and saved to that location. Inside the zip file is a .mht file containing the documentation. You will need to use Internet Explorer to view the MHT file.

Opening the documentation will present the help desk, admin, or family tech guy with a step-by-step walkthrough of what the user did, complete with screenshots and any comments made by the user.

Click here for a sample of what the recorded output looks like:
Windows-PSR-SharePoint-Problem-Steps-Recorder-Debugging

In addition to the screenshots, at the bottom of the report file the PSR generates you’ll find a copy & pastable (plain text) output of the events, like the following:

Recording Session: ‎2014-‎05-‎29 7:35:48 PM – 7:36:51 PM

Recorded Steps: 4, Missed Steps: 3, Other Errors: 0

Operating System: 9600.17041.amd64fre.winblue_gdr.140305-1710 6.3.0.0.2.48

Step 1: User left click in “Sites – Internet Explorer”
Program: Internet Explorer, 11.00.9600.16384 (winblue_rtm.130821-1623), Microsoft Corporation, IEXPLORE.EXE  SCODEF:13064 CREDAT:1782837 /PREFETCH:2, IEXPLORE.EXE
UI Elements:

Step 2: User mouse wheel down in “Pages – Engineering – Internet Explorer”
Program: Internet Explorer, 11.00.9600.16384 (winblue_rtm.130821-1623), Microsoft Corporation, IEXPLORE.EXE  SCODEF:13064 CREDAT:1782837 /PREFETCH:2, IEXPLORE.EXE
UI Elements:

Step 3: User left click in “Pages – Engineering – Internet Explorer”
Program: Internet Explorer, 11.00.9600.16384 (winblue_rtm.130821-1623), Microsoft Corporation, IEXPLORE.EXE  SCODEF:13064 CREDAT:1782837 /PREFETCH:2, IEXPLORE.EXE
UI Elements:

Step 4: User Comment: “This is where it breaks”
Program:
UI Elements:

How to Use the PSR

Notes

  • When you record steps on your computer, anything you type will not be recorded. If what you type is an important part of recreating the problem you’re trying to solve, use the comment feature described below to highlight where the problem is occurring.

    Some programs, like a full-screen game, might not be captured accurately or might not provide useful details to a support professional.

To record and save steps on your computer

  1. Open Problem Steps Recorder by clicking the Start button, and then typing psr. In the list of results, click psr.

  2. Click Start Record. On your computer, go through the steps on your computer to reproduce the problem. You can pause the recording at any time, and then resume it later.

  3. Click Stop Record.

  4. In the Save As dialog box, type a name for the file, and then click Save (the file is saved with the .zip file name extension).

    To view the record of the steps you recorded, open the .zip file you just saved, and then double-click the file. The document will open in your browser.

To send the problem steps in e‑mail

  • After recording and saving a .zip file, click the help down arrow , and then click Send to E‑mail recipient. This will open an e‑mail message in your default e‑mail program with the last recorded file attached to it.

    Note

    • You won’t be able to click the Send to e‑mail recipient option until you’ve recorded and saved a file.

To annotate problem steps

  1. Open Problem Steps Recorder by clicking the Start button , and then typing psr. In the list of results, click psr.

  2. Click Start Record.

  3. When you want to add a comment, click Add Comment.

  4. Use your mouse to highlight the part of the screen that you want to comment on, type your text in the Highlight Problem and Comment box, and then click OK.

  5. Click Stop Record.

  6. In the Save As dialog box, type a name for the file, and then click Save.

    To view the record of the steps you recorded, open the .zip file you just saved, and then double-click the file. The document will open in your browser.

To adjust settings

When you adjust settings for Problem Steps Recorder, they’re only saved for your current session. After you close and reopen Problem Steps Recorder, it will return to the regular settings.

  1. Open Problem Steps Recorder by clicking the Start button , and then typing psr. In the list of results, click psr.

  2. Click the help down arrow , and then click Settings.
  3. You can change the following settings for Problem Steps Recorder:

    • Output Location. If you don’t want to be prompted to save a file after recording, click the Browse button to set a default output file name.

    • Enable screen capture. If you don’t want to capture the screen shots along with the click information, select No. This might be a consideration if you are taking screen shots of a program that contains personal information, such as bank statements, and you are sharing the screen shots with someone else.

    • Number of recent screen captures to store. While the default is 25 screens, you can increase or decrease the number of screen shots. Problem Steps Recorder only records the default number of screen shots. For example, if you took 30 screen shots during a recording but only had 25 screen shots as the default, you would be missing the first five screen shots. In this case, you would want to increase the number of default screen shots.

What about the other screenshot tool <X>?

As usual in software-type things, there’s more than one product around that does the same type of thing. For screenshots, even just in the Microsoft stack there’s:
OneNote Screen Clipping – http://www.youtube.com/watch?v=r6yutoKDZLE
Office Screen Clipping – http://office.microsoft.com/en-ca/word-help/insert-a-screenshot-or-screen-clipping-HA010355185.aspx

On the general market, there’s:

I use the great SnagIt on a daily basis to make screenshots (just trying out version 12 this week myself) however, it’s more for us as Consultants to create content for consumption by others. The Problem Steps Recorder has the advantage over SnagIt for particular scenarios where you need the user to show you what’s going on:

– Free
– Built into most Windows environments you’ll encounter these days
– Can be run by end users with very little instruction
– Can be used on workstations where remote desktop’ing in isn’t available, performed autonomously by end users
– Handles all the screenshot’ing, layout, description of user interaction events
– Provides detailed descriptions of interaction events that would be otherwise time-consuming/difficult for a human to collect manually

Final Victory of the PSR

2014-05-29_20-24-13
The final advantage I see in the PSR in general (as a troubleshooting tool), is a huge one:
By empowering the user to document their own grief, with their own mouse button and on their own time, you are creating a purer user story:

– they are not being influenced by weird remote desktop software running on their workstation
– they don’t have to worry that the visiting technician invading their desktop is going to discover what kinds of oddball websites they visit while poking around
– there’s less time constraints as the user can run this on their own time, again without someone breathing down their neck
– there’s less chance of their user story being tainted as there’s no one coaching them, directly or indirectly

References:

http://blogs.msdn.com/b/patricka/archive/2010/01/04/using-the-secret-windows-7-problem-step-recorder-to-create-step-by-step-screenshot-documents.aspx
http://technet.microsoft.com/en-us/windows/problem-steps-recorder-overview.aspx
http://windows.microsoft.com/en-CA/windows7/How-do-I-use-Problem-Steps-Recorder
http://www.maximumpc.com/article/how-tos/how_use_windows_7_problem_steps_recorder_make_easy_pc_guides
http://msdn.microsoft.com/en-us/library/dd371782%28v=vs.85%29.aspx
http://www.7tutorials.com/easy-troubleshooting-and-problem-solving-problem-steps-recorder
https://www.youtube.com/watch?v=z6EgLm3-XcQ

Change Site Collection Managed Path after move from different version of SharePoint

​In order to change a Managed Path for a site collection we need to backup and restore that site collection to the new Managed Path.

I attempted to backup and restore a site collection today, with the goal of changing the managed path from:
https://go.portal.com/site/siteA

to:
https://go.portal.com/department/siteA

After mounting the 2010 version Content DB in from the 2010 Production farm, into the 2013 farm, and attempting to run the PowerShell to backup and then restore the site collection, I ran into an error:
Restore-SPSite : <nativehr>0x80070003</nativehr><nativestack></nativestack>.

Once I ran the Visual Site Collection upgrade and brought the site collection up to 2013, I could run my script to backup/restore and get the managed path changed.

I found this which explained some things for me:

http://social.technet.microsoft.com/Forums/sharepoint/en-US/1060ae12-0d72-47c6-91bb-e98cc779c16d/what-is-causing-this-error-restorespsite-?forum=sharepointadmin

While the below comment from that thread doesn’t address the exact scenario, it may also be helpful for us to know:

I am wondering if anyone noticed but on SharePoint 2013 we have lost a lot of the flexibility in the restore process?

On SharePoint 2010 you could and still can restore from one SP20120 server to a another SP2010 server with a different cumulative update/version, once the destination server (where you trying to restore to) does not have a cumulative update that is pre that of which is installed on the source server. In summary site collection backups would restore to SharePoint servers which has equal or above cumulative updates.

Example of this…

You could.. 1. Backup a site collection from Server A with December 2010 CU and then restore to Server B running July 2011 CU.

2. Backup a site collection from Server A with SharePoint Foundation December 2010 CU and then restore to Server B running SharePoint Server December 2010 CU. (Foundation –> Server)

3. Backup a site collection from Server A with December 2010 CU and then restore to Server B running December 2010 CU. (Identical servers)

You could not… Backup a site collection from Server A with July 2011 CU and then restore to Server B running December 2010 CU.

Example 1 & 2 above are no longer available on SharePoint 2013

Moral of the story seems to be that you better make sure your major version and CU levels are on par before you attempt changing the managed path like this. By running the Visual Site Collection upgrade everything got brought into SP 2013 mode and the process could complete.

The PowerShell used was:

#Get the from Site Collection URL
$fromURL = "https://go.site.com/site/siteA"
#Get the to Site Collection URL
$toURL = "https://go.site.com/department/siteA
#Get DB Reference
$Database = Get-SPContentdatabase "org_SiteAContentDB1"
#Location to the backup file directory to store Site Collection backup files
$backupPath = "d:topSharePointBackupsorg_SiteAContentDB1.bak"
#Backing up Site Collection prior to moving
Write-Host "Backing Up Site Collection…."
Backup-SPSite $fromURL -Path $backupPath -force
#Removing Site Collection from old managed path
Write-Host "Removing Site Collection from old managed path location…"
Remove-SPSite -Identity $fromURL -Confirm:$false
#Restoring Site Collection to new Managed Path
Write-Host "Restoring Site Collection to new managed path location…"
Restore-SPSite -Identity $toURL -Path $backupPath -Confirm:$false
#Remove backup files from the backup directory
Remove-Item $backupPath

Delete a SharePoint 2010 service application database for a service application that was previously removed/deleted

In this post I will explain how to delete a SharePoint 2010 service application database for a service application that was previously removed/deleted.

When you remove your service application, you may see on on the page Central Administration > Management Databases Upgrade Status that the database is still visible even though it a) is not in use anymore and/or b) has been deleted from SSMS.

You may notice in the event log:

SQL Database ‘db_name’ on SQL Server instance ‘sql_instance’ not found. Additional error information from SQL

Server is included below.

Cannot open database “db_name” requested by the login. The login failed.
Login failed for user ‘login’.

To overcome this error and remove the old DB reference, fill your zombie DB name into the following PowerShell and execute from the SharePoint PowerShell interface:

get-spdatabase | where {$_.name -eq 'db_name'} | foreach {$_.Delete()};

This will remove the DB from SharePoint’s frame of reference and clear up any related error messages. Don’t forget – if the physical DB is still in SQL Server, you will need to go into SSMS and archive/delete it as ye may so desire.

Concurrency Error with PSConfig

Patching SharePoint servers, you’ve probably run into the situation where you try to run PSConfig to upgrade a server and it fails on step three. Looking at the error logs, you’ll may see SPUpdatedConcurrencyException is the error that was thrown.

An exception of type Microsoft.SharePoint.Administration.SPUpdatedConcurrencyExc
eption was thrown.  Additional exception information: An update conflict has occ
urred, and you must re-try this action. The object SPUpgradeSession Name=Upgrade
-20120917-101200-949 was updated by MYDOMAINspinstall, in the PSCONFIG (3540) pr
ocess, on machine SERVER1.  View the tracing log for more information about the
 conflict.

Total number of configuration settings run: 3
Total number of successful configuration settings: 2
Total number of unsuccessful configuration settings: 1
Successfully stopped the configuration of SharePoint Products.
Configuration of SharePoint Products failed.  Configuration must be performed be
fore you use SharePoint Products.  For further details, see the diagnostic log l
ocated at C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14LOGSPSCDiagnostics_9_17_2012_10_11_55_375_12483735.log

..and the application
event log.

There are a lot of entries on the web about this – lots of information about clearing out the SharePoint object cache; but that may not always work. What I’ve found that seems to correct the problem every time is to run this command on the offending server:

1. Open Administrative Command Prompt
2. Go to

c:Program FilesCommonMicrosoft SharedWeb Server Extensions14BIN

3. Execute the following:

stsadm –o setproperty –propertyname command-line-upgrade-running –propertyvalue no

This should clear the “an upgrade is in process” flag on the server. You should now be able to run your PSConfig as expected.

Telerik acquires Fiddler

Great news, the greatest little open source web debugger, Fiddler, has now been aquired by the great vendor of .NET controls, Telerik. Expect some nice upgrades to Fiddler soon, and yes, it will remain free.

Full story:
http://www.telerik.com/automated-testing-tools/blog/christophereyhorn/12-09-10/here-we-grow-again-telerik-acquires-fiddler-what-s-next.aspx

“We have some very exciting news to share with the Telerik community. Telerik has just acquired Fiddler! Even more exciting is that Fiddler’s brilliant creator Eric Lawrence will come over from Microsoft to join the team fulltime. For those of you who don’t know, Fiddler is a web debugging proxy which logs all HTTP(S) traffic between your computer or device and the Internet. In other words, it is an essential tool for any web, desktop or mobile developer. The popularity and sophistication of Fiddler is hugely impressive considering this has been Eric’s informal side project for more than 8 years. With Eric joining the team he will be able to deliver on his vision for Fiddler with the full financial and resource backing of Telerik.

It might be apparent why Eric would jump at an opportunity to turn his side passion project into a full time position, but what might not be readily obvious is why Telerik would need a product like Fiddler in our portfolio.

Our strategy has always been to acquire when it makes sense and to use the new technology to improve our core products for the benefit of our customers. In the case of Fiddler, this was a natural extension because Fiddler is already in use as the core technology behind Test Studio’s load and performance features. Additionally, we gain a formidable competitive edge over other tools as both Eric and Fiddler join the Test Studio product family. The collaboration for enhancing Fiddler is already underway as well as discussions to further expand our portfolio and extend support for our customers.

The Fiddler community is very important to us. We have learned from the mistakes of others who have acquired free tools only to turn the tables on the community and monetize them at a later date. We admire what Fiddler has delivered to the community and want to expand that value by investing in things like expanded platform support, user interface improvements and a first class website with extensive community and support features.

That is why, as part of our commitment to keeping Fiddler free and making further investments into the tool, we have launched a poll on the Fiddler website asking the community to vote on the first improvements we will target. Whether you are an avid or occasional Fiddler user we would love to get your opinions on what you would like to see happen first.

To give you some insight into how popular Fiddler really is here are some stats, year to date. On average Fiddler receives over 9,000 installations EVERY DAY, and when I say average that is including weekends. That number jumps to over 10,000 for weekdays. The website has received more than 5 million unique visitors this year alone with over 80% of them being first time visits. Needless to say that the Fiddler community is not just big, it’s HUGE.

So please help me in welcoming Eric and the Fiddler community into the Telerik family. Great things are ahead for Fiddler as we continue to invest in and build an even better tool and community. To see how Fiddler is already powering Test Studio’s load and performance features download a trial today.”

Webclient Service File Size limit in SharePoint

We ran into an issue with some custom code that was doing a System.IO.File.Copy from a WebDav (SharePoint) to a UNC network share. Everything was working great until the file sizes we were transferring hit approx. 47MB in size. At this point, it craps out with an error.

When you upload a large file (over 50Mb usually) to SharePoint 2010, you might get an “Error 0x800700DF: The file size exceeds the limit allowed and cannot be saved” message. Check your  current SharePoint file size upload quota and web.config settings. If the quota is not a problem, then the error is most likely caused by a local restriction set on Web Client service. By default, Web Client file size limit is set to 47Mb or so. To increase this limit:

  • Backup the Windows Registry – be cool, keep your job
  • Open Windows Registry using regedit command
  • Browse to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWebClientParameters
  • Right click on the FileSizeLimitInBytes and click Modify
  • Click on Decimal, and type 4294967295 and click OK
  • Restart Web Client service by typing services.msc.
This will increase the Web Client file size limit to 4Gb, which is a maximum file size you can upload using WebDAV. Please note, that this will only address Web Client service restrictions, and will not increase your SharePoint quota .. you still need to address those points approriately as per the linked MSDN blog post above.
It is also of note that the SharePoint max, cannot raise, hardcoded file size limit is 2GB, period, so raising to 4Gb is essentially overkill. 😉
p.s Don’t forget, if you want to use WebDAV effectively in SharePoint, you will need to have the Desktop Experience feature turned on in Win2k8 – you’ll run into inexplicable intermittent transfer drops otherwise.

p.p.s See my post SharePoint 2010 File Size Upload Limits – The Essential Mix for a full run down of all the file size limit jazz in SP 2010.

AutoSPInstaller – Auto-create local profiles for SharePoint Service Accounts

SharePoint is a big product and there’s a lot of people in the world working on it.. so it’s funny to be working on a specific issue, then coming full circle and either Bing’ing upon your own old blog post, or, as today, seeing that someone has adopted what the guy sitting next to you blogged a while ago into the current code you are looking at.

What

While running SharePoint 2010 you may notice the following error Event ID 1511 messages in your Application event log each time you restart the IIS Worker process and made a request:

Log Name: Application
Source: Microsoft-Windows-User Profiles Service
Date: 5/3/2010 10:05:07 AM
Event ID: 1511
Task Category: None
Level: Error
Keywords:
User: CONTOSOAppPoolAccount
Computer: SP2010Dev.contoso.com
Description:
Windows cannot find the local profile and is logging you on with a temporary profile. Changes you make to this profile will be lost when you log off.

So What

If your SharePoint services accounts are being run under the Application Pools then you are not going to see this message. If you are however using a separate account to run your Application Pools you are probably going to see this error in your event logs.

You need to get those accounts to fire up a local profile – this could in the simplest sense be accomplished by logging on as each of those accounts once. Nasty!

The better approach- well, I was looking at scripting a PowerShell to run the following en masse for all of an installs service accounts:

runas /u:CONTOSOAppPoolAccount /profile cmd

..however, knowing that we have had some joy with the AutoSPInstaller recently, I thought I’d poke around that and see if we couldn’t just wire in the creation of the local profiles into that solution, so it would be taken care of in the same go as batch account creation.

Well, poking around the AutoSPInstaller file AutoSPInstallerFunctions1.ps1 is discovered the following magical discovery – look’s like my homeboy Sean (on his Brainlitter blog post) has already inspired this fix (change 72193) to be added to the AutoSPInstaller codebase! :

The suggestion from matein78 got added in as a patch:
– AddManagedAccounts function now creates local Windows profiles for each account, to avoid ‘1511’ type event log errors (thanks to user matein78’s suggestion from http://autospinstaller.codeplex.com/workitem/15535!)

NOTE: I created a stripped down version of this functionality that doesn’t require the main AutoSPInstaller script, i.e. you can run it manually on a hand-deployed SharePoint install. Read about it here.

..which is implemented as:

ForEach ($account in $xmlinput.Configuration.Farm.ManagedAccounts.ManagedAccount)
		{
            $username = $account.username
            $password = $account.Password
            $password = ConvertTo-SecureString "$password" -AsPlaintext -Force 
			# The following was suggested by Matthias Einig (http://www.codeplex.com/site/users/view/matein78)
			# And inspired by http://todd-carter.com/post/2010/05/03/Give-your-Application-Pool-Accounts-A-Profile.aspx & http://blog.brainlitter.com/archive/2010/06/08/how-to-revolve-event-id-1511-windows-cannot-find-the-local-profile-on-windows-server-2008.aspx
	        Try
			{
				Write-Host -ForegroundColor White " - Creating local profile for $username..." -NoNewline
				$credAccount = New-Object System.Management.Automation.PsCredential $username,$password
				$ManagedAccountDomain,$ManagedAccountUser = $username -Split ""
				# Add managed account to local admins (very) temporarily so it can log in and create its profile
	    		If (!($LocalAdmins -contains $ManagedAccountUser))
				{
					$builtinAdminGroup = Get-AdministratorsGroup
                    ([ADSI]"WinNT://$env:COMPUTERNAME/$builtinAdminGroup,group").Add("WinNT://$ManagedAccountDomain/$ManagedAccountUser")
				}
				Else
				{
					$AlreadyAdmin = $true
				}
				# Spawn a command window using the managed account's credentials, create the profile, and exit immediately
				Start-Process -WorkingDirectory "$env:SYSTEMROOTSystem32" -FilePath "cmd.exe" -ArgumentList "/C" -LoadUserProfile -NoNewWindow -Credential $credAccount
				# Remove managed account from local admins unless it was already there
                $builtinAdminGroup = Get-AdministratorsGroup
	    		If (-not $AlreadyAdmin) {([ADSI]"WinNT://$env:COMPUTERNAME/$builtinAdminGroup,group").Remove("WinNT://$ManagedAccountDomain/$ManagedAccountUser")}
				Write-Host -BackgroundColor Blue -ForegroundColor Black "Done."
			}

Now What

Now I sit back and relax as the circle of life has been completed and this is one less bit of code to write today. Thanks to Sean, Todd Carter, matein78 and of course brianlala for writing AutoSPInstaller and adding this patch!

References:
Sean Wallbridge (my boss):
http://blog.brainlitter.com/2010/06/08/how-to-resolve-event-id-1511windows-cannot-find-the-local-profile-on-windows-server-2008/

AutoSPInstaller:
http://autospinstaller.codeplex.com

Todd Carter:
http://www.todd-carter.com/post/2010/05/03/give-your-application-pool-accounts-a-profile/

IE=Edge in SP 2010

We have experimented quite a bit with having IE9 Compatibility mode turned on in custom SharePoint 2010 Branding.

Out of the Box SP 2010 Masterpages come with the following tag:

<meta http-equiv="X-UA-Compatible" content="IE=8"/>

You may try changing it to IE=9 to get some of the goodies but will quickly notice things blow up and there is simply no choice for the time being except to remain in IE=8 mode.
Recently we tried IE=Edge, which indicates “hey, use the latest IE version”. I guess this could save you some maintenance in the future in some scenarios but really seems like it’s prone to just cause future headaches. If your code outlives IE version iterations you will probably have plenty of scope to evaluate browser compatibilty once in a while.

A particular symptom of what will break with IE=Edge / IE=9, is that the SharePoint user picker UI will not work for multi user selection. That would classify as a showstopper:

  • 1
  • 2