To change the default .NET Framework Version in IIS 7 and IIS 7.5 to .Net 4.0 follow these steps:

1. Select the root element in the tree on the left – it contains the name of the server.
2. Click on the "Change .NET Framework Version" link on the right panel. You will now see the "Change .NET Framework Version" dialog.
3. Select the .NET 4.0 framework from the drop down list.
4. Click [OK].

I hope that helps!

via Deploying .NET 4.0 applications using IIS 7.x

The following is taken from Configure Remote PowerShell in SharePoint 2010

Setup your Remote Server
There are a few steps you have to take on your server to initialize and set it up running for remoting. once.
First, you need to run the following command on your server — Enable-PSRemoting

Next you need to let powershell know that your server machine or remote machine will act as the server.

Enable-WSmanCredSSP -Role Server

Setup your Client Computer
There are also a few one time setup steps you need to take on your client computer. You only have to do this once. The first thing to do, if you are going to use the logged in user’s credentials to make a remote session in powershell, is to enable client credentials delegation. This can be achieved by changing the group policy.
First, edit group policy on your client computer to all credential delegation. Using gpedit.msc, enable both of the following (Under Local Computer Policy–> Computer Configuration–> Administrative Templates–> System–> Credentials Delegation):

• Allow Delegating Fresh Credentials
• Allow Delegating Fresh Credentials with NTLM-only Server Authentication

Note: In case you are going to explicitly specify the credentials, you can skip the above step.

Second, run the following command
Enable-PSRemoting

Third, enable WSMan CredSSP with the following command:
Enable-WSManCredSSP -Role Client –DelegateComputer “NameOfServer”

Once you have configured remote powershell, now you are all set to run remote commands.

Create and enter a remote session of Windows PowerShell
If your current user on client machine has permission to the SharePoint farm and Windows PowerShell on the remote box, you can use Enter-PSSession to create and enter the remote session.
For example, connecting to machine SpServer…

Enter-PSSession -ComputerName SPServer
If it works, the command prompt will be changed to [SPServer]: PS C:\Users\Administrator\>.
The session will be closed when you type exit or Exit-PSSession.

To connect to a machine with CredSSP and a different credential, you can use
Enter-PSSession -ComputerName SPServer -Authentication CredSSP –Credential domain\username
This will open up a dialogue for you to type in password. Type in the password and press enter and your remote session will be created.

Store and use credentials for scripting

First, use the following command to covert password from keyboard input to a secure string in a text file.

Read-Host -AsSecureString | ConvertFrom-SecureString | out-file C:\crd-sharepoint.txt

As soon as you type the command, start typing the password.

When you need to create a credential object, read this password (the secure string) from the file and create the credential with the following command:

$pwd = Get-Content C:\crd-sharepoint.txt | ConvertTo-SecureString

then create the credential (replace #### with your domain\username):

$crd = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "####",$pwd

Then you will be able to use this credential in the command line without any dialogue.

$session = New-PSSession -computername "SPServer" -Authentication CredSSP -Credential $crd

Start Remoting on you Client Computer

Now your client computer is ready to actually create the session and import the SharePoint commands from the Server.

The next command adds the SharePoint PowerShell commands to your session.

Invoke-Command -Session $session -ScriptBlock{Add-PsSnapin Microsoft.SharePoint.PowerShell}

Note, that at this point, you can run whatever administrative PowerShell commands you need to run by using the Invoke-Command -Session $session -ScriptBlock{} syntax.

Importing remote commands into local session

Let’s see how one can import a remote command into a local session. First – let’s ask Import-PSSession cmdlet to look in the remote session $s, take all the remote commands matching "*-SPFarm" wildcard, add a "Remote" prefix to their noun, and then present them to me as if they were local commands:

Import-PSSession -Session $session -CommandName *-SPFarm -Prefix Remote

So, now we can run Get-RemoteSPFarm

Thanks again Configure Remote PowerShell in SharePoint 2010

After applying the latest Windows updates for Windows Server 2003, we received many “Timed Out” errors when trying to run content deployment jobs.  The main culprit of there errors seemed to be the OWSTIMER.EXE process and it taking 100% of the CPU… yeah, I know “it’s a pain!”

Anyway, one of the things I did to try and get the issue resolved was to clear out the years of Content Deployment objects that had built up on the target server.

This was a 2 step process:

1. Find all the Content Deployment Job objects in the config database and get their IDs

   select * from Sharepoint_Config.dbo.[Objects]  where [Name] like 'ContentDeploymentJobDefinition%'

2. Run an stsadm command to delete the object based on its ID
   

   STSADM -o deleteconfigurationobject -id "<object id>"

I was able to do some text manipulating and get a really long .bat file that ran for a really long time. When it was done, all the Content Deployment Job objects were gone.

However, it did not seem to fix my issue with OWSTIMER.EXE taking 100% of the CPU.

The solution for that seemed to be narrowing down which Content Deployment Job was causing the issue by disabling them all and then re-enabling them one at a time and deleting the target site collection and doing a full deployment.

I ran across an issue this morning that had the Sharepoint WSS Search Server in a “Pausing” state.  I had to restart the Office SharePoint Server Search service in order to resolve the issue.

Now to see if it will complete successfully.

Today, I came across a Windows Service on a server that I inherited. By the name of the service I could tell that it was built in-house and I even found enough information to determine who the developed it.  However, since it was not in the Add / Remove Programs list of the Control Panel, I wasn’t sure how to remove it.  So, I found the following on Geeks With Blogs – Shahed’s Blog:

Recently, I was trying to delete a windows service. Normally it should not be necessary to manually delete a service. Uninstalling an application should remove its associated service (if any).

However, I installed some beta products and a service created by one of the applications was not removed automatically. Its very easy to remove a service from registry if you know the right path. Here is how I did that:

1. Run Regedit or Regedt32

2. Find the registry entry "HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services"

3. Look for the service there and delete it. You can look at the keys to know what files the service was using and delete them as well (if necessary).

alternatively, you can also use command prompt and delete a service using following command:

sc delete < SERVICE name>
or to create, simply type
sc create <SERVICE name>

Update:
If you have space in the file path you need to use quotation marks ("). For example: 
sc create "MySQL" binpath= "C:Archivos de programaMySQLMySQL Server 5.1binmysqld.exe"

I used the “sc delete” method to remove the service.

Thanks, Shahed!

Did you know that there is a script that was shipped with Windows 2003 SP2 that allows you to recycle your IIS Application Pools.

Below is the command that you use from the command line:

[code lang="dos"]
Description: list IIS application pools and associated worker process
             Recycle application pools.

Syntax: IIsApp.vbs [{ /a  | /p  } [/r] ]

Parameters:

Value              Description
/a    Specify an application pool by name. Surround
                    with quotes if it contains spaces.
                   If used alone without an accompanying action,
                   IIsApp.vbs will report PIDs of currently running
                   w3wp.exe processes serving pool .
/p            Specify a process by process ID. If used alone
                   without an accompanying action, IIsApp.vbs will
                   report the AppPoolId of the w3wp process specified
                   by . When a PID is specified with /r, that PI
                   is mapped to an application pool and the action is
                   taken upon the application pool. If a PID is given
                   for a web garden, i.e. an application pool served
                   by more than one w3wp, then all w3wp's for that
                   application pool will be acted upon.
/r                 Recycles the application pool.

DEFAULT: no switches will print out the PID and AppPoolId.

Examples:

IIsApp
IIsApp /p 2368
IIsApp /a DefaultAppPool /r
IIsApp /p 2368 /r
[/code]

While working to email-enable SharePoint lists I ran across a great post on Microsoft Support about testing SMTP:

SMTP relay behavior in Windows 2000, Windows XP, and Exchange Server

The basic test:

Start a command prompt.

Type telnet ServerName 25, where ServerName is the SMTP server name or IP address and 25 is the port number, and then press ENTER.

Type EHLO, and then press [ENTER].

At the Telnet session prompt, type RSET. The telnet session responds with text that is similar to the following:

1. 250 2.0.0 Resetting

2. Type MAIL FROM:UserName@DomainName.tld, where UserName is the name of the user, DomainName is the name of the domain, and tld is the top level domain such as .com or .net.
   The telnet session responds with text that is similar to the following:

3. 250 2.1.0 UserName@DomainName.tld….Sender OK

4. Type RCPT TO:RecipientName@DomainName.tld, where RecipientName is the e-mail address of the recipient.
   The telnet session responds with text that is similar to the following:

5. 550 5.7.1 Unable to relay for RecipientName@ DomainName.tld