Mariusz, Gorzoch tech Blog

Archive for October 2009

Hyper-V, snapshots and LOW DISK SPACE !

with 2 comments

Did anyone ever told you to watch carefully your disk space when playing with snapshots on Hyper-V ? Be careful, because if you are not doing so, then you can get in troubles I get. In the nutshell, if your machine has at least one snapshot, then she is recording all differences in special “avhd” file. This file get bigger and bigger and guess what : it will fill you disk and scream for more, and what is the worst : if you don’t gave her what she need she will refuse to work. If you get to this point what you need is to delete snapshot and shutdown your machine for start merge process:

if you are lucky and have space on the drive, then you are done, but if you don’t then as someone on one blog said, you are in deep sheet. Lucky I found solution how to safe your time. What I assume here is that your snapshot file is on the same drive when your vhd file. The secret lays in the XML configuration file of the machine (in my case it was something like that : 54816D20-3A17-4C42-A777-2857D27F894D.xml and it was placed in the folder when I’ve asked Hyper-V manager to save my machine setting). If you open this file (remember to shutdown entire Hyper-V service before doing so), you should be able to find line like this one:

as you can guess you can tweak-up this line and move you snapshot file to different drive and by this free some space to let merge process complete. In my case what I did is, that I moved the snapshot file to new drive, start the Hyper-V service, start the machine and later on shut it down – this will start merge process.



Written by Mariusz Gorzoch

28 October 2009 at 20:37

Posted in Bez kategorii

How to not apply cumulative updates for SharePoint

leave a comment »

If you ever done installation of cumulative updates for SharePoint you probably know that your need to do this right, otherwise you can end up having quite big trebles

so, what is the proper order ?

Let’s assume that you have a MOSS farm which contain two machines, and SQL box. First machine is hosting central administration and second one contain front-end hosting our site to users. If we agree on that, the proper direction should be like that:

  • first we download proper packages (yes!, packages). One package for WSS and second package for MOSS (remember to choose proper bit version)
  • now, we are starting installation. First go to the central administration server and fire-up installation of WSS CU. When you installing CU, you always need install WSS package first. This is really important to remember and it doesn’t meter if you are before or after sp2 (I found some blogs on net where people were saying that after sp2, you don’t need to go for WSS packages – THIS IS NOT TRUE! – you still need to go for WSS first).
  • When installation get completed, then you are fire-up “Product Configuration wizard” and hit next, till the time, when wizard will ask you to install binaries on all other machines. In this moment we DO NOT press ok, but instead of that we are switching to the second machine (the one which is not hosting central administration) and we are starting the installation of the same package. This time we wait until the installation complete and we are coming back to the “Central administration” server
  • On the central administration server we should have message box from wizard waiting with the button “OK” to be pressed. Now, when binaries are installed on the front-end we can press this button and wait until the end of configuration. As soon configuration will be done, we are switching to front-end server
  • Now on the front-end server we are starting “Product configuration wizard” and proceeded until the last screen (hitting “OK” button in mean time, when SharePoint will ask you to install binaries on all other machines)
  • Brilliant! WSS CU are installed, now it is time for MOSS CU
  • The procedure here is the same. First we are going to “Central administration server” and starting installation of the package. We proceed here until the end of installation and just right after that we are starting “Product and configuration wizard”. When we do so, we proceed with “Next” button until we get message, that binaries should be installed first on other machines in the farm. As before now we are going to “Front-End” server.
  • On the front-end server we are doing installation of the MOSS CU binaries and as soon we are done we are coming back to the “Central administration” machine and hitting “OK” button on the screen which question to install binaries on all other machines. Now we are proceeding to the end of configuration wizard. When this process complete, then we are going to “Front-end” machine and starting configuration wizard. This time we are not waiting on the screen with “OK” button, but just hitting it and moving to end of the wizard.

Done it!

Written by Mariusz Gorzoch

22 October 2009 at 21:05

Posted in Bez kategorii

TF30267: Exception: System.Web.Services.Protocols.SoapException

leave a comment »

As I found few days ago, solution to solve problem around SharePoint “No exact match found” in people picker did not work as well as it should be. After applying ideas described there you will correct problem with setting permission for the users on your sites, but if you one day go to the “Central administration”->”Site collection administrators” you will end-up with exactly the same “No exact match found” problem.

Thing can even can go worst ,as if you are using in your environment “Team foundation server” then you will find-out that you cannot create new “Team project”. Of course those two things are connected, as creation of “Team project site” involves creation of SharePoint site and as SharePoint cannot recognize you as a valid user, then he cannot create site for “Team project” and entire process crashes. If you go to the error log for project creation you can find this:

2009-10-15 11:17:28Z | Module: WSS | Thread: 22 | Verifying site template exists on the server using http://gdansk-tfs:9822/_vti_bin/Sites.asmx
2009-10-15 11:17:31Z | Module: WSS | Thread: 22 | Creating site with the following parameters
2009-10-15 11:17:31Z | Module: WSS | Thread: 22 | Admin Url: http://gdansk-tfs:9822/_vti_adm/admin.asmx
2009-10-15 11:17:31Z | Module: WSS | Thread: 22 | Site Url: http://gdansk-tfs/Sites/Exchange%20rates%20processing
2009-10-15 11:17:31Z | Module: WSS | Thread: 22 | Site Title: Exchange rates processing
2009-10-15 11:17:31Z | Module: WSS | Thread: 22 | Site Description: This team project was created based on the ‘MSF for Agile Software Development – v4.2’ process template.
2009-10-15 11:17:31Z | Module: WSS | Thread: 22 | Locale: 1033
2009-10-15 11:17:31Z | Module: WSS | Thread: 22 | Template: _GLOBAL_#2
2009-10-15 11:17:31Z | Module: WSS | Thread: 22 | Owner Login: DEV\mgo
2009-10-15 11:17:31Z | Module: WSS | Thread: 22 | Owner Name: Mariusz Gorzoch
2009-10-15 11:17:31Z | Module: WSS | Thread: 22 | Owner Email: mgo@hempel.com
2009-10-15 11:17:36Z | Module: WssSiteCreator | Thread: 22 | TF30267: Exception: System.Web.Services.Protocols.SoapException: Exception of type ‘Microsoft.SharePoint.SoapServer.SoapServerException’ was thrown.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   at Microsoft.TeamFoundation.Proxy.Portal.Admin.CreateSite(String Url, String Title, String Description, Int32 Lcid, String WebTemplate, String OwnerLogin, String OwnerName, String OwnerEmail, String PortalUrl, String PortalName)
   at Microsoft.VisualStudio.TeamFoundation.WssSiteCreator.CreateSite(WssSiteData siteCreationData, ProjectCreationContext context)
   at Microsoft.VisualStudio.TeamFoundation.WssSiteCreator.Execute(ProjectCreationContext context, XmlNode taskXml)
—begin Exception entry—
Time: 2009-10-15 11:17:36Z
Module: Engine
Event Description: TF30162: Task "SharePointPortal" from Group "Portal" failed
Exception Type: Microsoft.TeamFoundation.Client.PcwException
Exception Message: The Project Creation Wizard encountered an error while uploading documents to the Windows SharePoint Services server on gdansk-tfs.
Exception Details: The Project Creation Wizard encountered a problem while uploading
documents to the Windows SharePoint Services server on gdansk-tfs.
The reason for the failure cannot be determined at this time.
Because the operation failed, the wizard was not able to finish
creating the Windows SharePoint Services site.
Stack Trace:
   at Microsoft.VisualStudio.TeamFoundation.WssSiteCreator.Execute(ProjectCreationContext context, XmlNode taskXml)
   at Microsoft.VisualStudio.TeamFoundation.ProjectCreationEngine.TaskExecutor.PerformTask(IProjectComponentCreator componentCreator, ProjectCreationContext context, XmlNode taskXml)
   at Microsoft.VisualStudio.TeamFoundation.ProjectCreationEngine.RunTask(Object taskObj)
—   Inner Exception   —
Exception Type: System.Web.Services.Protocols.SoapException

Which is not very helpful. Anyway, this problem is caused by SharePoint and because he cannot recognize you as a valid user (funny thing is that he will recognize you when you try to log into you default and central admin site)

In my case reason of the problem comes from installation one of the cumulative updates (I’m even not sure which was it – probably the august 2009 one) and that this patch change something around SharePoint, that he will start not recognize users if application pool for central administration is hosted by the local box account (including network service). Solution for that is to switch application pool account used to host your central administration pool to use domain account. When you have such account this can be quite fast done by issuing command:

stsadm –o updatefarmcredentials –userlogin <yourDomain\userInDomain> –password <passwordForThisUser>

+restart of the IIS and the problem should disappear.

Written by Mariusz Gorzoch

16 October 2009 at 10:02

Posted in Bez kategorii

No exact match was found

leave a comment »

Every thing was working fine, till today, when suddenly “people picker” control stop accepting users from the domain where my SharePoint box is placed. Woow… I was completely lost as I have no idea what can cause this problem. I’ve checked machine configuration (server was still inside domain), DNS, ping-pong to domain and everything was fine. The only exception was SharePoint itself as he stop accepting my domain users and only let to use local box users.

On the end I found this post : http://suguk.org/blogs/sharepointhack/archive/2009/02/05/16960.aspx 

it says that to correct “people picker” AD search properties you need to issue two commands:

1. stsadm –o setapppassword –password MyPassword 

2. stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:YourDomain.com,domain\user,password –url relevant web application

I did it and my “People picker” was working fine again.

If you encounter similar problem – try this.

Written by Mariusz Gorzoch

6 October 2009 at 14:36

Posted in Bez kategorii

Session state and cross domain IFrame problem

with one comment

Today I encounter strange behavior and really stuck for one day with work as I was completely lost what is the problem. In general I’ve create application with was going to be exposed in our external IIS server inside IFrame object:

So, the application surrounding IFrame was build be someone else and was placed in different domain then main application and was complete out of my control. In first place, when I was testing my application outside of IFrame object – everything works perfectly fine. Then when I moved it to IFrame, everything stooped to work. As I mentioned on the beginning I was looking for the solution on that, and found that it helps if I open my application outside of IFrame in second browser and if I will get back to the IFrame version of the application – then everything looks fine.

… on the end I found reason of the problem …

The problem was that I wasn’t aware that if you are placing your application inside IFrame and if the hosting application is placed in different domain then yours application then you will not have access to cookies, and by this each time you make a post back, then the session will get new ID, which will of course crash application (as it was depend on the session state). To correct this I need to tweak-up my web.config to stop using cookies for storing session ID and instead of that use URL to do so. In case of framework 2.0 this can be done by adding this section:

    <sessionState cookieless="true" mode="InProc"></sessionState>

if you will go for this, then you tell IIS engine to not use cookies and store Session ID in the URL send back and forth to the users. In my case this solve the problem.

here is an overview of this section on msdn : http://msdn.microsoft.com/en-us/library/h6bb9cz9.aspx

Written by Mariusz Gorzoch

2 October 2009 at 14:18

Posted in Bez kategorii