quotable quotes

In this day and age of ever increasing government size, control, invasiveness and the (apparent) rise of socialism in the US…

 

"The trouble with Socialism is, sooner or later you run out of other people's money."  - Margaret Thatcher

"When you subsidize poverty and failure, you get more of both." - James Dale Davidson, National Taxpayers Union

"The more corrupt the state, the more it legislates." - Tacitus

"A Liberal is a person who will give away everything he doesn't own." - Unknown

Who is going to pay for all of this?  - TsooRad

Heightened Threat Levels Explained

I got this from a friend of mine; he happens to be an ex-pat Brit.  I fully expect this to jerk someone’s chain, but IDGAF.

Heightened Terrorist Threat Raises Alert Levels

The English are feeling the pinch in relation to recent terrorist threats and have raised their security level from "Miffed" to "Peeved." Soon, though, security levels may be raised yet again to "Irritated" or even "A Bit Cross." The English have not been "A Bit Cross" since the blitz in 1940 when tea supplies all but ran out. Terrorists have been re-categorized from "Tiresome" to a "Bloody Nuisance." The last time the British issued a "Bloody Nuisance" warning level was during the great fire of 1666.

 
The Scots raised their threat level from "Pissed Off" to "Let's get the Bastards" They don't have any other levels. This is the reason they have been used on the frontline in the British army for the last 300 years.

The French government announced yesterday that it has raised its terror alert level from "Run" to "Hide". The only two higher levels in France are "Collaborate" and "Surrender." The rise was precipitated by a recent fire that destroyed France 's white flag factory, effectively paralyzing the country's military capability.

It's not only the French who are on a heightened level of alert.   Italy has increased the alert level from "Shout loudly and excitedly" to "Elaborate Military Posturing." Two more levels remain": Ineffective Combat Operations" and "Change Sides."

The Germans also increased their alert state from "Disdainful Arrogance" to "Dress in Uniform and Sing Marching Songs." They also have two higher levels: "Invade a Neighbour" and "Lose".

Belgians, on the other hand, are all on holiday as usual, and the only threat they are worried about is NATO pulling out of Brussels .

The Spanish are all excited to see their new submarines ready to deploy. These beautifully designed subs have glass bottoms so the new Spanish navy can get a really good look at the old Spanish navy.

Americans meanwhile are carrying out pre-emptive strikes on all of their allies, just in case.

New Zealand  has also raised its security levels - from "baaa" to "BAAAA!". Due to continuing defense cutbacks (the air force being a squadron of spotty teenagers flying paper aeroplanes and the navy some toy boats in the Prime Minister's bath), New Zealand only has one more level of escalation, which is "Shit, I hope Australia will come and rescue us". In the event of invasion, New Zealanders will be asked to gather together in a strategic defensive position called "Bondi".

Australia  , meanwhile, has raised its security level from "No worries" to "She'll be all right, mate". Three more escalation levels remain, "Crikey!', "I think we'll need to cancel the barbie this weekend" and "The barbie is cancelled". So far no situation has ever warranted use of the final escalation level

Just a little over the top, thanks!

Installed a new DC yesterday.  Today I thought I would quickly audit the event logs, just to make sure things were going well before I moved to the next task.

Keep in mind that this figure (as shown below) is for less than 24 hours of no activity - there has been NO activity on this server other than a few logins that may have been handled.  No files, no one else logging in, nuttin’!

12,970 security events in less than 24 hours?  Really?  I am as security conscious as the next average Joe, but at some point the real problems become obscured by the chaff.

Oh my aching brain cell, or, dcpromo u gotta be kidding me!

 

Stupidly, I attempted to join a new 2008 R2 DC to our domain the other day.  I was doing it from a different site, but heck, should be no sweat, right?

Wrong.

DNS was good, name resolution worked, and the machine could join the domain, but why the dcpromo errors?

“failed to examine the active directory forest.  the error was: the operation cannot conitnue because the ldap connect/bind operation failed: error: 58” 

and

“the operation cannot continue because ldap connect/bind operation failed: error: 1326”

I tried various fixes and whatnots…and then stumbled across a little tidbit here that implied that the computer administrator (pre-domain) password might need to match the forest root domain administrator password. 

Having exhausted all my other possibilities, I tried this - and did not expect any success.

But, WTFO!  It worked.  So now the question is, why?

OCS 2007 R2 and Server 2008 R2

Originally posted the 17 November 2009, now updated on 20 November 2009

I get this question over and over:  Can we deploy OCS 2007 R2 on Server 2008 R2?

According to the Office Communications Server 2007 R2 Documentation:

All domain controllers in the forest where you deploy Office Communications Server run Windows Server 2003 with SP1, Windows Server 2003 R2, or Windows Server 2008.

All global catalog servers in the forest where you deploy Office Communications Server run Windows Server 2003 with SP1, Windows Server 2003 R2, or Windows Server 2008.

All domains in which you deploy Office Communications Server are raised to a domain functional level of Windows Server 2003 or Windows Server 2008.

The forest in which you deploy Office Communications Server is raised to a forest functional level of Windows Server 2003 or Windows Server 2008.

As of 16 November 2009, Windows Server 2008 R2 is still not supported.

Having established the “official” facts, I can tell you empirically, OCS R2 on Server 2008 R2 might be OK (emphasis on MIGHT) in a lab, but it is nothing I want to try (again) in anything resembling a production environment.

SharePoint stuck in Read-Only

Our office, like many others, uses SharePoint for a wide variety of uses.  To say that our SharePoint is “business critical” is not an over-statement.  Recently, we ran our SQL Express instance of the SharePoint database into the SQL Express 4GB database size limit.  While moving the database was not a huge issue, what was an issue is that SharePoint, on an internal basis, apparently marked the database as “read-only.”

What is important here is that SQL did not think the database was locked, SharePoint thought it was locked.  After we moved the database to full SQL server, and reconnected the database to the SharePoint farm server, we still could not edit, add, or remove items, documents, or perform other action/task except look at database contents.

Running the following command showed that SharePoint had the database marked as “readonly” (command may have wrapped)

stsadm -o getsitelock -url http://servername

This command returned this output, which explained our issue!

<SiteLock Lock="readonly" />

How to fix this?  Here’s how: (command may have wrapped)

stsadm -o setsitelock -url http://servername -lock  none

Problem solved!

Users unable to join LM session, MEET NOW button not working, LM functions grayed out.

In the middle of a deployment - an OCS R1 to R2 migration - we noticed that the LM functions were not working.  LM worked for the individual workstations when connecting to a remote session initiated by a federated partner.  The meeting policy at the global level was created, edited, and assigned correctly.

We noticed that we had neglected to run the Web Conferencing validation tests.  We had a tick box on our checklist, we had just overlooked it.  Running the validation wizard revealed that the validation connection checks were failing to successfully contact the MCU on either of the Front End servers.  We double-checked everything, and concluded that everything on the OCS side was correct.

“Aha,” says we.  “Must be a certificate issue.”  Except that we were using good public certificates on all the interfaces for the FE servers.  Bummer.  Except, I then read this blog article.

Oddly, this was so on target it floored me.  I used the solution that changed the usage on the Trusted Root Certificate to “ALL” - voila!  problem resolved.  I don’t know who exactly wrote this, and what follows is a cut ‘n paste and edit of the relevant parts of that blog that fixed my issue. Many thanks to the unknown CSS engineer (Dave) who took the time to write this up.

Event Type:    Error
Event Source:    OCS MCU Infrastructure
Event ID:    61013
User:        N/A
Computer:    OCS1
Description:
The process DataMCUSvc(2596) failed to send health notifications to the MCU factory at https://OCS1.contoso.com:444/LiveServer/MCUFactory/.
Failure occurrences: 3491, since 3/24/2009 10:05:18 PM.

If you run the Web Conferencing validation wizard from the OCS Pool, you may find the following error in the output log:

MCU Type: meeting
URL: https://OCS1.contoso.com:444/LiveServer/MCUFactory/
HTTP Connectivity Error : ReceiveFailure
HTTP Connectivity Error : Receive failure typically indicates that the connection was closed by
the remote host. This can happen if the remote server does not trust the certificate presented by the
Local Server.

HTTP Connectivity Error : Ensure that the certificate of the local server and remote server are both
valid, have not expired, and contain valid subject name. In addition, ensure that the certificate chain
of both Server(s) are valid. Ensure that the certificate chain of the local server is installed
on the remote server and vice-versa. The most up-to date certificate chain that was used to issue
the server certificate must be present.

When you see errors like these, it usually indicates that a certificate-related authentication problem exists with the OCS Pool (or with a particular OCS Front End server).  Most of the time, this turns out to be a problem with the certificate from an issuing Certification Authority.  To troubleshoot this issue, you would typically perform the following steps:

1. Log in to the affected OCS 2007 Front End server either locally or remotely using Remote Desktops.
2. If the issuing CA is a Root CA (the top of the list), expand Trusted Root Certification Authorities > Certificates
1. If the issuing CA is an Intermediate CA (not the top of the list), expand Intermediate Certification Authorities > Certificates
2. From the list of CA certificates, right click on the certificate and choose Properties
3. Under the General tab, verify that Enable all purposes for this certificate is selected (or, if Enable only the following purposes is selected, verify that both Server Authentication and Client Authentication are enabled)
4. Click OK to close the properties of the CA certificate.
5. If this was an Intermediate CA certificate, repeat steps 6 through 10 until these settings from all certificates in the trusted certification chain are verified
6. Close the Certificates Management Console (be sure to restart services if you made any changes)

Why this occurred on a brand new R2 installation on server 2008 SP2 is beyond me.  The OCS R1 system (on Server 2003 SP2 R2) did not have this issue, but the brand new setup did.  Go figure.