Marc Lognoul's IT Infrastructure Blog

Cloudy with a Chance of On-Prem


Leave a comment

SharePoint: MS15-022 (Critical) Vulnerabilities in Microsoft Office Could Allow Remote Code Execution (3038999)

Once again, SharePoint Server 2007, 2010 and 2013 are affected by a vulnerability categorized as Critical by MS that can allow remote code execution. The matching Office suite version are affected as well.

More information:

Important: SharePoint Server 2013 updated with March PU or Service Pack 1 can receive this security update through Windows Update.


SharePoint 2007: Post-SP2 Issue User Information Page URL leads to 400 or 404 when My Site is Disabled

MOSS 2007 SP2 introduced a fix for a bug related to the redirection of the User Information page (userdisp.aspx under WSS) redirected to people.aspx (under MOSS). This post will explain the behavior in details: http://blogs.msdn.com/b/dmp/archive/2009/01/21/user-information-page-userdisp-aspx-vs-person-aspx.aspx.

The problem occurs when you’re running a farm where My Site is disallowed or simply not configured: depending on the exact set-up, clicking on the user name will lead to HTTP Error 400 “Bad Request” or 404 Page not found”.

How to solve this? There are actually multiple ways:

1. Activating My Site

Activating and configuring My Site will actually restore MOSS’ standard behavior. There are of course obvious implications with this solution. If you do not wish to deal with them, look at solution 2 and 3 then!

2. Manually Editing the page userdisp.aspx

Backup then edit the page userdisp.aspx located under C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12TEMPLATELAYOUTS

Find the line hereunder:

<SharePoint:DelegateControl runat=”server” id=”DelctlProfileRedirection” ControlId=”ProfileRedirection” Scope=”Farm” />

Replace Farm with Web so that it looks like:

<SharePoint:DelegateControl runat=”server” id=”DelctlProfileRedirection” ControlId=”ProfileRedirection” Scope=”Web” />

Save the file then execute IISRESET.

Note: you’ll have to repeat this operation on all Web Front-ends in the farm and keep in mind that this page might get updated with SharePoint hot fixes and service packs and therefore the customization lost.

2. Implementing a Delegate Control through a Feature

The redirection from userdisp.aspx to people.aspx is actually implemented by a control named ProfileRedirection.

In order to restore the pre-SP2 behavior, you can lower the priority of this control implementing a Delegate Control with a sequence number that will actually lower its priority. It would actually look like this:

<Control Id="ProfileRedirection" Sequence="50" ControlSrc=""/>

All you need to do is creating a simple feature with a definition that contains the line above. In order to prevent all odd behaviors implied by not having My Site enabled on the farm you may also want to add GlobalSiteLink1 and GlobalSiteLink2 to the list of controls:

<Elements xmlns=”http://schemas.microsoft.com/sharepoint/&#8221;>
<Control Id=”GlobalSiteLink1″ Sequence=”50″ ControlSrc=”” />
<Control Id=”GlobalSiteLink2″ Sequence=”50″ ControlSrc=””/>
<Control Id=”ProfileRedirection” Sequence=”50″ ControlSrc=””/>
</Elements>

Not feeling comfortable with creating you own feature? No problem, you can download this feature ready-to-use packaged as WSP and install it without any special intervention by executing the commands below:

stsadm -o addsolution -filename PreventMySiteRedirect.wsp
stsadm -o deploysolution -name PreventMySiteRedirect.wsp -immediate

Kudos to SharePoint MVP Stéphane Eyskens for pointing me in the right direction regarding Delegate Controls!

Marc


Leave a comment

SharePoint 2007: C: Drive filling up with WSS_AdminService.log growing

Hi there. This post was actually sleeping in my draft folder for a long that I finally decided to finalize and post it ASAP before it gets completely outdated.

On WSS3/MOSS 207, the SPAdmin Service (Windows SharePoint Services Administration, process WSSADMIN.EXE) is logging its activity out to the file WSS_AdminService.log located under C:Documents and SettingsDefault UserLocal SettingsTemp (Server 2003) or C:UsersDefault UserLocal Settings (Server 2008 and beyond).

Apparently there is no limit to its expansion so don’t be surprised if its size goes well beyond 1 GB over time.

It is solely used for internal tracing and there is no clean nor supported way for controlling it (disabling, limiting its size…) like you would do for Diagnostics or Usage Logs.

There are 2 dirty (although working) ways to prevent SPAdmin service from writing out to disk:

  1. Setting the read-only attribute on the file: attrib +r “C:Documents and SettingsDefault UserLocal SettingsTempWSS_AdminService.log”
  2. Denying access to the Local System account:
    icacls “C:Documents and SettingsDefault UserLocal SettingsTempWSS_AdminService.log” /deny “NT AUTHORITYSYSTEM”:F

I have seen on some blogs that you could configure a user profile to that service by changing the account that is running it and therefore grant you the flexibility to redirect the profile to another partition. From the informal conversations I had with MS support, this would void supportability since the SPAdmin service is meant to run exclusively under Local System .

If you wish to keep it while managing its size, you can set-up a scheduled task that would delete the file if it goes beyond a certain size, taking care of archiving it as necessary. BTW, the service does not set an exclusive lock on the file permanently so as long as it does not write to it, there is nothing preventing its deletion.

Finally, you can also enable the compression on that file (log files usually shrink well, expect a 5 to 1 ratio): compact /c “C:Documents and SettingsDefault UserLocal SettingsTempWSS_AdminService.log”

I will later post a PoSH script to tidy up the log file and running as schedule task.

Marc


Leave a comment

SharePoint 2007: KB983444 (MS10-039) Might Break your SharePoint Installation on SBS

Do you remember when WSS/MOSS SP2 used to break SharePoint deployments on Small Business Server? Well it is almost the same story here: if you install the June 2010 Security Update for Windows SharePoint Services, it might break your SharePoint if it’s running on SBS.

Fortunately, MS’ Official SBS has already posted the solution (hang on, you may have to retry a bit before it actually works):

Marc


SharePoint: A Bunch of issues with Windows Vista and SharePoint Explorer View

It’s critical to keep systems up-to-date with patches, the 4 issues described hereunder prove it again 😉 They affect Windows Vista only, not 7 or XP. Certainly because the WebClient went through a serious revamp with Vista, Seven drawing benefit from product maturation.

 

Explorer View does not work when connection goes through a forward proxy asking for authentication

When browsing a SharePoint site through a forward proxy (or simply web proxy) server requiring authentication, everything is working fine but when switching to Explorer viewing or simply trying to open an MS Office document, whether you directly get an “Access Denied” message or you get prompted multiple times for authentication (pop-up windows).

This problem occurs because early Vista’s implementation of the WebDAV redirector (aka WebClient) used by the Explorer do not handle correctly the HTTP Response 407 (Proxy Authentication Required)

Solution: install this hot fix (http://support.microsoft.com/kb/954807) or install Vista Service Pack 2. note: the hot fix requires SP1 to be present

 

Explorer View does not automatically forward credentials if the site does not belong to Local Intranet zone

A tricky one: let’s say that a user is browsing a SharePoint site that belongs to the Trusted Sites security zone of Internet Explorer while the browser is configured to automatically forward credentials for that zone (non-standard config). Although it will work fine with the browser, it will miserably fail with the Explorer View because on vista, WebClient does not rely on Internet Explorer security zones configuration and therefore does not automatically forward credentials under some circumstances.

Solution: Install this hot fix (http://support.microsoft.com/kb/943280) or install Vista Service Pack 2 and configure registry as described in the MS KB article related to the hot fix (this step is mandatory).

 

Explorer View does not automatically forward credentials if IE’s proxy setting check box “Automatically detect settings” is cleared

Pretty much derived from the previous issue, this one will behave identically.

Solution: install this hot fix (http://support.microsoft.com/kb/941853) or install Vista Service Pack 2

 

Explorer View might merge merge cookies leading to authentication issues (or other issues as well)

Cookies are often used to maintained state and sometimes to allow some kind of authentication mechanism, like form-based authentication.

In the case of authentication, products such as ISA/IAG/TMG may use so called “persistent” cookies to allow application to share authentication. This is typical when you want to seamlessly switch from a browser to an MS Office application when working with SharePoint.

Apparently, Vista’s implementation of the WebClient may accidently merge cookies when passing them to the web server or gateway, making them unusable.

Solution: install this Internet Explorer Cumulative Security Update (http://support.microsoft.com/kb/972260/), which also includes functional updates solving that problem…

Credits go to Pascal B and Nicolas S both MSFT for this one. Thanks guys!

 

Marc


Leave a comment

SharePoint 2007: A Clockwork Orange – Some Timer Job Issues without Beethoven…

Long time without any post? Yeah sorry March has been a pretty busy month! I’ll try to empty my backlog in the coming two weeks, I swear 😉

Recently, a production deployment of MOSS gave me the opportunity to revisit 3 interesting issues worth mentioning here.

Some Timer jobs are failing with the error “An update conflict has occurred …you must re-try this action.”

This is the consequence of an inconsistency between the timer jobs definition in the configuration database and a cached copy of them under the form of XML files located on each SharePoint server under %ALLUSERSPROFILE%Application DataMicrosoftSharePointConfig. The reasons why these inconsistencies may occur are various but the fix is common (hopefully):

  1. On every server of the farm, stop the service “SPTimerV3”
  2. On every server of the farm, delete the folders named with GUID-like names. note: you will not lose any data since these are cached copy from the database
  3. On every server, restart the service “SPTimerV3”
  4. From any server, trigger the execution of the timer jobs by executing stsadm -o execadmsvcjobs from a command-line
  5. Inspect the application event logs, the error should not occur anymore

Greetings to P Erol Giraudy and EtienneL, some MVP’s behind the excellent Club MOSS France!

The previous instance of the timer job ‘Config Refresh’, id ‘{573BE459-DF82-481C-84BD-CA14D287450B}’ for service ‘{49A27252-A326-4EF1-B698-6EBC7068833C}’ is still running, so the current instance will be skipped. Consider increasing the interval between jobs.

This error will show up on the server hosting the Web Front-end role after installing and older security update related to the .Net Framework (MS07-040).

To fix it, there is actually nothing to change in the way time jobs are scheduled, only in the way error messages are handled and reported to the event log and to the trace logs.

Look at this MS KB article for the detailed solution and explanation: http://support.microsoft.com/kb/941789/

Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

An “old” issue too but still requiring extra attention. The Timer service may report this error while you are unable to open an IIS console or this console will open but remain desperately empty…

This issue is not cause by SharePoint but by the management API that sits between SharePoint and IIS: ADSI. ADSI does not seem to like when more than one thread is used to access IIS configuration and throws this exception making believe that “memory is corrupt”. Frankly speaking, the first time I saw that, I was rather considering DEP as the culprit 🙂

To regains access (for a short period until the next timer job touching IIS runs) to the IIS console, you can perform IISRESET or simply reboot the server.

To fix the problem, you’ll have to install the appropriate hot fix as stated here in the corresponding MS KB article FIX: You may be unable to manage IIS by using Server Manager if two threads access IIS at the same time.

 

Now time form some ultra-violence enhanced by Beethoven’s music 😉

And cut!


Leave a comment

SharePoint 2007: Search Administration, index propagation and .Net 3.5 install fail

Last week the road was rockier than ever in order to get MOSS 2007 properly deployed in a relatively strict security environment. We experienced 4 funny, though show stopping issues, that were hopefully relatively easy to solve!

.Net Framework 3.5 Installation report error message “The application has requested the Runtime to terminate it in an unusual way”

This is an ‘”old” issue caused by the fact that in a security-hardened environment, the Print spooler service might be set to disabled while the .Net Framework setup needs it in order to install the XPS print driver… Yeah, dependencies show up where you don’t really expect them ;).

Take a look at these resources which are really helpful though a little outdated:

 

MOSS Search Administration Page fails with error “Authentication failed because the remote party has closed the transport stream”

I already met this error under different circumstances: it usually means that the remote web server you’re trying to access requires SSL communications but the server certificate it uses is corrupt or invalid.

My first reaction was: but we don’t use SSL for our Central Admin or SSP so why would it require it then?

Simply because the Search Administration console uses it to communicate with Web Services hosted on each SharePoint server in the farm and in this case, with the query servers in particular.

After some investigations, the excellent tool SSL Diag reported that the server certificate was corrupted on nearly all servers in our farm… How could this happen?

Apparently, this is the consequence on combining the following elements:

  • The server that is running Office SharePoint Server 2007 has the query role in a server farm
  • The server farm was updated with Microsoft .NET Framework 3.5 Service Pack 1 (SP1)
  • The roles of the query server and the index server are not on the same server in the server farm.

And the issue as well as its solution are documented at MS Support under the KB article 962928: http://support.microsoft.com/kb/962928.

Note: although MS says it only affects the Query servers, the server certificate was corrupt on all servers except the Index… So we decided to fix it everywhere for optimal farm sanity.

 

MOSS Search Administration is unable to retrieve the status of index propagation on Query Servers

The real issue is that actually, the Index server is unable to propagate (read ‘”copy”) the index files and configuration to the query servers because the shared folder “searchindexpropagation” is missing since it could not be created at setup time.

Martin Kearn (MS MCS Consultant in UK) also reports the issue in locked-down environment (Windows Server 2008 in particular): http://blogs.msdn.com/martinkearn/archive/2008/10/29/manually-configuring-search-propagation-location-using-stsadm.aspx.

Talking about Martin Kearn, make sure you update your RSS Reader with the address of the new blog run conjointly with all UK SharePoint MCS Consultants: http://blogs.msdn.com/uksharepoint/

 

And finally, even the SQL Server cluster decided to bring its own set of issues, consequently bringing our SharePoint farm down…

Fortunately this one was easier to troubleshoot since it is almost and “old friend”: Cannot generate SSPI context.

The 3 resources hereunder will help tracking the root cause of the problem:

 

This interesting troubleshooting day reminded me Mr Spock saying “Logic, logic, logic. Logic is the beginning of wisdom, not the end”. This was is Start Trek VI: The Undiscovered Country. My favorite ST movie with the TOS crew. Christopher Plummer playing General Chang was simply great!

Star Trek VI: The Undiscovered Country Poster

And cut!


SharePoint 2007: Using PowerShell to Retrieve all Servers in a Farm

I often have to perform maintenance or configuration activities on all servers members of a SharePoint farm suchs as archiving or parsing logs, recycling IIS application pools… While you could simply store all servers’ name in a plain text file, I always prefer a more dynamic way and as usual now, PowerShell will do the job.

Begin with loading the assembly…

[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")

Then connect to the farm:

$spFarm = [Microsoft.SharePoint.Administration.SPfarm]::Local

And finally populate an array with all servers:

$spServers = $spFarm.Servers|Select Farm,DisplayName,Address,Role

Now the problem with this array is that it also contains servers that are not real servers but rather “network names” such as the SMTP host for mail-out or the SQL database server name and instance. If you want to retrieve only server where SharePoint is installed and running, use this filter

$arrServers = $spFarm.Servers|Where {!($_.Role -eq 'Invalid' -and $_.Status -eq 'Online')}|Select Farm,DisplayName,Address,Role

Note: the Role will help you identifying a WFE from and application Server, for example. The address is the real host name used for network connectivity while the Display Name is, like its name suggests it, the text used for displaying the Central Admin.

And cut!

PS: Finally my “assistant director” Anthony (the Minghella of PowerShell, the Hopkins of automation or should I say, the Zuiker of scripting;)) has finally caught his digital pen to shoot ahem.. I mean write, his first post. Welcome online Antho!


Leave a comment

SharePoint 2007: MySolution.WSP has an unsupported extension, and cannot be added to the solution store

A member of my team busy with SharePoint deployment industrialization came to me with this strange error message resulting from a “usual” STSADM –o addsolution command.

I quickly skip the detailed enumeration of the usual suspects (corrupt CAB, system A-V, path with spaces…) to jump straight to the root cause: STSADM (or the SharePoint API) handles the file name’s extension with case sensitiveness and therefore did not support having the filename parameter’s value containing .WSP while with the actual file name is is .wsp! We adapted the script to rigorously use the same file name as it is in the file system and it finally worked as usual… Wow, SharePoint has some hidden *NIX behavior sometimes 😉

And cut!