SCCM over VPN connections
As part of on-going internal infrastructure projects, we have recently implemented new Endpoint security across our network namely Microsoft Forefront 2010. As part of the prerequisites for Forefront we needed to install Microsoft SCCM 2007.
The configuration of SCCM and Forefront generally went through without any issues, if not a lengthy process! Forefront automatically creates the client installation package and policy packages, which are used to apply settings to the client such as Anti-Virus scan schedules, Windows Firewall settings etc. So once SCCM is configured, the process of installing Forefront Endpoint security on top of SCCM is a fairly automated process in terms of configuration.
So far so good, SCCM fully configured and the Forefront client and policy packages ready to be pushed out to clients. I first of all choose to push out the Forefront client and policies to a client machine which was directly on our office network. This machine was added to a collection within SCCM where the Forefront client package was advertised to. The advertisement for the package was set to ‘Always rerun program’ so that there was no need to manually send out the advertisement to the client machine, this will automatically be sent out every time a new client is added to the related collection.
Clients directly inside the network could receive the package ok, but we also wanted packages to be sent out to clients which were connected via VPN and this is where the problem happened! The advertisement would make an attempt to be sent out to the client and the package would not arrive at the client machine, whilst connected via VPN.
So this made me question what was different been the clients directly on the network and those which were connected via VPN. One of the main differences in our case is that VPN clients are issued with a DHCP assigned IP address via our Cisco ASA Firewall. These addresses are in a different IP subnet than our internal office network, where our domain controllers and SCCM server sit. However, VPN clients still point to the same domain, domain controllers and DNS servers as clients in the internal office network.
There is a configuration setting within SCCM which allows you to specify what network or domain criteria clients need to match in order to connect to SCCM, known as ‘Boundaries’. To get to this within the Configuration Manager Console, expand Site Database, Site Management, SCCM Site Name, Site Settings and Boundaries.
There was already a boundary configured for clients which are a part of the domain where the local domain controllers are within a specific active directory site. However, this only covered clients which were within the same IP subnet as the active directory site.
Therefore I created another boundary as an IP address range rather than another active directory site. To do this I needed to be within the ‘Boundaries’ configuration as above, selected ‘New Boundary’ at the right hand side under actions, provided a description, selected our site code (in our case we only have the one SCCM site), selected the type as ‘IP address range’ and then entered the IP range which our Cisco ASA serves out to VPN clients.
Also another important setting in this configuration especially for VPN clients which will be connecting in through varying bandwidth speeds is to set the network connection type as ‘slow or unreliable’.
After this new boundary was created, I was then able to push out the Forefront client and indeed any other software packages to clients connected via VPN.
Our SCCM setup is a single server environment but it is possible to scale this out over several site servers. This would be particularly useful if you have a larger enterprise and therefore even the load out over several SCCM site servers or your domain is based over several physical sites/offices. Placing a SCCM site server at each physical location would mean that SCCM packages could be pushed out via the local site network, rather than using network links from the primary SCCM site location to secondary sites. If you were to go with the option of scaling out SCCM, you may find that you also need to create further boundaries for those clients at different physical sites/offices, dependent on what IP subnet they are within.
IBM Cognos 10 Report Studio Style & Conversion
Following a recent support call I found a nice way of changing the overall look and feel of a Cognos 8 report that has been imported into a Cognos 10 environment.
When I looked at the XML of a new (blank) report in Report Studio 10 I noticed a new variable in the report header tag: useStyleVersion=”10″ (as shown below):-
A fairly obvious logical deduction followed, and I noted that in the imported Cognos 8 report the XML displayed thus:-
Surprise surprise, no useStyleVersion value to be found. With this in mind, a simple solution followed.
First, open the existing Cognos 8 imported report and ‘Copy Report to Clipboard’:-
Second, paste (CTRL+V) into a preferred text editor (in this case Notepad++):-
As shown above, insert useStyleVersion=”10″ into the <report> tag (on the first line).
Then, select all text (CTRL+A) and copy (CTRL+C).
Open a New -> Blank report in Report Studio 10, then ‘Open Report from Clipboard’:-
Et voila. Now you should have retained your Cognos 8 imported report in your Cognos 10 environment, but with the new Cognos 10 ‘look ‘n’ feel’.
IBM Cognos and 64bit Servers, again!
If you receive this error message after installing IBM Cognos BI or Planning on a Windows 2008 64bit server:
HTTP Error 500.0 – Internal Server Error
The page cannot be displayed because an internal server error has occurred.
Then it is more than likely you haven’t enabled 32bit applications to run in IIS. Here are steps to do this:
1. Open Internet Information Services (IIS) Manager from Server Manager on your Windows server.
2. Open the Application Pools node and select ‘DefaultAppPool’
3. Right click and select ‘Advanced settings’
4. Click on the Value of ‘Enable 32-Bit Applications’, select ‘True’
5. Click “OK” to complete the Advanced Settings Dialogue
6. Now go to a command prompt and run an IIS Reset, seen here:
7. You can now access IBM Cognos Connection
IBM Cognos 10.1.1 and Adobe 10
During a recent site visit we found that IBM Cognos 10.1.1 could not print PDF Cognos reports. We received the following error:
Failure RSV-DST-0014 Unable to deliver the output of the report. See the run history details for more information. Ensure that the required services are started. Ensure that the user account is configured to distribute the output in the requested manner.
After a lengthy investigation, we found this was down to Adobe 10’s ‘Protected Mode’. To turn this off follow the below instructions:
On each server running Cognos and Adobe 10, edit a registry key to disable Adobe’s ‘Protected Mode’:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Acrobat
Reader\10.0\FeatureLockDown]
“bProtectedMode”=dword:00000000
When changed reboot all Cognos servers and you will now be able to print PDF reports from Cognos!
Add Database Specific Functions into IBM Cognos Report Studio
Have you ever wanted to add database specific functions into Report Studio for easy access? Here’s how:
1. On your Cognos server navigate to the following directory:
<C10 INSTALLATION DIRECTORY>\c10\configuration\functions
2. Open the FileList.xml which contains definitions and descriptions of vendor specific functions. Notice that the first part of the file name is the database name and the second part is Tree.xml and Strings_<lang>.xml.
For example, for SQL Server there is a SQLServerTree.xml definition file and SQLServerStrings_en.xml description file. The *Tree.xml files contains the definition of the functions and the *String_<lang>.xml contains the description, tips, and help used in C10′s UI.
Notice that for each *Tree.xml there are usually four *String_<lang>.xml files for each of the supported languages (SQLServerStrings_en.xml, SQLServerStrings_fr.xml, etc.). FileList.xml is where you define which language description file you would like to use.
3. To add a new function to Framework Manager open SQLServerTree.xml (If a SQL Server function is required) in an XML editor.
a. Find the </datasourceQueryType> tag.
b. After </datasourceQueryType> tag insert the following -
<function>
<id>sql_avg</id>
<name>avg</name>
<canonical>avg</canonical>
<returnType>numeric</returnType>
<parameter>
<type>numeric</type>
</parameter>
</function>
If the function does not require parameters, the <parameter> tags can be omitted. If the function requires more than one parameter each parameter is defined in a separate <parameter><type>…</type></parameter> tag.
4. After defining the function, you can add the description, if required. Open SQLStrings_en.xml file in an XML editor.
a. find the following line -
<string id=”V_SQLServer”>SQLServer</string>.
b. After this line add the following -
<string id=”sql_avg.syntax”>avg(numeric_exp)</string>
<string id=”sql_avg.tip”>AVG ( [ ALL | DISTINCT ] expression ) </string>
When you selects this function in C10 the help window will display -
avg(numeric_exp)
AVG ( [ ALL | DISTINCT ] expression )
Notice that the function is referenced by an id and therefore the id should match the id in SQLServerTree.xml file. The id in our sample is sql_avg.
5. Now restart the Cognos services.
6. To ensure the function was added to Cognos C10 open the Framework Manager project, select the Namespace and create a new calculation. In the Calculation Definition window, click the Functions tab and expand Vendor Specific Functions, SQL Server. Notice that avg is the first function that appears below the SQL Server database node. Drag avg into the Expression window and insert Quantity from Order_details query subject, so the full syntax looks like this:
avg ( [gosales].[ORDER_DETAILS].[QUANTITY] )
7. Click the blue arrow in the right hand corner to test the function. Et voilà!
Microsoft IIS 7 Issues with HTTPS – Port 443 Access
During a recent Cognos BI and Planning, 8.4.1 to 10.1 upgrade I experienced issues around using port 443 for HTTPS access to the gateway. After successfully completing the installation of 10.1, I was able to access Cognos connection via the HTTPS address fine. However, the following morning I logged back onto the client’s Windows 2008 servers where Cognos 10.1 was installed to start the migration of content from their existing 8.4.1 Cognos environment, but Cognos connection failed load! Instead I was received a ‘page cannot be displayed’ message.
After checking that Cognos services were running ok across all Cognos servers and that there were no errors when testing running a test on the Cognos configuration, I tried to hit the IIS welcome page via HTTPS by entering https://<server_name> but this also loaded up with a page cannot be displayed page. I then tried to access IIS via HTTP but this loaded fine. Therefore I knew at this point that we had an issue with IIS access via HTTPS (port 443) and it looked as soon as the server was rebooted, IIS 7 was falling over on port 443.
IIS 7 Welcome screen that should appear…….
After having a look around the various IIS 7 configuration options, I checked out the site bindings for the default web site and under this option there were 2 types of bindings listed, one for HTTP and another for HTTPS. I noticed that HTTPS was not bound to the IP address of the Cognos Gateway/IIS server. Therefore I added the IP address of this server for HTTPS to be bound to. To check this in your environment, carry out the following:
1. Launch Windows Server Manager (Start menu, right click on ‘Computer’ and select ‘Manage’.
2. Expand ‘Roles’, Web Server (IIS), Internet Information Services.
3. To the right, expand the name of the server, site and then click on ‘Default web site’.
4. Under the actions section on the right hand side, click on ‘bindings’.
5. Select the entry for ‘HTTPS’ and then click on the Edit button.
6. Under the IP address, enter the IP address of the server where the IIS instance is installed (Cognos Gateway server). Do not change any of the other settings such as the SSL Certificate or the Port number. Click on OK
7. You will need to then restart IIS services. To do this, open a command prompt and run the command: iisreset. Before you do this, you may need to run command prompt as an administrator (Start menu, All Programs, Accessories, right click on Command Prompt and select ‘run as an administrator’).
Try to access Cognos Connection again via the HTTPS address and all should be well, providing there are no other configuration issues.
Windows Firewall and Port 9300
During an installation of Cognos 10.1 on a distributed environment, I ran into Windows Firewall issues. The environment consisted of 2 failover Content Manager servers, 2 Dispatcher servers and 1 Gateway server. I successfully started the first Content Manager server; however when it came to starting the services on the standby Content Manager, the services failed to start. On closer inspection of the Cognos logs, it was reported that the primary content manager could not found. To check whether this was just an issue with this particular content manager server or whether it was affecting the whole Cognos environment, I proceeded to start up each Cognos server one by one and logs on each machine reported the same issue.
This really was strange as the active content manager had obviously started up OK and from a Cognos Configuration point of view, each of the servers were configured in the same way as the active content manager but with the corresponding server IP address different for each set of dispatcher URI’s, as you would expect.
After thinking about this further, it became more apparent that this could be some sort of communication issue between Cognos servers. Therefore as a test, I tried to access the active content manager URI from each of the servers and this is the result I ended up with:
And we should expect to see:
If we specifically look at the way which the Content Manager is accessed, any communication to and from the server is via port 9300 and one of main methods that can be used to control access to ports is a firewall. In this case, our client was using Windows Firewall on each of the Cognos servers. In the past, Windows Firewall has been a nightmare for blocking specific ports or programs, for example I know that when I’ve installed a new Windows Server box it always blocks Windows Remote Desktop connections.
Therefore I added port 9300 as an exception as an inbound and outbound rule in Windows Firewall for Windows 2008. I then tried to start the Cognos services across all servers, Cognos was then able to see the active content manager and the services successfully started!
IBM Cognos Planning on 64bit Servers
A known issue has arisen in the latest versions of IBM Cognos Planning when installing on 64bit servers as detailed here: https://www-304.ibm.com/support/docview.wss?uid=swg21472649. On developing a new production environment in our own infrastructure I was hit by the issue myself, but rather than scrap the 64bit VM I had configured and build a 32bit server in its place, I decided to take things into my own hands and formulated a bespoke fix.
The issue I’m referring to particularly affects terminal services servers (e.g. Citrix environments) and is rooted in Windows user profiles. Analyst and Planning Manager (components of the Planning Admin package) will not be accessible for anyone who logs on to the server, apart from the user who installed the Planning environment. Instead, this will happen:
So how did I resolve this issue?
First, a source of inspiration from some Google searching (thanks to Microsoft’s support pages and of course to Google): http://support.microsoft.com/kb/284193
Initially the thought was to (either through local or group policy) create a logon script for new users, in order to amend the registry accordingly so that these applications would work. However, thanks to the above article detailing the method of loading the ‘default user’ profile as a ‘hive’ in the registry (by opening the NTUSER.DAT in the default user profile folder), I realised that a script/policy amendment shouldn’t be necessary. Instead, all I should have to do, in theory, is amend the registry keys in the default user’s NTUSER.DAT file (or hive) so that these will automatically appear in the HKEY_CURRENT_USER registry tree for new users.
First task: export the appropriate keys from the user’s profile under which the environment install had taken place.
The Cognos key can be added manually as there are hardly any sub-keys / values involved, but the IBM key (at least) should be exported to a .reg file. In this example I have added the Cognos key export to the .reg files manually (the first two lines), so that both keys will be imported from one file.
Next, select ‘HKEY_USERS’ and go to File -> Load hive… then browse to (in this case, using Windows Server 2008) C:\Users\Default and open NTUSER.DAT (NB: you will need to have ‘View all hidden files’ and ‘View protected system files’ enabled in Windows Explorer in order to browse to and select this .dat file). You should then be prompted for a Key Name which can be anything, in my case ‘default‘:
(NB: you can see Cognos and IBM keys under Software in this hive as I have already imported the keys – initially these will not be present)
The Key Name is important as you will amend the exported .reg file accordingly, so that when importing this file it will update keys in the correct location (the loaded hive). Below shows the export with the Cognos key lines added (planning.reg) and the amended version to update keys in the default user hive (planning-imp.reg), demonstrating the required change:
This is the only bit of grunt work in the process and it doesn’t take long to change the paths accordingly as there aren’t many sub-keys in the IBM tree.
Once this is completed, simply import the amended .reg file (planning-imp.reg in my case) and you should see the Cognos and IBM keys under HKEY_USERS\default\Software.
Then, with ‘default‘ selected, go to File -> Unload Hive… and answer ‘Yes‘ to the prompt.
Job done! All users will now be able to use Analyst and Planning Manager on the server (unless they have already logged on and had their Windows profile created of course!). So just make sure these steps are taken as a matter of course while installing Cognos Planning 10.1 on a 64bit server (before it goes live) and you shouldn’t have any problems.
Creating Default Styles In IBM Cognos Connection
I have recently been working with a client to implement a corporate style/theme incorporating their company’s logo, which will be displayed across the client’s Cognos Connection.
After we successfully implemented the style, it would usually be the case that the individual users would need to select this new style within the ‘My Preferences’ section in Cognos Connection, before they could see it. However, our client needed their corporate style to be displayed as soon as any user logs into Cognos Connection.
So how do we achieve this?
Each user in Cognos is assigned a user profile the first time that they login to Cognos Connection and this profile is pulled down from a default profile. The user profile contains user personalised settings such as Cognos Connection styling, my folder/public folder display layouts etc. So what we need to do is configure the default profile with any specific display layouts or styling which we want all users to see.
1. You need to be logged into IBM Cognos Connection as a user with Administrator rights. Within Cognos Connection, select ‘IBM Cognos Administration’ from the Launch menu.
2. At the IBM Cognos Administration page, select the ‘Security’ tab. Then select the ‘Cognos’ namespace directory.
3. In the top right hand corner of the next page, click the ‘edit default user profile’ icon which is to the left of the search magnifying glass icon.
4. At the set properties page, you can edit different appearance factors such as the default style and folder layout under each of the four tabs. Once you have made the required changes, click on the OK button at the bottom of the page.
5. The next time that users login to Cognos Connection, they will see the preferences which you have set as default.
For any users who have logged into Cognos Connection previously, you will need to delete their existing Cognos user profile before the default profile can be picked up with the new settings, but please be aware that the user in question will lose any of their previously configured preferences. If this action needs to be performed, do the following:
1. Whilst staying within IBM Cognos Administration, select your companies namespace directory under the ‘Security’ tab.
2. Search for the relevant user who needs to have their profile deleted.
3. To the far right of the user, click on the ‘More….’ option.
4. At the next page, select the option titled ‘Delete this user’s profile’ and click on OK to the message which appears.
5. Ask the user to login to Cognos Connection again and they should find that the default preferences are applied.
The importance of IBM Cognos Connection Content Store backups
I have lost count of the amount of occasions we see clients in a pickle due to a corrupt Content Store database. On many instances the only option is to revert to a working backup of the Content Store. However, IT may not have a database backup or the restored backup still causes issues! Our next question in this scenario is always, “Do you have a Content Store export taken from IBM Cognos Connection?”.
One sure-fire way to ensure you always have a fall-back position is to schedule Content Store backups to run daily via IBM Cognos Connection. An Entire Content Store backup exports all Cognos content to a zip file which is stored on a file system. Therefore no matter what happens to your Content Store database you have a complete backup of all IBM Cognos Connection objects. Find below steps to set up and schedule daily Content Store backups via IBM Cognos Connection:
Steps:
1. Open IBM Cognos Connection, go to Administration>Configuration>Content Administration
2. Next select the New Export icon and give the export a name and select Next
3. Now choose ‘Select the entire Content Store’ and ‘include user information’
4. Confirm the name of the export, Select ‘Next’ and give the export a password. Make a note of the password!
5. Now save and schedule the Content Store export to run on a daily basis
You now have an automated daily back up of all IBM Cognos Connection content!
Giles Horwood
James Smith
Ian Van Ham
Matt Whitehead
