Here are some factors I have experienced or learnt about that can cause problems for a VSAT connection.

Obstruction to the line of sight to the satellite

Obstructive Mango Tree in Makeni, Sierra Leone

Anything that gets in between the VSAT dish and the satellite can weaken or obliterate the signal. Obviously when you initially set up a VSAT dish you find the clearest possible view of the sky, but environments have a tendancy to change. Buildings are erected, or extra floors are built. Trees grow taller or grow extra foliage. I’ve experienced this with mango trees in a couple of locations. Mango trees seem to be common in locations where VSAT is the only connection option!

RF interferance

VSAT operates in several frequency ranges, the most common being:

• Ku band – 12-18 GHz
• Ka band – 26.5 – 40 GHz
• C Band – 4 – 8 GHz

Different things can create interference in each of these bands. Notably, WiMax operates in the 2 – 11 GHz, which overlaps C Band. C Band installations within 50 miles of a WiMax network can potentially be effected. Nice one IEEE! I have also observed local welding work to completely obliterate a Ku band signal. When the work was completed the connection came back.

Rain Fade

Ku band is notorious for being affected by water droplets in the atmosphere – commonly referred to asrain fade – although this can affect any frequency above 11 GHz. This is now usually mitigated against by changes to the transmission power at the satellite and earth stations, but can still sometimes cause problems. Build up of moisture in the feed horn of a VSAT dish can degrade the signal enough to break the connection – if the moisture is removed, or once it evaporates, the connection is reestablished.

Physical disruption

Pointing a dish at a small object 35,786 km away is a fine art. Moving the dish by just 1 degree results in pointing at something more than 600 km away from the satellite! Small knocks to the dish can result in loss of signal, but the dish still looks like it is pointing in the right direction. That is why you spend a lot of money and effort on building secure mounts for your dishes, and put up signs suggesting that getting near the dish is dangerous. Leaving dead birds lying around the dish can be helpful! Talking of birds, they have been known to build nests in VSAT dishes – they generally come with some spikes to discourage this. I’ve seen a 1.5m Maribou stork perching on a VSAT dish.

Cabling can also get damaged (and is expensive and awkward to replace). Again, investment in proper cable runs is worthwhile. Wind blowing a loose cable against a wall, especially over an edge, can result in damage to the cable.

Lightning strikes

Like any metal outdoor object pointed at the sky, lightning strikes are a risk. Generally you won’t be supplied VSAT equipment without some form of lightning protection, but adequate earthing/grounding is usually left up to you. Are lightning rods a good idea? I’m not sure, and haven’t been involved in any installations that include them.

The project employs Community Knowledge Workers who live in communities in Uganda.  These CKWs, many of whom were previously Agricultural Extension Workers, are “trusted neighbours” who can be consulted on a variety of issues that are deemed useful for smallholder farmers in Uganda.  More details about the CKW programme can be found on the Grameen website.

At the presentation I attended, Grameen showcased the technology they are using to support their CKWs.  Each CKW is supplied with an IDEOS android mobile phone – these retail for $80 in Kenya.  The phones have three Grameen authored apps installed.

The first app, CKW Search, is a searchable repository of information that the CKW can consult through a very simple menu.  This information is stored locally on the phone, but is updated automatically when a 3G signal is available.  Each query is logged in the system with GPS coordinates, and this information is sent back to Grameen when a 3G signal is available.

The second app, CKW Survey, is a simple forms based app the CKW can use to capture images, video and text, as well as fill out surveys – typically the CKW will survey farmers who use their services.  Again the data is stored locally on the phone until a 3G signal is available.

The final app, CKW Pulse, is the hub through which Grameen can communicate with the CKWs.  This can be used to message an individual CKW or a group.  Each CKW can monitor their own performance based on the work they have done with the other two apps.  CKWs can also log support calls through CKW Pulse.

In addition to these applications, the CKWs can supplement their income by selling airtime on the phones, and selling phone charging services using the solar chargers they have for chargind the IDEOS phones.

At the backend, Grameen are using Salesforce to collect the data, and have a live dashboard where various aspects of the CKW service can be monitored.  The survey application is based on the Open Data Kit – a free open-source set of tools built to make survey building and data collection quick and easy.

This project is a great showcase of what can be achieved by joining up widespread mobile phone coverage, low cost smart phones, online database systems, and a well trained local workforce.

There are a number of opportunities that Christian Aid could take advantage of here.

• Simple surveys on touch screen phones are a great way to collect baseline data and aggregate it quickly, before and after other initiatives have been carried out.
• The ability to collect images, audio and video and send them quickly through 3G networks means that collecting stories about our work is easier and more immediate than ever.
• The Pulse application could be a useful way to immediately keep in touch with partner organisations, reminding them about deadlines, contacting them with specific messages, or allowing them to see the results of M&E activities and understand their performance.
• The Search application is a simple way of making different kinds of information available offline.  This could be useful for Christian Aid staff, as well as in programme work that employs the “trusted neighbour” model or similar.

For more information on the Grameen CKW project I suggest the following reading:

• Grameen’s CKW project site, for general details of the CKW service
• The CKW technology page, for details of the applications and backend
• The CKW Dashboard
• The OpenDataKit website for info on the tools used to build the CKW apps

Why not create an Admin Console that includes all the Snap Ins you use, and can be Run As an admin user during a regular session?

Here’s how.

Start > Run > mmc

MMC opens in edit mode

File > Add/Remove Snap in

Click Add button

Add the different snap ins you normally use – ADUC, DNS, Exchange, Event Log Viewer are some of mine.

Ok that, then save this MMC somewhere.

Now the tricky bit – running that MMC as a different user.

Create a shortcut to the MSC file:

Right click on the shortcut, and select Properties.

On the shortcut tab, click Advanced button.

Ok out of the shortcut properties.

Now when you double click the Shortcut it will ask you for credentials – you are in!

Note – you may need to install Admin Tools to get the different Snap Ins – see this Microsoft document on how to install different tools.

Some of the snap-ins allow you to change the context – for example Event Viewer – you can change the server it is getting the logs for.  You can also set up multiple instances of some snap-ins – again, very useful if you want quick access to event logs on multiple servers.

It looks like this:

[username@hostname ~]$ 

and when logged in as root:

[root@hostname ~]# 

Here’s how to do it.  While logged in as yourself, edit your .bashrc file and change the export PS1 line so it reads like this:

export PS1='[e[0;32m][u[e[m]@h W]$ '

Now su to root, and edit it’s .bashrc file changing export PS1 to this:

export PS1='[[e[0;31m]u[e[m]@h W]$ '

That easy.  You can do a lot more things with your command prompt, but this is enough for me.  Be careful when using non-printing characters (such as the colour commands above).  These should be surrounded by escape block ([ and ]).

This shows “Administrative” rights, but can equally be applied to other permissions at any level below a site collection. Dotted boundaries show where the inheritance are optional (and shouldn’t really be called inheritance either).

To explain this a little further let’s start at the top:

Web application level

The Policy for Web Application setting allows you to give Active Directory users and groups rights over all Site Collections in that Web Application.  If you give a user or group Full Access permissions at this level, they will have access to all the settings pages for all sites in the web application.  These users and groups names do not show up in any Sharepoint groups or permissions pages.

Site Collection level

When creating a site collection you can set Primary and Secondary Site Collection Administrators.  These can only be set as Active Directory user accounts.  These users get access to all settings pages for the sites within the site collection (including the root site /).  Emails sent by Sharepoint relating to sites in the site collection appear to come from the Primary Site Collection Administrator.

To update all your Site Collection Administrators in one go, take a look at my Sharepoint 2007 PowerShell scripts.

Sites

This is the level that the groups you can administer within Sharepoint become available, and what most people think of when they think of permissions in Sharepoint.

An important point to note is that there is always a root site within a site collection – this is accessed at the root of the site collection directory (/).  All other sites in the site collection are subsites (or subsites of subsites) of this site.  The groups and permissions you set up for this root site can be used by the other sites in the collection.

This all gets a bit complicated, so lets use an example to illustrate.

We’ve got a site collection with a root site at http://dunxd/sites/teams/.  Within this site there are two subsites – a and b.  Site a has a subsite 1.

When we create the site collection (and root site), Sharepoint will set up the following groups:

• Teams owners – this is for users who can administer the root site.  They won’t see the Site Collection admin links unless they are included in one of the higher level permissions described above.
• Teams members – this is for users who need to be able to work on content in the site
• Teams visitors – this is for users who only require read access to the site

When we create subsite a, we have the choice of using the same permissions as the parent site. If we choose that, subsite a will not have any additional groups created.  Owners of the Teams site will also be owners of the a site, and so on.

Note that here we are simply using the groups – once these have been set up, we can change the permissions those groups have for site a without changing the permissions they have for site Teams.  Also note that if we add a user to the Teams owners group, that user will also have the Owner permissions on site a.

We also have the choice of using unique permissions.  If we choose that, additional groups may be created, or we may use existing groups for each of the Owner, Member and Visitor roles.  The default options in this situation are to share the parent Visitors group, and create new Member and Owner groups specifically for the site.

When we come to create a subsite of site a called site 1, we get the same options for using parent permissions or unique permissions.  If we use the parent permissions, we get whatever we set for the parent site – if we used the permissions for Teams in site a then site 1 will also have Teams owners as owner and so on.  If we select to use unique permissions for site 1,  we can create 1 Owners etc, or we can use a owners, or even Teams owners.  A site can access all the groups in the parent sites above it.

This is quite a major departure from the way that normal file system permissions work.  It’s also quite difficult to explain.  I hope this post helps you if you need to understand this, or explain to someone else.

With any luck you didn’t need to read 800 words – the diagram explained it for you.

First up however, you need a list of the profile property names so you know what to select.  The following PowerShell script will display a table showing the internal name used by Sharepoint, and the property name displayed in the Sharepoint UI (Download Get-UserProfileConfigManager):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# Outputs a list of User profile names - both the internal name, and the name displayed in Sharepoint
 
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server.UserProfiles")
# Function:          Get-UserProfileConfigManager
# Description:       return a UserProfileConfigManager object which is used for management of MOSS User Profiles
# Parameters:        SSPName          Shared Service Provider Name    
 
Function global:Get-UserProfileConfigManager($SSPName)
{
$ServerContext = [Microsoft.Office.Server.ServerContext]::GetContext($SSPName);
new-object Microsoft.Office.Server.UserProfiles.UserProfileConfigmanager($servercontext)
}
 
$cm=Get-UserProfileConfigManager("SharedServices");
$cm.getProperties() | ft name,displayname

The output from this can be used to determine the names of the properties you want to use in the next script.  To use this script, update the  $arProperties list with the property names you need.  By default this saves the results to a file UserProfiles.csv in the directory from which you run the script.  You can then import this into Excel or whatever (Download Get-UserProfiles-To-CSV).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

# Outputs a delimited file with specified user profile properties for each user in Sharepoint
 
# Create array of desired properties
$arProperties = 'UserName','FirstName','LastName','Title','WorkEmail','WorkPhone','Manager','AlternateContact','RoleDescription','PictureURL';
# Specify output file
$outfile = 'UserProfiles.csv';
#Specify delimiter character (i.e. not one that might appear in your user profile data)
$delim = '^';
# Specify Shared Service Provider that contains the user profiles.
$SSP = "SharedServices";
 
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server.UserProfiles")
 
# Function:          Get-UserProfiles
# Description:       return a UserProfileManager object containing all user profiles
# Parameters:        SSPName          SSPName
 
Function global:Get-UserProfiles($SSPName)
{
	$ServerContext = [Microsoft.Office.Server.ServerContext]::GetContext($SSPName);
	$UPManager = new-object Microsoft.Office.Server.UserProfiles.UserProfileManager($ServerContext);
	return $UPManager.GetEnumerator();
}
$profiles = Get-UserProfiles($SSP);
 
#Initialise Output file with headings
$header = [string]::join($delim,$arProperties);
Write-Output $header | Out-File $outfile
 
#Output the specified properties for each
$profiles | ForEach-Object {
	foreach($p in $arProperties){
		# Get the property name and add it to a new array, which will be used to construct the result string
		$arProfileProps += $_.Item($p);
	}
	$results = [string]::join($delim,$arProfileProps);
	# Get rid of any newlines that may be in there.
	$CleanResults = $results.Replace("`n",'');
	Write-Output $CleanResults
	Remove-Variable -Name arProfileProps
} | Out-File -Append $outfile

The next stage of development would be to pipe the output of the first script into the second, instead of setting up a list of desired properties – it is probably more useful to just grab everything.

I’m sure this could be written much more gracefully, but I can’t work out how to iterate through the UserProfile.Item array/object.  Any suggestions gratefully received!

Download Sharepoint User Profile PowerShell scripts here (zip file).

As such, any problems with SharePoint related to performance will not have anything to do with NLB, as all it does is decide which host a client will send requests to.  Rather such problems would be down to one of the web front ends responding slowing – usually down to the application pool needing to free up memory, which should happen automatically after a while.  Where NLB confuses things is that you can’t easily tell which WFE a client machine is talking to.

If NLB is not working, the only likely symptom would be that no requests to the NLB IP address would work.  If you can ping your NLB IP address, then NLB is working.

You can check Network Load Balancing by going to Start > Administrative Tools and running Network Load Balancing (most likely you have this on your PC).  You need to connect to one of the nodes involved.  You can then see the status of the nodes. This should always be checked first in case one of the nodes has stopped responding on the NLB address).  You should also use this interface to drainstop a node before taking it offline for any reason – that way you get as graceful as possible a handover of affinities.

Update: It seems that in certain circumstances, NLB can come apart under load.  We recently switched from two high end Cisco core switches to two stacks of three Dell PowerConnect 6048 switches.  Since then NLB works, but as soon as we get moderate load coming to the NLB address, Sharepoint grinds to a halt.  Dell are chasing this, and we are promised a fix soon – until then no NLB – we can’t roll back to our Cisco switches.  Christian Aid isn’t such a huge organisation (~800 staff worldwide), but heavy users of Sharepoint for file storage – seems enough to break NLB.  I think it is something to do with the multicast hack Microsoft use to make NLB work – but I’d better wait to hear back from Dell and get it working before I can say for sure.

By default VMware hosts ping their default gateway to determine whether or not they are isolated from the cluster.  However, if you are running a pair of Dell PowerConnect switches using VRRP for redundancy, the VRRP IP address is not pingable (I’m not sure why Dell set this up – this isn’t the case with Cisco’s HSRP equivalent).  So the solution to the problem was to nominate another device in the same subnet as the Service Console as an isolation address and force VMware to use this.  We nominated our monitoring server, as we attempt to keep this running 24/7.  You need to go to the Advanced Settings for VMware HA, and set das.isolationaddress to the IP of the device you will be pinging, and then create a new variable das.usedefaultisolationaddress and set that to false.  After doing this, disable HA, then once that has completed, reenable.

HA should work fine after that.

There are a lot of places in Sharepoint where you can assign permissions.  This is intended as a summary of where administrative level permissions can be assigned.

Site Collection Users and Groups

This is set per site collection.  Super user and regular user permissions to children of the site collection are set here.  These permissions can be inherited by an site collection child, including sub-sites.  Giving a user Full Control here does not give Site Collection Admin level control as might be assumed, but does give enough functionality for many things.

Site Collection Administrators

This can be set through the Site Collection Site Settings if you are already a Site Collection Administrator, or owner or secondary contact – i.e. existing site collection administators can add other people.  You cannot add AD groups to this list, so Site Collection Administrators must be listed individually.  Owners and Secondary Contacts are automatically Site Collection Administrators whether they are listed as such or not.

Site Collection Administrators is the highest level permission that can be given to a site collection.  A Farm Administrator does not automatically inherit this permission (but see below) but can add themselves to the a specific Site Collection’s Administrators list through Central Administration > Application management > Site Collection Administrators.

Policy for Web Application

Here you can give Site Collection Administrator type permissions to all Site Collections in a Web Application (e.g. http://division).  This can be useful for setting up admin accounts.

SSP Users and Groups

Access to some, but not all, SSP functions can be assigned via the SSP Users and groups page.

SSP Site Collection Administrators

If you are not on this list, you cannot access the Search Usage Report

SSP Web Application Policy

As for any other site collection, you can add an AD group as Site Collection Administrator by adding the group to this list.

Personalisation Services Permissions

Set up specific users who need to manage profiles and MySites in here.  You also need to set up these users under the Policy for Web Application for your MySites Web Application or they won’t be able to admin mysites fully.

Business Data Catalog Permissions

If you use these, then you need permissions in here for administration.

Central Admin Site Users and Groups

Some functionality can be given here, but mainly you will be able to see the menu, but not do anything.

Central Admin Site Site Collection Administrators

Here you get the real power over Sharepoint.

Policy for Central Admin Web Application

Again – useful for assigning admin permissions by AD group.

Phew – that is a lot of places, and possibly not an exhaustive list.  Does anyone actually need this level of granularity?  Even if that is the case, could this have been made easier through better thought out admin pages, and better labelling?  I am sure that Donald Norman and Edward Tufte would have a lot to say about Sharepoint admin!