Unable to change private key size when generating custom certificate request on windows

It is becoming the norm to use larger private key sizes with certificates and while trying to generate a new request on a windows 2003 box I found my self unable to change the key size at all, it was greyed out.  After a bit of head scratching I noticed all the cryptographic service providers were ticked.

After changing the tick boxes so that only the “RSA,Microsoft Software Key Storage Provider” is ticked the option becomes available and the key size can be customized.

If (like me) you are generating some CSRs to be used on a forefront threat management gateway or similar don’t forget to make the private key exportable so later on you can export it to the TMG server.

Update: This is still true for modern server versions such as 2012 R2 and 2016.

Lync Client on Linux

I have been wondering lately if it is possible to use Lync from a linux workstation.  As far as I am aware there is no official support or even a chance that the client will run outside of a virtual windows box or similar. (if somone has managed to get the Lync client running under wine or similar i’d love to hear about it) however it seems it is possible to at least have basic chat functionality using pidgin.

For my ubuntu laptop it was simply a case of running:

sudo apt-get install pidgin
sudo apt-get install pidgin-SIPE

Then running pidgin and adding my account details in as a “Office Communicator” account type.

For example:

Protocol: Office Communicator
Username: sipaddress
login: domain\user
Password: password

If all your services are published in DNS you wont need to mess about in the advanced tab but be warned you may get a certificate warning if you used self-signed certs.

 

System Centre Operations Manager Release Candidate Setup

Following on from the unified installer for the Microsoft private cloud, the System centre operations manager installation failed and I decided to attempt the installation myself.

Once you have a suitable server setup with windows 2008 R2 the first step is to install the .NET Framework 4, report viewer and all the required IIS roles:

IIS6 Metabase Compatibility role service.
ASP.NET role service.
Windows Authentication role service.
Static Content role service.
Default Document role service.
Directory Browsing role service.
HTTP Errors role service.
HTTP Logging role service.
Request Monitor role service.
Request Filtering role service.
Static Content Compression role service
IIS Management Console role service.

Even with all the correct roles and pre-requisit software installed the validator will still throw up a couple of problems.

 

You will need to load the IIS Manager and open the ISAPI and CGI Restrictions properties and change the deny to an allow for the ASP.NET v4.0.30319 line.

 

In addition to the above if you installed the .NET 4 framework before the roles you will get an error message: “The ISAPI and CGI Restrictions are disabled or missing” on validating the pre-requisites and will need to run the following command in a cmd window to resolve the problem.

%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe –r

If all is well the command window should look like this:

 

Now setup should allow you to proceed with setup and select weather to add a management server to an existing management group or create the first management server in a new management group.  I like most people playing with the release candidate chose the latter.

Next you are prompted to supply the SQL server details.  In my environment the failed unified installer attempt had left a default SQL instance installed which appeared to be unsuitable as the installer complained I was missing the “Full text indexing” features required.  I had used the SQL 2008 R2 express media which does not include this option (and according to tech-net not on the list of supported SQL versions) so my next steps were to remove the currently installed SQL instance and install a full fat version of SQL 2008 R2 Standard with the full text indexing and reporting services options.  In a production setup you may well choose to create a new database on an existing server but for the purposes of evaluating this I selected to have a local instance of SQL installed as it makes cleaning up this install later a lot easier as I can just destroy the VM.

With the advanced services options installed the operations manager setup wizard will allow you to continue and adjust the configuration of the operational database (although I just left these at the defaults)

 

On clicking next you should see a similar screen for the datawarehouse database.  Again I accepted the defaults and continued on to choose the reporting services instance I installed earlier with SQL 2008 R2 Standard (don’t forget to run the Reporting Services configuration manager and start the SQL Server agent service)

 

Next it is time to choose which IIS site to use for the web console.  In a production environment it would be prudent to configure a new site and setup SSL however I am sticking with the default website for now.

 

Next you are prompted to select an authentication mode for use with the web console.  I selected Mixed Authentication as it will be an entirely private deployment for evaluation/testing purposes only.

After selecting the authentication mode you are prompted to supply some domain account/s for the various roles to use.  I created a single user for this purpose however it would be advisable to separate the data and management accounts so you can fine tune the permissions they are granted.

 

After this step you can choose to opt-in (or not) to the various customer experience improvement programs.  I chose not to as this machine has no Internet access anyway.

Finally you are presented with a page full of the various configuration options set in the previous steps.  If all looks well click install, go grab a tea/coffee and you should be able to return to an installed SCOM 2012.

 

Next I will work on getting a few servers monitored and start evaulating what is avaliable in SCOM 2012.

Initialization Failed: The Operation Couldn’t Be Completed Because a Change Occurred in the Remote Forest

When attempting to start the exchange 2010 management console the error “Initialization Failed: The Operation Couldn’t Be Completed Because a Change Occurred in the Remote Forest” is displayed. This error doesn’t appear to be related to the cause of the problem which can make it especially confusing when trying to resolve.  The problem is usually caused by the server/s the management console is connecting to being a higher update roll-up or service pack than the management console itself. Simply make sure the management tools are patched to the same version as the server and you should then be able to connect successfully.