Log4net can be made to read it’s configuration from any file in the file system. One of the easiest ways to do this is to add an assembly reference to the AssemblyInfo file. The example that follows is one that I use for C# projects.

[assembly: log4net.Config.XmlConfigurator(ConfigFile =
  @"C:\Program Files\Common Files\Microsoft Shared\" +
  @"Web Server Extensions\12\CONFIG\log4net.config", Watch = true)]

As I said you can locate the config file anywhere in the file system. I put it in the CONFIG folder of the SharePoint hive simply for convenience.
You will need to execute the following to ensure that log4net opens the config file.

            log4net.Config.XmlConfigurator.Configure();

If you find that logging does not occur then try explicitly forcing log4net to open your config file.

            string log4netConfig = @"C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\CONFIG\log4net.config";
            FileInfo log4netInfo = new FileInfo(log4netConfig);
            log4net.Config.XmlConfigurator.ConfigureAndWatch(log4netInfo);

So any process that uses the assembly and logs using log4net will now pick up its configuration from one source. This you might think is a neat solution. Well it is but it comes with a caveat. The log file once opened will be held open by the process. This will result in unreliable logging. Log4net fails silently so you could be lulled into thinking that all is well. In fact a little care is required here. Take this scenario – a workflow starts execution under a W3P process, the process is terminated when the application pool recycles. This does not present a problem for the workflow as it is simply dehydrated and stored in SQL server. When the process restarts it will be the OWSTIMER process that wakes it up and takes ownership. Now whichever process is first to open the log file is the process that will deny access to the other. Logging for one of the processes will stop!
Thanks to log4net’s type=”log4net.Util.PatternString” the problem is easily solved.
Here is an example of a RollingFileAppender that will ensure that logging is directed to process based log files.

	<appender name="eSpaceFileAppender" type="log4net.Appender.RollingFileAppender">
    <file type="log4net.Util.PatternString" value="c:\temp\workflows - [%processid].log" />
		<appendToFile value="true" />
		<rollingStyle value="Composite" />
		<datePattern value="yyyyMMdd" />
		<maxSizeRollBackups value="10" />
		<maximumFileSize value="1MB" />
		<layout type="log4net.Layout.PatternLayout">
			<conversionPattern value="%date [%thread] %-5level %logger  - %message%newline" />
		</layout>
	</appender>

The issue I found was that the authentication chain had broken down with the new certificate because it was no longer trusted by the SharePoint root authority. This could be seen because the thumbprint of the cert listed against the SPTrustedRootAuthority differed from that of the new cert being used by ADFS for token signing. This issue was manifesting itself in a variety of ways from server errors to ‘cannot display this web page’ messages.

In the event log AD FS 2.0 was reporting an error with Event ID 364

Encountered error during federation passive request.

Exception details:
System.ServiceModel.Security.MessageSecurityException: An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault...

SharePoint Foundation also reported an error in the Application event log. This time the Event ID was 8311 with a Task Category of Topology.

An operation failed because the following certificate has validation errors:\n\nSubject Name: CN=ADFS Signing - login.3guysonsharepoint.com\nIssuer Name: CN ADFS Signing - login.3guysonsharepoint.com\nThumbprint: 5F8B59F71E0A47988D35464442FB1CEA\n\nErrors:\n\n The root of the certificate chain is not a trusted root authority..

To solve the issue

1. Export the token signing certificate from ADFS
2. Update the trusted root authority in SharePoint (SPTrustedRootAuthority)
3. Update the SPTrustedIdentityTokenIssuer

Export the token signing certificate from ADFS

1. Open the AD FS 2.0 Management console
2. Click on AD FS 2.0 > Service > Certificates
3. Find your new primary token-signing certificate and select View certificate from the right hand pane
4. From the Details tab select Copy to File… and export the certificate. Do not export the private key if offered as an option.
5. Save the cert to a location on your file system

Update the trusted root authority in SharePoint (SPTrustedRootAuthority)

1. Open a SharePoint Management Console window, i.e. PowerShell
2. Find the Trusted Root Authority for the existing certificate. Note down the ID property of the authority and check that the certificate thumbprint matches that seen in the error message:
   Get-SPTrustedRootAuthority
3. Create the new certificate object:
   $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\updates\newadfs.cer")
4. Update the SPTrustedRootAuthority using the Set-SPTrustedRootAuthority cmdlet. Use the ID of the relevant SPTrustedRootAuthority that you noted down in step 2 as the -Identity parameter.
   Set-SPTrustedRootAuthority -Identity "5F8B59F7-1E0A-4798-8D35-464442FB1CEA" -Certificate $cert
5. Check that the thumbprint of the certificate is reflecting the thumbprint of the new token-signing certificate in ADFS:
   Get-SPTrustedRootAuthority -Identity "5F8B59F7-1E0A-4798-8D35-464442FB1CEA"

Update the SPTrustedIdentityTokenIssuer

In the existing or a new SharePoint Management Console window, i.e. PowerShell

1. Find the SPTrustedIdentityTokenIssuer that is configured to provide claims token for the application and note down the Name of the authority that is using the offending token-signing certificate – this can be verified by checking the certificate thumbprint.
   Get-SPTrustedIdentityTokenIssuer
2. Update the SPTrustedIdentityTokenIssuer with new certificate, provide the Name of the Token Issuer.
   Set-SPTrustedIdentityTokenIssuer "ADFS" -ImportTrustCertificate $cert
3. Verify that the SPTrustedIdentityTokenIssuer is using the new token-signing certificate
   Get-SPTrustedIdentityTokenIssuer "ADFS"

You should now be able to log in as before to your claims-based SharePoint enviornment via ADFS. I should probably point out that even if you were not using the auto certificate rollover feature of AD FS 2.0 and were instead manually changing token-signing certifcates you would still get this issue. These steps should work for this too. I have not tested this however…

=IF(TEXT([Column Name],”hh:mm”)=TEXT(HOUR(TIMEVALUE([Column Name]))&”:”&MINUTE(TIMEVALUE([Column Name])),”hh:mm”),TRUE,FALSE)

Column Name is a ‘Single Line of text’ field.

Scenario:
1.Search for the term ‘Virtual’ and results are returned
2.Search for the term ‘Virtual’ again and an ‘Invalid request’ is returned
3.Search for the term ‘Exchange’ and results are returned.
4.Search for the term ‘Virtual’ and results are returned.

I battled with this issue for some time. It turns out to be an IE10 issue. The problem is not seen when using Chrome or IE9.

UPDATE:
Found it.
Free Download Manager Explorer add-on.
Uninstalled Free Download Manager and all now works Tickety-Bo!
Sorry SharePoint and IE 10.

Scenario
1.Create a new Document Library accepting all defaults
2.Add a document to the library
3.Edit the properties of the document and save.
RESULT: The server was unable to save the form at this time. Please try again.
4.Enable ‘Manage content types’ in the library setting.
5.Add the ‘Link to a document’ content type.
6.Edit the properties of the document and save.
RESULT: Fixed

The problem turns out to be with IE10. Chrome and IE9 do not exhibit this problem.

UPDATE:
Found it.
Free Download Manager Explorer add-on.
Uninstalled Free Download Manager and all now works Tickety-Bo!
Sorry SharePoint and IE 10.

1. Prior to installing Windows 8 make copies of all of the VMware vms that you want to convert. Never burn your bridges:)
2. Remove all snapshots from each VM.
3. Add a 5gb IDE hard drive to each VM.
4. Start each VM in turn and remove VMware tools, then shutdown the VM.
5. Using the VM settings, remove the 5gb IDE drive from each VM. DO NOT restart the VMs after this.
6. Download Vmdk2Vhd.
7. Convert each .VHDK file to .VHD.
8. Install Windows 8. If like me you are hoping to upgrade a Windows 7 virtual boot disk then forget it. It is not supported, naughty MS.
9. After installing windows 8, add the HyperV role.
10. Create your new VMs and attach the converted disks.
11. Enable remote desktop in each VM and use it to work within your VMs.