DCO 8.3 Desktop Client Loading Errors

[DCIM_Support]

Hello,

Wanted to throw this question out there to the community and team to see if anyone else is experiencing random, regular errors when attempting to load the Data Center Operation client (we're using version 8.3, but this has been an issue for some time from 8.2.7 on). 

Essentially, what we find is that it can take multiple attempt and sometimes a machine reboot in order to get the application to completely load. 

A few examples of errors we've seen during the loading of the application:

Each of these failures requires a manual task manager ending of the application generally and then several subsequent attempts to load the application. Any thoughts or known bugs with the application that could be causing these issues? Also, this is not authentication related as this behavior is seen with authenticated accounts as well as local accounts. 

I have application log files downloaded as well as the server log files available if needed. Thanks again.

(CID:153093493)

[DCIM_Support]

Hello Neil

Are you able to share log files from your dco desktop client? They might shed some light on the actual cause of the behavior.

Regards

Greg Sterling

(CID:153093520)

[DCIM_Support]

Hey Greg - no problem at all, sir. Is there a way to send them directly to you (so that our logs are not available to the entire community)?

(CID:153093523)

[DCIM_Support]

Hi Neil,

Your attached screen shots showing different issues, 

Authentication error: as notification says there seem to be something with the user authentication (possibly with remote/AD users). For local users we do not have password expiration polices, but modifying the user permissions (while the user is logged in) may interrupt the communications.

Error during startup: seems to be setup related issue, apparently something/some configuration might be generating errors. So we need to look into setup (backup file) + client logs. 

And concerning room/location loading: it says "Waiting for Custom Properties, Power path nodes", this seems to be solution/configuration related as well. Do you have room opening issue here? or it just takes some time to open the room? Depending on size and complexity of the rooms, plus if there are power cabling between the rooms, the room(s) opening may take some time.

To be able to investigate the problems, it would be great if I may ask for the following data:

1- backup file (containing the issue)

2- client application.log file (C:\Users\\.isxo\8.x\Operations\application.log)

3- server logs 

I will send you an invite to my =S= box shortly, so the data safely can be shared with me, thanks.

Kind regards

(CID:153093599)

[DCIM_Support]

Hey Jef - thank you for the quick response, sir! I'm in the process of uploading both the server logs (via client backup) as well as the client application logs. Please let me know if anything else is needed! Thanks.

(CID:153093671)

[DCIM_Support]

Hi Neil,

You are most welcome & many thanks for providing the data, I got the client and server logs (but there were no backup file uploaded).

According to the client logs, there seem to be authentication and/connection timed out issue(s). 

On the server side there are lots of remote authentication failed errors, apparently DCE 7.7.1 is being used as an authentication server? right? Logs contains entries like "Failed to perform user authentication; the provided credentials are invalid, the user's account is locked or the user does not have any roles assigned!"

I have recently experienced that DCO may have issue(s) using DCE as authentication server. I guess issue basically might be related to the latest improvements in DCE itself, however we have included this in DCO/ITA backlogs for detail investigations.

For the time being I would suggest using/testing with DCO local users, or possibly using AD/LDAP server as authentication server in DCO.

Please let me know if you have questions, thanks.

Kind regards

(CID:153550948)

[DCIM_Support]

Hey Jef! Thank you for the response. I just uploaded the backup file for the DCO server as well, so you should have that shortly. 

You are correct in that we are using the DCE server as our authentication method. What we found when attempting to use the DCO server as our authentication server is that it did not appear to handle nested groups well in AD. In that, we would have an access group created in AD that contained users we want in that group, but DCO would not recognize those users. What we ended up having to do was add users individually in addition to our user groups (which defeated the purpose of using groups). 

We did not have this issue when using DCE as the authentication server, so we've gone that route. I'm certainly open to using DCO if any changes have been made. Using local accounts isn't really an option because of our audit folks. They require tracking/authentication so that user activity is accurately logged as opposed to a local account that doesn't require authentication. I don't agree with it, but audit is audit. 😀

That being said, I don't believe this is necessarily an authentication issue, because I can duplicate the errors above using a local account as well. Let me know what you find. Thanks again!

(CID:153550988)

[DCIM_Support]

Hi Neil,

Many thanks for providing the backup, which I have tested without any problem at all. Opening the room "Data Hall" may open other/4 rooms as well (due to power dependencies). However rooms (all of them) can be opened without any problem!

Concerning the authentication via DCE:

a) indirect AD authentication (via DCE) is unsupported. User must be local to DCE, when DCE is being used as authentication server.

b) however as mentioned, we might have authentication issue(s) with the latest versions of the DCE (such as 7.7.1), which I have registered an investigation/ enhancement case for it. 

Concerning authentication via AD/LDAP server:

You are right, nested groups in AD are unsupported in DCO. A best approach which we experienced with other customers was/is to put the remote users in 'normal' group(s) (in AD server).

And concerning the user activity tracking:

DCO supports audit trails, the reports can be generated from desktop client, Analytics Reports > Audit Trail

more info here: https://sxwhelpcenter.ecostruxureit.com/display/UADCO8x/Audit+Trail+Report

Kind regards

(CID:153551219)

[DCIM_Support]

Hey Jef,

So, if you were able to open the application without any errors - what do we think might be causing the errors that we regularly see when attempting to load the application? Like I said, I don't think it's authentication since we can duplicate those errors using a local account or an AD authenticated account. We can duplicate it across different workstations, so also nothing specific to any one user. 

(CID:153551469)

[DCIM_Support]

Hi Neil,

To narrow down and exclude login or client temp files related issues, can you please try the following (when it suits you best):

a) clear the client temp files (usually located in C:\Users\\.isxo\8.3.*, this folder can be removed or renamed to something like 8.3.*_old)

b) if possible reboot the server (it may take approximately 20 min. until the server/application being ready to be used. Users might need to be notified.)

c) start the client and login with a local user.

If you experience issues, can you please provide these updated data:

1- screen captures illustrating the issue(s)

2- client application.log file (C:\Users\\.isxo\8.3.*\Operations\application.log)

3- server log files (web-client, Administration > Download log files)

Thanks,

Kind regards

(CID:153551745)

[DCIM_Support]

Hey Jef,

Appreciate the follow-up. So far, no luck with clearing the temp files - symptoms remain (one of the three mentioned originally). Not a bad thought on rebooting the DCO server and something that we've actually discussed as well. We'll work on completing that and report back with updates. 

Are there any application level fixes in 8.3.2 that we would see benefit in if we upgraded from 8.3? 

(CID:153551915)

[DCIM_Support]

Hi Neil,

Thanks for the update so far.  Lets' see if reboot may help, otherwise we need to study updated data. 

Additional thoughts: I was wondering if you have option to setup an additional test server (just for testing), eg. a) clean install of DCO on the test server, and then b) restore the latest backup file (from production setup) on the test test server.
Then see if issue is reproducible on the test server.

Following page contains the what is new in DCO 8.X:
https://sxwhelpcenter.ecostruxureit.com/display/UADCO8x/What+is+new+in+StruxureWare+Data+Center+Oper...
I don't think there have been application level fixes in 8.3.2 that could be beneficial here (we have not located your main issue yet). However, it is always good idea (recommended) to keep the product up to date. 

Kind regards

(CID:153552536)

[DCIM_Support]

Jef,

Good thought on a test server - we can explore that option as well. If we build a second server and restore our backup, will that impact our production system? Since we don't have licenses to cover two full implementations? Just want to make sure we won't have issues with our production system. 

Another update - I've got approvals to reboot the DCO server Monday evening, so should be able to test that step and see if we notice any improvements. 

(CID:153552934)

[DCIM_Support]

Hi Neil,

A possible test setup will not have any impact on your production system. And you do not need to have additional license(s) for your test setup.

Kind regards

(CID:153553193)

[DCIM_Support]

Yes. Jef appears to have sent you a direct email with a box folder link based on his comments.

Regards

Greg Sterling

(CID:153093606)

[DCIM_Support]

Thank you, Greg!

(CID:153093672)

[DCIM_Support]

This question is closed for comments. You're welcome to start a new topic if you have further comments on this issue.