SharePoint 2010 Foundation–The Website Declined to Show This Webpage

After doing an in-place upgrade of SharePoint 3.0 to SharePoint Foundation 2010, you may receive this error on both your SharePoint site and the Central Administration Tool. 

The cause of this problem for me was the application pools in IIS not being set properly after the upgrade.

In IIS 7.0, expand your web server and go to Application Pools.


As the picture above indicates, both the SharePoint Central Administration v3 and the SharePoint – 80 application pools are set to “No Managed Code.”  They should be set to .NET Framework version 2.0.50727.  Once you make the change your SharePoint sites should come up.  Do note that it may take a moment for the site to display since the .Net runtime has to be spun up.


Setting Up Multiple VLAN’s in the Juniper SRX

By default, the Juniper SRX100 and SRX210 set up fe-0/0/0 as your Internet connection interface and the rest of the interfaces (fe-0/0/1 – fe-0/0/7 on the SRX100) as switching ports on a single vLAN.  It is not uncommon for a network to require more than one vLAN for either political or technical reasons.  For my home, in which I am using a SRX100, I have the reason in that I want my family computers on one vLAN and my Dell T310 server with all my test virtual machines on other vLANs.  This way issues such as my test Small Business Server 2003 machine, with its own DHCP server, will not interfere with other computers which belong to my family (my wife has a mini-laptop, we also have an XBox).  Furthermore, I could go further by setting up a Windows Server 2012 Essentials machine with its own DHCP server as well and it would not interfere with the SBS 2003 virtual machine nor the family machines.  As long as everyone is on their own vLAN, all should be well.

First, type in edit interfaces vlan in the SRX to get to the vLAN interface.  Remember that each physical interface can have many logical interfaces.  Obviously, the vlan interface is not a physical interface (it doesn’t represent a physical interface on the front of the machine) yet the same rule applies nonetheless.  Type the following to create three more vLANs for this interface:

set unit 1 family inet address

set unit 2 family inet address

set unit 3 family inet address

When you type show you should see the following for the current config of your vlan interface (note that unit 0 is the default that was already there):


Now, we need to go to the actual vlan settings of the SRX.  Type top to get out of interfaces and back to the top of the configuration tree, then type edit vlans.  Type the following three set commands to create new vlans we will tie into our interface.

set vlan-trust2 vlan-id 4 l3-interface vlan.2

set vlan-trust3 vlan-id 5 l3-interface vlan.3

set vlan-trust4 vlan-id 6 l3-interface vlan.4

If you type show your configuration for vlans should now look like this:


Now we must set three interfaces to our new vlans – one to each vlan.  Type top to go to the top of the configuration tree and then type edit interfaces to get back in to the interface list.  For my configuration, I’m going to assign fe-0/0/7 to my fourth vlan, fe-0/0/6 to my third vlan, and fe-0/0/5 to my second vlan.  Type the following:

delete fe-0/0/7 unit 0 family ethernet-switching vlan members vlan-trust

set fe-0/0/7 unit 0 ethernet-switching vlan members vlan-trust4

delete fe-0/0/6 unit 0 family ethernet-switching vlan members vlan-trust

set fe-0/0/6 unit 0 ethernet-switching vlan members vlan-trust3

delete fe-0/0/5 unit 0 family ethernet-switching vlan members vlan-trust

set fe-0/0/5 unit 0 ethernet-switching vlan members vlan-trust2

Our last step is to configure DHCP for one of the vlans.  I need DHCP for only one of the vlans as the other two with have a server such as Windows Server 2012 Essentials as the DHCP server.  Type top to make sure you are at the top of the configuration tree.  Then type edit system services dhcp.

Type the following commands to create a new DHCP scope and assign it to the last vlan:

delete router

set pool router

set pool address-range low high

set pool router

set pool propagate-settings fe-0/0/0

Notice we had to delete the original router entry since it was outside the scope of any given pool and, therefore, would have propagated that router setting out to all DHCP scopes.  If you received an error typing that delete command, don’t worry, just type show to see where the router settings entry is.  If is it already in the first first pool, then skip that command and finish setting up the second pool.  After typing show your DHCP should look like this:



Once you are done with that, do a commit confirmed 5 which will commit your settings but give you 3 minutes to type confirmed again before rolling you back.  This way, if a mistake is made, you will get back to your last known good configuration and can try again.  While waiting your 5 minutes, be sure to connect a computer to the other interfaces on the device to see if they get connectivity.  For those interfaces without DHCP, you’ll need to statically assign an IP address.  Once you verify all is well, type commit again to make the changes permanent before you are rolled back.

We now have three vLANs on our SRX. One vLAN with interfaces fe-0/01 through fe-0/0/4 with DHCP, one at fe-0/0/5 without DHCP, one at fe-0/0/6 without DHCP, and one at fe-0/0/7 with DHCP.  The table below summarizes.



IP Address


0 fe-0/0/1 Yes
1 fe-0/0/5 No
2 fe-0/0/6 No
3 fe-0/0/7 Yes


As far as security goes, all the vLANs belong to the trust zone and follow all the policies of that zone.  Later on we will look at putting vLANs into their own zones so we can have more granular control over security.


How Windows Handles Applying Service Packs and Patches

My programming god, Raymond Chen, has written an article on TechNet Magazine about how everything is kept straight and organized when you apply security patches and service packs to Windows 7.  It’s a great read.  He doesn’t cover all the details, but he does cover some interesting bits.  Check out the article here:


SSIS: Dealing With Temporary Tables in Access

When using temporary tables in SQL Server, all you have to do is prefix the table during creation with a “#” (pound sign) and SQL Server knows to delete the table after the session closes.  Example of creating a temporary table in SQL Server:

ID int IDENTITY(1,1),
firstName nvarchar(30),
lastName nvarchar(30)

Again, if you close your session in SQL Server, the above table will be dropped then and there.  This makes temporary tables in SQL Server very useful to SSIS as they clean up after themselves.

Unfortunately, there are many of us who are still having to deal with all those pesky Access 200x databases running around.  And, unfortunately, Access does not support temporary tables like SQL Server does.  When you create a table in Access, it is there to stay unless you specifically drop it by executing a DROP TABLE statement.

In SSIS, this leads to a bit of a problem.  Let’s say your package fails for whatever reason (lost connection to server, power went out, etc.) before it gets to the step where you clean up all those temporary Access tables (i.e. you have an Execute SQL step that has one or more DROP TABLE statements in it).  The next time that same package is scheduled to run it’s just going to fail again when it gets to the step where you create your temporary tables in your Access database because those tables already exist.

In order to combat this problem, and provide yourself a sanity check as I’m certain that like me you always forget to delete your temp tables while testing which means you get the “table already exists” error a lot, we can put a step in that checks for temp tables in Access and drops them.  Before the step that creates your temp tables, insert a Script Task that runs the following code:

OleDbConnection conn = null;
OleDbCommand comm = null;
public void Main()
    conn = new OleDbConnection(Dts.Connections["Connection Manager"].ConnectionString);
    comm = new OleDbCommand("", conn);

    if (checkForTable("Demographics"))
        comm.CommandText = "DROP TABLE Demograhpics";
    if (checkForTable("newBills"))
        comm.CommandText = "DROP TABLE newBills";
    if (checkForTable("newTrans"))
        comm.CommandText = "DROP TABLE newTrans";
    Dts.TaskResult = (int)ScriptResults.Success;
private bool checkForTable(string tableName)
    string[] restrictions = new string[3];
    restrictions[2] = tableName;
    DataTable dt = conn.GetSchema("Tables", restrictions);
    if (dt.Rows.Count == 0)
        return false;
        return true;

Notice that this code checks for three tables:  Demograhpics, newBills, and newTrans.  You can, of course, keep adding “if” statements to check for your temporary tables or you can pass in an object variable that you can loop through that checks for a list of tables.  This way, if your packages fails for some reason during one run, on the next run any temporary tables in Access will be dropped before the task that creates them executes.

There may be other more elegant ways to handle this problem.  If I think of any, I’ll post them.  You, of course, are welcome to mention other ways in the comments section.