8/28/11

Install ESXi 5 on a USB drive



To install ESXi on a USB drive simply plug the drive into your host, put the installation media (CD) in the drive and reboot the server. The install will start and you can select the USB drive as the installation path, the installer will format and partition the drive for you.

I used a Kingston 4GB drive because I read DELL was actually shipping these with their pre-configured ESX servers, no issues with these USB drives. I was able to free up 2 640GB hard drives from my ESX hosts that were only being used to hold the small ESXi footprint.

You will have to modify your BIOS setting (Boot Order) to ensure that USB - HDD is your first boot device, I changed my Gigabyte motherboard setting to USB-HDD, CDROM, Harddrive and it works great.

Apparently you don't even need any drives in your ESX host(s) now with ESXi 5 you can install Auto Deploy on your VCenter machine and pxe boot your hosts but I like the idea of having these portable USB drives for my installation.

I'm still curious when ESXi actually commits configuration changes to the USB device because I have tried switching the USB drive from one host to another. The issue I came across was switching the USB drive, booting up a host, changing the configuration options and then shutting down. When I tried booting up again it seemed that none of the new configuration options were persisted to the USB drive.

I'll do more testing to try and resolve this but so far I'm real happy with these devices. I have noticed that after ESXi installs on the device, my Windows 7 box will not recognize the drive when I plug it in, I just wanted to format and start over but no luck. What worked for me was plugging the device into my Synology DS1010 NAS and choosing external devices and format. I noticed that there were at least three separate partitions created by ESXi.

8/15/11

Hide Sharepoint controls using a custom masterpage

I was asked to make a site display only the content, hide the header, quick launch bar, site actions button, etc. I started with a minimal masterpage on Codeplex - http://startermasterpages.codeplex.com/

I then added the following css to hide the Sharepoint controls


<style type="text/css">

    #s4-ribbonrow, .ms-cui-topBar2, .s4-notdlg, .s4-pr s4-ribbonrowhidetitle, 
.s4-notdlg noindex, #ms-cui-ribbonTopBars, #s4-titlerow, #s4-pr s4-notdlg 
s4-titlerowhidetitle, #s4-leftpanel-content {display:none !important;}
   .s4-ca{margin-left:0px !important; margin-right:0px !important;}

</style>

The list cannot be displayed in DataSheet view for one or more of the following reasons:

You receive the following error when trying to view a library in Datasheet view:
The list cannot be displayed in DataSheet view for one or more of the following reasons:
- A datasheet component compatible with Miicrosoft Sharepoint Foundation is not installed.
- Your web browser does not suport ActiveX controls
- A component is not propelry configured for 32- or 64-bit support.



Cause: The 32 bit version of Microsoft Office is not installed on the machine that is viewing the page in Internet Explorer


Resolution: Install the 32 bit version of Microsoft Office

Note: The 64 bit version of Microsoft Office is incompatible with the Datasheet view.

Error when trying to view a library in Datasheet view

You receive the following error when selecting Datasheet view in a Sharepoint 2010 library
The query cannot be completed because the number of lookup columns it contains exceeds the lookup column threshold enforced by the administrator.0x8007009

Cause:  List View Threshold feature - If the number of library columns of type Lookup, Person or Group, and Workflow Status exceeds the threshold enforced by the List View Threshold, an error is returned when trying view the contents of the library in the Datasheet view.

Resolution: Change the Resource Throttling settings under Central Administration | Application Management | Manage Web Application | Your Web Application | General Settings | Resource Throttling. Set the List View Lookup Threshold value to a number larger than the number of lookup and workflow status column in the library and view. The default value is set to 8.

8/14/11

Call a SQL Stored Procedure from Powershell with a parameter

Recently I had to write a Powershell script that iterates a text file of user names and calls a stored procedure  to delete users from a database. The text file just contains account names on each line and must be in the same directory as the Powershell script.



$conn = new-Object System.Data.SqlClient.SqlConnection("Data Source=databaseservername;User ID=sa; Password=password; Initial Catalog=databasename")
foreach ($user in Get-Content “UserList.txt”)

{
$conn.Open() | out-null
$cmd = new-Object System.Data.SqlClient.SqlCommand("SP_DeleteUser_By_AccountName", $conn)

$cmd.CommandType = [System.Data.CommandType]::StoredProcedure
$cmd.Parameters.Add("@AccountName",[system.data.SqlDbType]::VarChar) | out-Null

$cmd.Parameters['@AccountName'].Direction = [system.data.ParameterDirection]::Input

$cmd.Parameters['@AccountName'].value = $user


$cmd.ExecuteNonQuery()
$conn.Close()


}

One or more field types are not installed properly. Go to the list settings page to delete these fields.0x81020014



Recently came across this error message after migrating a site from Sharepoint 2007 to Sharepoint 2010. Apparently it is an issue where the relationships list is not updated when migrating a site.

The Relationships List can be found at http://(yoursiteurl)/Relationships%20List/allitems.aspx

As the site collection administrator deactivate the SharePoint Server Publishing Infrastructure feature under Site Settings for the site collection that has the issue. Then delete the Relationships List - http://(yoursiteurl)/Relationships%20List/allitems.aspx.

Re-activate the SharePoint Server Publishing Infrastructure feature and the Relationships List will be recreated, this will correct the problem.

8/12/11

Update Sharepoint Domain Group Name attribute after migrate

If you migrate a Sharepoint Farm into a new domain and use the STSADM -o migrategroup command it does not update the name attribute. The LoginName attribute will be correctly updated. The following Powershell script was written to address this.


The script only updates the display name of the groups, does not alter any security permissions and only looks for Domain Groups with "OLDDOMAINNAME\" in the name attribute.

The script copies the Domain Group LoginName attribute and replaces the name attribute with that value.

The script accepts a URL parameter and will get the web application for the URL you pass in and iterate all the sites in that web application.



[Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=Neutral, PublicKeyToken=71e9bce111e9429c")
#enter a site URL
$siteUrl = Read-Host "Enter Site URL"
$rootSite = New-Object Microsoft.SharePoint.SPSite($siteUrl)
# Get the web application for that site URL
$spWebApp = $rootSite.WebApplication
# Iterate the sites for the web application
foreach($site in $spWebApp.Sites)
    {
# Iterate the users/groups for that site
$group = $site.RootWeb.SiteUsers
foreach ($grp in $group)
{
# Ensure the item is a domain group
if($grp.IsDomainGroup -eq "True")
{
$groupname = $grp.name
if($groupname.Contains("OLDDOMAINNAME\"))
{
$grp.name = $grp.LoginName
$grp.Update()
$outputText = "$spaceBuffer$BUFFER_CHARS<Group>" + $grp.LoginName + "   --Updated"
Write-Output $outputText
}
}
}
}

Allow Code Blocks in a Sharepoint ASPX page


If you experience the following error message on a Sharepoint page that is trying to execute custom code, there is a web.config setting to allow the custom code.

An error occurred during the processing of /mypage.aspx. Code blocks are not allowed in this file.

Reason: SharePoint does not allow server side code to execute in aspx pages contained in the SharePoint site.

Corrective Action: Edit the web.config

<PageParserPaths>
<!-- To allow a single file: -->
<PageParserPath VirtualPath="/mypage.aspx" CompilationMode="Always" AllowServerSideScript="true" />
<!-- To allow global: -->
<PageParserPath VirtualPath="/*" CompilationMode="Always" AllowServerSideScript="true" />
<!-- To allow global within a subsite: -->
<PageParserPath VirtualPath="/mywebsite/*" CompilationMode="Always" AllowServerSideScript="true" />
</PageParserPaths>

Kerberos on Windows Server 2003 and Sharepoint 2007

Windows 2003 defaults to using UDP protocol for Kerberos. In our traces we were getting Kerberos errors because the packets were too small. Seems TCP packets are larger, so we had to modify the registry to force windows 2003 to send Kerberos messages through TCP. 


Another trace and the issues were resolved, prior to this setting we were experiencing unpredictable prompting issues with Kerberos enabled sites in Sharepoint 2007.