IT Monkey:   Join the Cireson Community today for your chance to win $50!

(v8.x) All ODATA (platform) calls fail with 401. Is this a setup/config issue?

Tom_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
An example is the "Asset Analysis" dashboard.  Users (including highly privileged) are prompted for credentials, but providing them does not work.  Direct calls to the platform api (postman, Excel, PowerShell) also fail with a 401/Not Authorized.

The platform service runs under a credential with more than sufficient privileges, it appears (same as CacheBuilder).  I see nothing wrong in IIS, also.

Is there something else I should look at before submitting an Incident?

Best Answers

  • Tom_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
    Accepted Answer
    I can update this from my end, as I have a few observations to share, now.  As of 8.2.2 / 8.3.1, this is working in my environment, but I am not entirely sure if it was a software change.  Perhaps that is part of it.

    It seems to matter very much whether your environment is configured to allow connections to /platform/api, BEFORE the installer runs.  In other words, installing the portal then setting up your server to conform to all this endpoint's demands later does not seem to work.

    I had a dev environment and a staging environment, both on portal v8.2.2, both with identical IIS configs.  Dev worked, staging did not.  That seems to be because we added an SPN and configured DTC in dev first, then rolled those changes to staging later, which happened to be after the portal was upgraded in both environments.  I just now updated both environments to portal 8.3.1 and it fixed the issue in staging, while dev continues to work properly.

    The DTC config I am referring to was mentioned by @John_Long in another thread (https://community.cireson.com/discussion/comment/10723#Comment_10723 ).


Answers

  • Martin_BlomgrenMartin_Blomgren Customer Ninja IT Monkey ✭✭✭✭
    Upgraded my dev environment last night so I haven't really gotten any time to play with the OData endpoint yet but I can say this much that there were problems even getting it up and running and I can't say I got it working using a OData table or chart (https->http on same resource...)

    Tried to use the new shiny https binding in the Cireson setup but that made the installation fail so I tested one more time but this time with only http (port 80) and everything seemed to go smooth. Immediately Changed the binding to https (hostname) and removed the http as a have a redirect on port 80 in the default site to https://hostname:443

    After this whenever and however I tried to access the platform api I only got a 404 Not found. Found the Platform folder in CiresonPortal with a 'Platform_Cache.config' where all settings is and in this case it's pointing to port 80 as that's what I had to use to be able to upgrade to v8.x

    Changed the bindings and restarted the services/pool/web and I was finally able to access the OData endpoint on port 80. Did test the table and chart again but was on https so I could be the reason it didn't work. Aside exploring the endpoint here's where my testing ended.

    Don't know why but in my case the Platform service was using the App pool account which doesn't have any privileges in SCSM db and I saw in the log.txt in the Platform folder repetitive errors with the sql client trying to access that db so being not even a test environment I went the easy route and made that account dbowner.

    Really need to take some time and get to the bottom with this!

    Regarding the OData endpoint (which I absolutely love that Cireson taken this route) the only sad part is that it's not for WI, which would have opened up a whole new world of smooth custom possibilities...
  • Tom_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
    I am also redirecting all http traffic to https, and there might be something to this.

    Your walkthrough did prompt me to look in the platform folder again--somehow I did not notice the log.txt file.  In it, I find many repetitions of this error, which may indicate a different problem:
    [TIMESTAMP]: Type Exception, Source: Newtonsoft.Json, Message: Unexpected character encountered while parsing value: <. Path '', line 0, position 0., InnerException: , StackTrace:    at Newtonsoft.Json.JsonTextReader.ParseValue()
       at Newtonsoft.Json.JsonTextReader.Read()
       at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.ReadForType(JsonReader reader, JsonContract contract, Boolean hasConverter)
       at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)
       at Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)
       at Newtonsoft.Json.JsonConvert.DeserializeObject(String value, Type type, JsonSerializerSettings settings)
       at Newtonsoft.Json.JsonConvert.DeserializeObject[T](String value, JsonSerializerSettings settings)
       at PlatformCache.Data.PortalAuthentication.PortalAuthenticationHandler.<GetUser>d__5.MoveNext() in C:\Portal\Integration-Lance-PlatformCache\Cireson.WebConsole\PlatformCache\PlatformCache.Data\PortalAuthentication\PortalAuthenticationHandler.cs:line 127, StackTrace: TargetSite
    I find myself wondering if there needs to be a CDATA wrapper in an XML file somewhere, or escaping of strings/characters in other types of files, for this to work in the wild.  I am thinking of my recent SMA Connector post, too.
  • Martin_BlomgrenMartin_Blomgren Customer Ninja IT Monkey ✭✭✭✭
    OData by it self should be able to handle any characters but as you say it could be something either with your complex  auto generated passwords and how Cireson has implemented this OData.

    Don't know if the https binding is totally broken or if it works if you remove the current binding before running the installer. Do remember some complaints about my SSL cert but didn't check the install log before re-running the installer. The idea here is to manage to get it installed with https and thus get the correct settings in the .config file. Did try to update the config file with correct protocol, port and cert thumbprint but was never able to access the odata endpoint on https.
  • Tom_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
    I can confirm that at least in my install, the https binding does not seem to have any bearing on this.  Everything else works fine with it, but anything under /platform/ fails (401 / Unauthorized) with or without it.  No combination of Win Auth, Impersonation, etc. in IIS seems to satisfy it.

    Again, the libraries may be choking on unexpected characters in my case, but it refuses to return anything other than 401 over here.  I hope other folks are having better luck with it.
  • Martin_BlomgrenMartin_Blomgren Customer Ninja IT Monkey ✭✭✭✭
    edited August 2017
    Update
    When installing the update to v8.1.0 in my dev environment trying to enable https I got the same error related to my certificate.
    8/4/2017 2:37:52 PM Installing Platform Cache Service
    8/4/2017 2:37:52 PM Failed to install windows service: parsing "*.domain.com Alpha" - Quantifier {x,y} following nothing.
    8/4/2017 2:37:52 PM Failed to install windows service: parsing "*.domain.com Alpha" - Quantifier {x,y} following nothing.
    8/4/2017 2:38:35 PM Platform not ready yet, please wait...
    8/4/2017 2:38:45 PM Platform not ready yet, please wait...
    8/4/2017 2:38:55 PM Platform not ready yet, please wait...
    8/4/2017 2:39:05 PM Platform not ready yet, please wait...
    8/4/2017 2:39:15 PM Platform not ready yet, please wait...
    8/4/2017 2:39:25 PM Platform not ready yet, please wait...
    8/4/2017 2:39:35 PM Platform not ready yet, please wait...
    8/4/2017 2:39:45 PM Platform not ready yet, please wait...
    8/4/2017 2:39:55 PM Platform not ready yet, please wait...
    8/4/2017 2:40:05 PM Platform not ready yet, please wait...
    8/4/2017 2:40:15 PM Platform not ready yet, please wait...
    8/4/2017 2:40:25 PM Platform not ready yet, please wait...
    8/4/2017 2:40:35 PM Platform not ready yet, please wait...
    8/4/2017 2:40:45 PM Platform not ready yet, please wait...
    8/4/2017 2:40:55 PM Platform not ready yet, please wait...
    8/4/2017 2:41:05 PM Platform not ready yet, please wait...
    8/4/2017 2:41:15 PM Platform not ready yet, please wait...
    8/4/2017 2:41:25 PM Platform not ready yet, please wait...
    8/4/2017 2:41:35 PM Platform not ready yet, please wait...
    8/4/2017 2:41:45 PM Platform not ready yet, please wait...
    8/4/2017 2:41:55 PM Platform not ready yet, please wait...
    8/4/2017 2:42:05 PM Platform not ready yet, please wait...
    8/4/2017 2:42:15 PM Platform not ready yet, please wait...
    8/4/2017 2:42:25 PM Platform not ready yet, please wait...
    8/4/2017 2:42:35 PM Platform not ready yet, please wait...
    8/4/2017 2:42:45 PM Platform not ready yet, please wait...
    8/4/2017 2:42:55 PM Platform not ready yet, please wait...
    8/4/2017 2:43:05 PM Platform not ready yet, please wait...
    8/4/2017 2:43:15 PM Platform not ready yet, please wait...
    8/4/2017 2:43:25 PM Platform not ready yet, please wait...
    8/4/2017 2:43:35 PM Unable to initialize Platform

    Somehow the installer isn't able to parse the friendly name of my certificate (Alpha is the CA thats why i'm using it in friendly).

    Changed from *.domain.com Alpha => wildcard.domain.com and re-run installer without any problem or errors. The OData endpoint works as supposed but I can still see that the App Pool service account is used for the Platform cache and I already made the necessary security arrangements for that account.
  • Tom_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
    Similar to your description, I do not have any wildcards in my cert, and the 8.1 installer ran just fine in my test environment.  Also, my issues connecting to OData seem to be gone.  More testing to be performed, though.

    Do you have any luck if you do not include a certificate in the installer, then add the 443 binding after the portal is installed?

    I have a few post-install steps that I have a powershell script for, and one of them used to be setting up the 443 binding that the installer used to wipe out.  What I am not sure about is whether leaving this out of the install process may have some detrimental effect.

    That part of the PS script, in case it is helpful:

    $PortalSiteName = "CiresonPortal"
    $CertFriendlyName = "FRIENDLY NAME OF YOUR CERT"

    # Get the certificate, to be used when re-binding SSL after portal installation
    $Cert = Get-ChildItem Cert:\LocalMachine\My | ? { $_.FriendlyName -like $CertFriendlyName }

    # Navigate to the IIS Namespace after loading the module
    if ($(Test-Path IIS:\)) {
    Set-Location IIS:\
    }
    else {
    Throw "ERROR: IIS Path not available. Check WebAdministration module and try again."
    }

    # Restore the bindings AFTER the portal update - test to see if the https binding exists first, because http always will
    if (-Not (Get-WebBinding -Name $PortalSiteName | ? { $_.protocol -eq "https" })) {
    Write-Output "SSL Binding removed by Cireson Installer. Restoring Bindings with certificate..."

    try {
    Set-Location IIS:\SslBindings
    New-WebBinding -Name $PortalSiteName -IPAddress * -Port 443 -Protocol "https"

    Write-Output "SSL Binding restored."
    }
    catch {
    Write-Output "ERROR: SSL Binding was not restored! Please add the binding and certificate back to the site manually. Error Details: $Error"
    }
    try {
    #separate this from the try/catch above, because sometimes an error is generated if the binding needed to be restored but the cert is already assigned.
    $Cert | New-Item 0.0.0.0!443
    }
    catch {
    Write-Output "**Potential** Error: The cert could not be added to the SSL binding. This could be because it already exists. Review the following error message for further instruction: $Error"
    }
    }
    else {
    Write-Output "SSL Binding was not removed by installer, so no action was required."
    }

    This always ends up at the final "else" now, thanks to the addition of the certificate in the newer installers.  I still have to change the session timeouts on the app pool, re-establish http/https redirects, add back virtual directories and virtual apps, of course.
  • Tom_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
    To anyone following along, I had to submit an IR ticket to Cireson for this.  Nothing I do and no set of credentials or permissions granted to them will make the 401 errors go away, and all OData endpoints remain utterly inaccessible in all environments.  I am hoping there is a simple explanation that I missed!
  • Ian_GlennIan_Glenn Member Adept IT Monkey ✭✭
    Tom, did you ever get a resolution on this?  I recently installed v8.1.1 and I am having issues with my Platform Cache and ODATA views. I also opened a ticket with Cireson but so far they haven't found a resolution.
  • Tom_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
    No.  The development team started looking at it about a month ago and asked me a few basic questions about my environment, but I have not heard anything about it since.  It is a shame, because this has so much potential usefulness for us.
  • seth_coussensseth_coussens Product Owner Ninja IT Monkey ✭✭✭✭
    Surfacing this thread, and I hope everyone having an issues around this will open an incident with support so we can track the affected environments here.

    Are we using the SSL thumbprint when we are inputing the SSL certificate or are we using the name? Can someone post their Platform.Cache.config file as well as their log file in the programdata/platform.core folder?
  • Ian_GlennIan_Glenn Member Adept IT Monkey ✭✭
    Hi Seth,  I submitted IR68845 for this issue and have attached the files you requested.  If you need anything else please let me know.
  • Tom_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
    I had to obfuscate parts of this, but here is the Platform.Cache.config:  (I used regular parentheses to indicate where I pulled out part of the actual file)

    {"HostWebServer":true,"Urls":["http://*:80/Platform","https://*:443/Platform"],"WorkerCount":1,"ConnectionString":"Data Source=(NAMEOFDATABASESERVER);Initial Catalog=ServiceManagement;Integrated Security=True;Connect Timeout=15;Encrypt=False;TrustServerCertificate=False;Trusted_Connection=True","ShowHelp":false,"Basic":false,"SslCertificateThumbprint":"(CERTHUMBPRINT)","ProductKey":"","MasterExtensionName":"PlatformCache","IsRunningAsService":false}

    There are a few parts of this that look suspicious right away.  Why doesn't ProductKey have a value?  Why isn't it running as a service (I have a "Platform" service running now, as of v8, after all)?  Why is Encrypt set to "false"?

    My log file is almost 20 MB, and I cannot post it publicly until/unless I can take the time to be 100% certain that there is nothing in it that is unique to our environment, but I can send it over to you privately.  For right now, here are some items that jump out to me among the many errors:

    Exception 2017-09-27T02:54:10.9323807-04:00: System.Data.SqlClient.SqlException (0x80131904): Execution Timeout Expired.  The timeout period elapsed prior to completion of the operation or the server is not responding. ---> System.ComponentModel.Win32Exception (0x80004005): The wait operation timed out

    I have no idea why this would occur, but this message is extremely prolific in the log.  But I am also not sure which server is supposedly not responding?  The web server (which this is running on) or the database server?  There should not be any issues on the DB server, unless this is using a port that is blocked or a service such as DCOM, WMI, WinRM, etc. that is being actively blocked.  The account that this runs on has all the authorization it needs to that database server.  We do have a lot of blocked queries and deadlocks right now due to performance issues, but this fails 100% of the time, and nothing else comes close to that.  In sharing about 25GB of logs with Microsoft, they identified which tables are causing the blocked and deadlocked queries, and it is primarily the ECL and RelatedECL tables.  None of the Cireson tables showed up.  (Unrelated side note: the Cireson KB Full Text search stored procedure did show up as the #1 operation with the most unindexed seeks/scans, though.  Yes, more than the ECL tables!)

    Error Number:-2,State:0,Class:11
    Exception 2017-09-28T00:05:54.5668760-04:00: System.Data.Entity.Core.EntityException: An exception has been raised that is likely due to a transient failure. If you are connecting to a SQL Azure database consider using SqlAzureExecutionStrategy. ---> System.Data.Entity.Core.UpdateException: An error occurred while updating the entries. See the inner exception for details. ---> System.Data.SqlClient.SqlException: Transaction (Process ID 178) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
       at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
       at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
    I do not see very many of these, and could easily see where this is just due to those performance issues I described above.  However, I am not quite sure how it could even get to the point where a deadlock is possible if it cannot even connect in the first place. 

    Circling back to the first error, here is the rest of the message, which has some file references (in a container??) and line numbers that may be helpful:

    Exception 2017-09-28T02:13:13.7910377-04:00: System.Data.SqlClient.SqlException (0x80131904): Execution Timeout Expired.  The timeout period elapsed prior to completion of the operation or the server is not responding. ---> System.ComponentModel.Win32Exception (0x80004005): The wait operation timed out
       at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
       at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
       at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
       at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
       at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()
       at System.Data.SqlClient.SqlDataReader.get_MetaData()
       at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString, Boolean isInternal, Boolean forDescribeParameterEncryption)
       at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, Boolean inRetry, SqlDataReader ds, Boolean describeParameterEncryptionRequest)
       at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean& usedCache, Boolean asyncWrite, Boolean inRetry)
       at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
       at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
       at System.Data.SqlClient.SqlCommand.ExecuteReader()
       at PlatformCache.Data.Services.Implementations.Database.<ReadFromParameterizedSql>d__5`1.MoveNext() in C:\Portal\Integration-Lance-PlatformCache\Cireson.WebConsole\PlatformCache\PlatformCache.Data\Services\Implementations\Database.cs:line 61
       at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
       at PlatformCache.Data.Models.CacheUtil`1.<ProcessUpdates>d__10.MoveNext() in C:\Portal\Integration-Lance-PlatformCache\Cireson.WebConsole\PlatformCache\PlatformCache.Data\Models\CacheUtil.cs:line 151
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at PlatformCache.Data.Services.Implementations.CacheableItemSyncService.<ProcessUpdates>d__9.MoveNext() in C:\Portal\Integration-Lance-PlatformCache\Cireson.WebConsole\PlatformCache\PlatformCache.Data\Services\Implementations\CacheableItemSyncService.cs:line 105
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at PlatformCache.Data.Services.Implementations.CacheableItemSyncService.<UpdateCacheableItems>d__6.MoveNext() in C:\Portal\Integration-Lance-PlatformCache\Cireson.WebConsole\PlatformCache\PlatformCache.Data\Services\Implementations\CacheableItemSyncService.cs:line 61
    ClientConnectionId:d2e0ca11-17ca-4343-ac1b-73027d4029e5
    Error Number:-2,State:0,Class:11

  • seth_coussensseth_coussens Product Owner Ninja IT Monkey ✭✭✭✭
    @Tom_Hendricks
    Definitely looks like a connectivity problem, though could be related to configuration rather than real network connectivity issues. Have you opened a ticket for your issue as well? If so what is the IR#? Also, what version of the portal are you currently using?
  • Tom_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
    Yes, IR67670, and I am on portal v8.1.1 (was on v8.0 when this was opened, but nothing has changed for better or worse since then).

    I agree with your take on this, I think something is artificially blocking this, but I have no sense of what that might be--just what it is not.  It is definitely not the network.  The only real wildcards here are if, perhaps, this is trying to impersonate a user instead of running as the service account.  The former would fail across the board, the latter should succeed.  Then I wonder if the cert referenced in the config needs to be added to the DB server, or if Kerberos factors into some part of the connection...etc.

    The config is how the installer set it up--no more, no less.  If there are additional steps that need to be taken to set this up, I am completely unaware of them, but more than happy to perform them.
  • seth_coussensseth_coussens Product Owner Ninja IT Monkey ✭✭✭✭
    None of that should be required. We have this up and running using HTTPS on this version and version 8.1.2 and have online https access to the portal and the end points. This is most likely something support will have to have a session with you and dig in a bit as it doesn't sound normal.

    I'll be watching this and some other threads closely in the meantime and will add to this if I see this or we resolve it elsewhere.
  • Tom_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
    There is clearly something that the installer (and the installation guide, for that matter) is not taking into consideration here.  We have a very "vanilla" setup here, which is why I think some other customers are also encountering this.

    I would be glad to help find out what that "something" is, to the extent that I can.
  • Ian_GlennIan_Glenn Member Adept IT Monkey ✭✭
    I wonder if this has anything to do with Integrated Auth vs. Forms Based Auth?  We use Forms Based Auth in our environment and the Portal is not installed on a Management Server. Tom, what does your environment use?  Seth, how are your environments configured?
  • seth_coussensseth_coussens Product Owner Ninja IT Monkey ✭✭✭✭
    Could be related. We are using form based, but on a management server for our development environments.

    I'm using NTLM but also on a management server for my lab environment.

    @john_doyle
    have you seen similar issues in the configuration above?
  • Tom_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
    For the record, we are using Windows auth.
  • Tom_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
    I installed 8.1.2 in our test environment, and the dialog boxes requesting credentials disappeared, but now I have 404 errors in the console for all the same endpoints.  Users just see blank pages/grids/charts where there should be data.  I am honestly unsure whether this is progress or not.  Maybe...?
  • Ian_GlennIan_Glenn Member Adept IT Monkey ✭✭
    I installed version 8.1.2 on my portal servers.  If I access the portal site using the non-secure HTTP port (80) I am able to access the /platform/api URL and the new Asset Management ODATA views work.  If I access the portal using SSL port (443) I cannot access the /platform/api URL and the ODATA views are broken again.
  • seth_coussensseth_coussens Product Owner Ninja IT Monkey ✭✭✭✭
    Thanks Ian, I will add this to our tracking of this issue.
  • Tom_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
    After reading @Ian_Glenn's post, I disabled HTTPS in our test environment, to see if that was it.  Doing this only seems to allow non-ODATA calls on the same page to proceed (which is good, I suppose) but the ODATA calls still come back as 404's.  (See my earlier post)

    For example, on the "Asset Analysis" dashboard page:
    GET http://[SERVERNAMEHERE]/platform/api/Cached_HardwareAsset?$filter=LanguageCode%20eq%20%27ENU%27%20and%20(ObjectStatusId%20ne%2047101e64-237f-12c8-e3f5-ec5a665412fb%20and%20ObjectStatusId%20ne%20eec83e3c-0106-d4c0-99ea-93b75fd23020)&$format=json&$top=0&$count=true 404 (Not Found)
    GET http://[SERVERNAMEHERE]/platform/api/Cached_HardwareAsset/Action.GetChartData(Filter='LanguageCode=%22ENU%22%20and%20ObjectStatusId%20!=%20guid(%2247101e64-237f-12c8-e3f5-ec5a665412fb%22)',LabelFieldName='HardwareAssetStatus',ValueFieldName='Id',AggregateAs='Sum',SortBy='Label%20Descending')? 404 (Not Found)
    GET http://[SERVERNAMEHERE]/platform/api/Cached_HardwareAsset/Action.GetChartData(Filter='LanguageCode=%22ENU%22%20%20and%20ObjectStatusId%20!=%20guid(%2247101e64-237f-12c8-e3f5-ec5a665412fb%22)',LabelFieldName='HardwareAssetHasLocation_DisplayName',ValueFieldName='Id',AggregateAs='Sum',SortBy='Label%20Descending')? 404 (Not Found)
    GET http://[SERVERNAMEHERE]/platform/api/Cached_HardwareAsset/Action.GetChartData(Filter='LanguageCode=%22ENU%22%20%20and%20ObjectStatusId%20!=%20guid(%2247101e64-237f-12c8-e3f5-ec5a665412fb%22)',LabelFieldName='HardwareAssetType',ValueFieldName='Id',AggregateAs='Sum',SortBy='Label%20Descending')? 404 (Not Found)
    GET http://[SERVERNAMEHERE]/platform/api/Cached_HardwareAsset/Action.GetChartData(Filter='LanguageCode=%22ENU%22%20%20and%20ObjectStatusId%20!=%20guid(%2247101e64-237f-12c8-e3f5-ec5a665412fb%22)',LabelFieldName='HardwareAssetHasOrganization_DisplayName',ValueFieldName='Id',AggregateAs='Sum',SortBy='Label%20Descending')? 404 (Not Found)

  • Dennis_de_JagerDennis_de_Jager Customer IT Monkey ✭
    Installed version 8.2 on our test environment which runs SSL and I'm getting the same errors on the New Hardware Asset view. It didn't load any results and when looking into the console it showed:

    Failed to load resource: the server responded with a status of 404 (Not Found)/platform/api/Cached_HardwareAsset?$filter=LanguageCode%20eq%20%27ENU%27%20and%20(ObjectStatusId%20ne%2047101e64-237f-12c8-e3f5-ec5a665412fb%20and%20ObjectStatusId%20ne%20eec83e3c-0106-d4c0-99ea-93b75fd23020)&%24format=json&%24top=250&%24count=true Failed to load resource: the server responded with a status of 404 (Not Found)

    When run without SSL the New Hardware Asset view worked like a charm, it would actually load the 17k Hardware Assets in some seconds. (instead of minutes)

    Then I remembered I didn't do any SSL settings in the initial Cireson Setup, I actually made the SSL settings by hand and everything seemed to work, except ODATA calls.

    So I figured I would reinstall with selecting the Advanced Web Settings in the setup and this worked like a charm.

    It might not solve all occurrences of this error but it might solve some.
  • seth_coussensseth_coussens Product Owner Ninja IT Monkey ✭✭✭✭
    The platform and the portal itself are actually two different web services. The platform service is actually a OWIN application service that runs and hosts it's own webserver, we are just tying it into the IIS portal so that they both reside in the same URL domain. This provides the crossover. The configuration for the platform application is in a .json file in the Platform folder underneath the portal folder in the IIS directory. If the settings in the JSON file are not correct (which get set by the installer usually) then you will run into issues.
  • Tom_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
    I installed 8.2, even re-installing pre-reqs for good measure, and now I am back to getting 401 (Unauthorized) errors instead of 404's.  The end result is the same--no data in any OData widgets--except now my users are once again treated with a prompt for credentials that will not help with this problem at all, but might lock their AD account for a few minutes.

    What exactly could be going wrong in the JSON file that I should be looking at?  I still have not been contacted by anyone since the day my ticket was sent to development.
  • seth_coussensseth_coussens Product Owner Ninja IT Monkey ✭✭✭✭
    Ok let me follow up on the development side and see if I can push this forward. 
  • Karen_Bruster1Karen_Bruster1 Customer IT Monkey ✭
    @Seth_Coussens Did we ever get a answer or fix for this?
  • Tom_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
    Accepted Answer
    I can update this from my end, as I have a few observations to share, now.  As of 8.2.2 / 8.3.1, this is working in my environment, but I am not entirely sure if it was a software change.  Perhaps that is part of it.

    It seems to matter very much whether your environment is configured to allow connections to /platform/api, BEFORE the installer runs.  In other words, installing the portal then setting up your server to conform to all this endpoint's demands later does not seem to work.

    I had a dev environment and a staging environment, both on portal v8.2.2, both with identical IIS configs.  Dev worked, staging did not.  That seems to be because we added an SPN and configured DTC in dev first, then rolled those changes to staging later, which happened to be after the portal was upgraded in both environments.  I just now updated both environments to portal 8.3.1 and it fixed the issue in staging, while dev continues to work properly.

    The DTC config I am referring to was mentioned by @John_Long in another thread (https://community.cireson.com/discussion/comment/10723#Comment_10723 ).


Sign In or Register to comment.