The cached_MT_Computer columns are not present

Stefan_Zieler

Hello,

we are still relatively new in the use of Cireson products. Maybe someone can help us with the following problem:

We have upgraded the Cireson Portal to version 9.1 in our integration environment and our production environment. With the new standard portal view for the Configuration Items, we have all options in the integration environment in the collection "Cached_MT_Computer" to adjust or select the existing columns in the OData Table Widget.

In the production environment the portal gives me the hint "No data found" when selecting the columns. Does anyone have a clue what could be the cause?

Stefan_Zieler

Upgrading to Portal version 9.2 fixed the problem.

Thanks Shane

Shane_White

Hi @Stefan_Zieler / @Martin_Strbavy

FYI - This was resolved in version 9.2.0 of the Portal

If you need anything else let me know!
Shane.

Shane_White

Hi Stefan,

When you go to Admin Settings > General Settings, can you confirm the versions you are running there? There should be 4 version numbers

Also, are you able to browse to /platform/api after the end or your url
e.g. http://localhost/platform/api

Are you able to see any computer in the 'New Config Items' Page you get in Navigation settings?

Kind Regards,
Shane.

Stefan_Zieler

Hallo Shane,

our Settings on both sites are:

Current Portal Version: 9.1.0.2016

Management Pack Version: 7.7.2016.206

Platform Cache Version: 3009.1.0-beta0002

Platform Version: 3.4.11

Over the old view I see the CIs.


But of course we would like to use the helpful extended representation of the configuration items of the new portal. Unfortunately, no data is displayed here.


It looks to us like the cached_MT_Computer Collections are not present.



Thanx for your support

Shane_White

Hi Stefan,

Okay that's interesting at least you are getting a Platform Version that is good.
What are the names of your Databases? E.g. ServiceManagement and ServiceManager

What do you get when you browse to https://sm-2.manserv.net/Platform/Api?

Have you tried restarting Platform Cache Service? Are you receiving any errors in the following log:
C:\ProgramData\Cireson.Platform.Host\PlatformLog-xxxx.xx.xx.log

Thanks,
Shane.

Stefan_Zieler

The logfile has the following entries:

Main Critical 2019-04-09T08:19:32.4087589+02:00: Authorization Cache Build Complete. 12720 ms

Main Critical 2019-04-09T08:19:32.4087589+02:00: Voided existing AuthTokens. 12725 ms

Main Critical 2019-04-09T08:26:39.5521121+02:00: Starting Active Directory sync process...

Main Critical 2019-04-09T08:26:43.5800479+02:00: Active Directory sync complete. 2 type(s) have successfully synced in 4,18 seconds.

Main Critical 2019-04-09T08:28:16.0447264+02:00: Building Authorization Cache.

Main Critical 2019-04-09T08:28:20.0996759+02:00: Authorization Cache Build Complete. 4628 ms

Main Critical 2019-04-09T08:28:20.0996759+02:00: Voided existing AuthTokens. 4643 ms

Main Critical 2019-04-09T08:38:16.3868416+02:00: Starting Active Directory sync process...

Main Critical 2019-04-09T08:38:20.4244365+02:00: Active Directory sync complete. 2 type(s) have successfully synced in 4,03 seconds.

Main Critical 2019-04-09T08:48:42.5160844+02:00: Starting Active Directory sync process...

Main Critical 2019-04-09T08:48:46.5462382+02:00: Active Directory sync complete. 2 type(s) have successfully synced in 4,03 seconds.

Main Critical 2019-04-09T09:00:26.9920790+02:00: Starting Active Directory sync process...

Main Critical 2019-04-09T09:00:31.0303146+02:00: Active Directory sync complete. 2 type(s) have successfully synced in 4,03 seconds.

Main Critical 2019-04-09T09:12:05.5635827+02:00: Starting Active Directory sync process...

Main Critical 2019-04-09T09:12:09.6160476+02:00: Active Directory sync complete. 2 type(s) have successfully synced in 4,05 seconds.

Main Critical 2019-04-09T09:23:47.0549639+02:00: Starting Active Directory sync process...

Main Critical 2019-04-09T09:23:51.0917933+02:00: Active Directory sync complete. 2 type(s) have successfully synced in 4,04 seconds.

Main Critical 2019-04-09T09:35:27.7699419+02:00: Starting Active Directory sync process...

Main Critical 2019-04-09T09:35:31.8205701+02:00: Active Directory sync complete. 2 type(s) have successfully synced in 4,03 seconds.

Main Critical 2019-04-09T09:45:51.7857993+02:00: Starting Active Directory sync process...

Main Critical 2019-04-09T09:45:55.8246310+02:00: Active Directory sync complete. 2 type(s) have successfully synced in 4,05 seconds.

Main Critical 2019-04-09T09:57:30.6698392+02:00: Starting Active Directory sync process...

Main Critical 2019-04-09T09:57:34.7057460+02:00: Active Directory sync complete. 2 type(s) have successfully synced in 4,04 seconds.

Main Critical 2019-04-09T10:09:09.4861118+02:00: Starting Active Directory sync process...

Main Critical 2019-04-09T10:09:13.5181375+02:00: Active Directory sync complete. 2 type(s) have successfully synced in 4,04 seconds.

Main Critical 2019-04-09T10:20:54.1031319+02:00: Starting Active Directory sync process...

Main Critical 2019-04-09T10:20:58.1462020+02:00: Active Directory sync complete. 2 type(s) have successfully synced in 4,02 seconds.

Main Critical 2019-04-09T10:31:18.0395578+02:00: Starting Active Directory sync process...

Main Critical 2019-04-09T10:31:22.0854573+02:00: Active Directory sync complete. 2 type(s) have successfully synced in 4,03 seconds.

A restart of the cache builder service has no effects on the current result.
and the browser to platform/api shows us the metadata values:

@odata.context	"xxx/Platform/api/$metadata"
value
0
name	"ScheduleDefinition"
kind	"EntitySet"
url	"ScheduleDefinition"
1
name	"ScheduledTaskDefinition"
kind	"EntitySet"
url	"ScheduledTaskDefinition"
2
name	"ScheduledTaskExecutionHistoryItem"
kind	"EntitySet"
url	"ScheduledTaskExecutionHistoryItem"
3
name	"PlatformUser"
kind	"EntitySet"
url	"PlatformUser"
4
name	"AuthenticationRole"
kind	"EntitySet"
url	"AuthenticationRole"
5 ...

Shane_White

Hi Stefan,

Very odd! Can you re run the installer for me and see if this fixes the issue? Do you get any errors in the install log?

Can you confirm the names of the Databases you are using please? E.g. ServiceManagement and ServiceManager

Thanks,
Shane.

Stefan_Zieler

Oh yes, sorry we use theDatabase names ServiceManagement and Service Manager.
We'll reinstall the application. I will update the status afterwards. Thanks 

Stefan_Zieler

Unfortunately, reinstalling the software did not bring any positive changes. Unfortunately, a new creation of the cache did not work either.

In the log file of the installation no errors are listed.

Are there any other ideas for the problem?

Shane_White

Hi Stefan,

I just noticed you earlier said that you restarted the Cache Builder Service, this is the wrong one, can you restart the Platform Cache please?

Are you using http or https?

Thanks,
Shane

Stefan_Zieler

The restart of the the Platform Cache service bring no changes.
We use https.

Shane_White

Hi Stefan,

Can you check your config file has the correct binding information and also has the information for SSL Thumbprint:
C:\inetpub\CiresonPortal\Platform\Platform_Cache.config

Thanks,
Shane.

Stefan_Zieler

We compared the config files with each other. They were the same in the interaction environment and in the production environment. We also added the thumbprint certificate of the Potal server to the file. But unfortunately that didn't change either.

The only thing that occurred to us is that the SQL database is not installed directly on the integration system The Database is on a separate SQL server.

Shane_White

Hi Stefan,

Can you try the following for me:

Run Cireson Setup

Browse to the installation files.

Edit the InstallPortal.ps1 file

Change line 580 from:

$ServiceManagerConnectionString =[String]::Format("Server={0};Database={1};Trusted_Connection=True;", $SQLServer, $SMDBName)

to:

$ServiceManagerConnectionString =[String]::Format("Server={0};Database={1};Trusted_Connection=True;", $SMSQLServer, $SMDBName)

Proceed with the installation as normal.

Once the installation is finished, can you go into your Platform_Config file and ensure the SSL is still setup correctly, if it is missing the port information which should be "Urls":["http://*:443/Platform"] and that the SSLThumbprint is in and correct for the certificate you are using which you can find out by running this PowerShell command on the server:
Get-ChildItem -Path cert:\LocalMachine\My (If that is where you stored the certificates)

Let me know how you get on with this.

Thanks,
Shane.

Stefan_Zieler

Hello, we did the setup again with the changes " SMSSQL". After the successful installation the Platform_Cache.config file did not contain the thumbprint. I did that manually. But unfortunately the behavior does not change.

Shane_White

Hi Stefan,

My next suggestion would be to get the logging level of the platform cache increased giving it some time to generate some logs and private message me the file to have a look at if that's okay?

You can change the log level in the DB using SQL in DB cp.Cireson_Core_SystemSetting

 

INSERT INTO [cp].[Cireson_Core_SystemSetting]

           ([Key]

           ,[Value]

           ,[Guid]

           ,[IsDeleted])

     VALUES

           ('LogLevel'

           ,0

           ,newid()          

   ,0)

 

To go back to normal logging:

 

DELETE FROM cp.Cireson_core_systemsetting where [key] = 'LogLevel'

 

Lower number more logging

500 default

0 most amount of logging

Thanks,

Shane.

Martin_Strbavy

Hi,
did you found a root cause? It looks that we have in our testing environment same issue. I am able to create Odata Table Widget for Business Services, but not for Cached_MT_Computer or some other custom classes (almost all classes).
After increasing LogLevel I cannot see any issue, just this:

Main Informational 2019-04-24T15:20:24.0823083+02:00: Updating process started state Cireson.Core.Worker.Workers.ScheduledWorkProcessWorker

Main Informational 2019-04-24T15:20:24.0823083+02:00: Updating process started state PlatformCache.Data.Workers.SyncAssetsWorker

Main Informational 2019-04-24T15:20:24.0823083+02:00: Checking single instance processes on ServerName

Main Informational 2019-04-24T15:20:24.0823083+02:00: Processed 0 entities for updates in [Cached_MT_Microsoft_Windows_Server_Computer]

Main Informational 2019-04-24T15:20:24.0823083+02:00: Removing [Cached_MT_Microsoft_Windows_Server_Computer] cache Soft Deletes.

Main Informational 2019-04-24T15:20:24.0823083+02:00: Removing [Cached_MT_Microsoft_Windows_Server_Computer] runtime cache Hard Deletes.

Main Informational 2019-04-24T15:20:24.0823083+02:00: Completed updating [Cached_MT_Microsoft_Windows_Server_Computer] cacheableItems in 11009ms

Main Informational 2019-04-24T15:20:34.1037357+02:00: Updating process started state Cireson.Core.Worker.Workers.ScheduledWorkProcessWorker

Main Informational 2019-04-24T15:20:34.1037357+02:00: Updating process started state PlatformCache.Data.Workers.SyncAssetsWorker

Main Informational 2019-04-24T15:20:34.1037357+02:00: Checking single instance processes on ServerName

Main Informational 2019-04-24T15:20:43.2144225+02:00: Updating process started state Cireson.Core.Worker.Workers.ScheduledWorkProcessWorker

Main Informational 2019-04-24T15:20:43.2144225+02:00: Updating process started state PlatformCache.Data.Workers.SyncAssetsWorker

Main Informational 2019-04-24T15:20:43.2144225+02:00: Checking single instance processes on ServerName

Thanks
@Shane_White

Shane_White

Hi @Martin_Strbavy

Hope you are well.

Can you firstly try updating to 9.1.2 and see if this resolves the issue?
After updating can you then go to Admin Settings > Dynamic Data > Click Reset Platform Cache
Wait around 15 minutes for it's cycle to complete and see if the data is then being brought through?

Thanks,
Shane.

Stefan_Zieler

Upgrading to Portal version 9.2 fixed the problem.

Thanks Shane

Shane_White

Hi @Stefan_Zieler / @Martin_Strbavy

FYI - This was resolved in version 9.2.0 of the Portal

If you need anything else let me know!
Shane.