If you do have products installed and not started then you will also see problems with menu items not displaying icons as they should.
The speed it takes to authenticate can depend on how many products are installed but not started; the more products not started the longer it takes.
Waiting around for what seems an age to log into workspace is not ideal but it doesn’t have to be that way.
Now you could install only the products you are going to use or run the configurator again and reconfigure the web server for only the required products but there is a better solution (thanks to the always helpful and extremely knowledgeable John Booth for giving a pointer to the performance degradation note in the troubleshooting guide)
In workspace if you navigate to Administer > Workspace Server settings a pop window will open.
You will see a button for Enabled Products.
The enabled products displayed will depend on what is installed in the environment.So it is just a matter of deselecting the products you are not starting up.
Once you apply the changes log out and log back into workspace the authentication should have dramatically improved.
Not only has the authenticated speeded up the products that are not being used have been removed from the menu options.
This also means you have the ability to quickly remove access to products within the workspace, so say for example you wanted to stop access to HFM or Planning (ok you can go directly to planning but there are ways to stop direct access) then you would just need to change the enabled products, there are many situations where this would be useful and does not require messing around with provisioning)
If you disable all products you can strip workspace back to the bare shell.
This led me on to think whether this could be scheduled and automated, well the answer is yes but it is not as perfect solution as I would like.
If you log into shared services, expand Application Groups > Foundation and select Deployment Metadata.
Expand Shared Services Registry > Foundation Services > WorkSpace > LWA - workspace@<machinename>_28080
Right click Properties > Export for Edit, this will let you open or save a text file called component.properties
Within the file is the parameter DisabledProducts and a summary of the possible values and how they relate to the name in the workspace server settings are:-
Cds = explore
RAFramework = Reporting and Analysis Framework
Analyzer = Web Analysis
Reports = Financial Reporting
CALC = Calculation Manager
ChangeManagement= Impact Management
HP = Hyperion Planning
HFM = Hyperion Financial Management
BPMA = Enterprise Performance Management Architect (EPMA)
APS = Provider Services
AIF = ERP Integrator
FCC = Financial Close Management
In theory you can update the component.properties file to disable the products that are not going to be started or required and then use the LCM command line functionality or you could use the command line utility epmsys_registry to directly update the property value in the Shared Services registry.
I am not going to go into how to automate LCM as I gave an overview on how to do it a while back which you can view here and the documentation is available here.
I also covered how use the epmsys_registry utility which you can read here and the documentation is available here.
If you are going to use the epmsys_registry method then here is an example command line that will update the hss registry :-
epmsys_registry updateproperty SYSTEM9/FOUNDATION_SERVICES_PRODUCT/WORKSPACE/LOGICAL_WEB_APP/@DisabledProducts "cds,RAFramework,Analyzer,Reports,CALC,ChangeManagement,HP,BPMA,APS,AIF"
Before you go ahead with any of these methods you have to realise there is a major drawback to them, they do update the properties but unfortunately the cache being used by the foundation web application is not updated, so to get the changes to be applied the foundation web app has to be restarted.
I would have thought that if the properties are updated then they should be reflected straight away.
If you are interested in where the property values are stored in the foundation relational repository then have a look at the table HSS_COMPONENT_PROPERTY_VALUES
I don’t recommend you go and update the properties directly in the table though as I don’t want to be the one blamed for corrupting the Shared Services repository.