SDK-Access Server Time Difference Reminder

When using a older Access Server SDK (7.0.4) with a newer Access Server (10.1.4) running in backward compatibility mode recently, the Access Server SDK always returned cookies that were logged out. The reason turned out to be because the time was never set on the machine the SDK was installed on.

However, the Access Server SDK installed correctly when it was installed. In previous incarnations the Access Server SDK would have never been able to be configured properly if a significant time difference existed.

This definitely falls squarely in the realm of user error, as the documentation clearly stipulates that when cert or simple mode are used the times have to be synchronized between client and server. In previous releases though you would never have been able to complete the SDK configuration. I can only imagine this has something to do with "backward compatibility" mode.

Access Server SDK on IIS5 / IIS6 (Part 2)

so we got the COREid AccessServerSDK working from ASP pages (part 1 here), but then we roled out to ASPX pages and low and behold we had the same problem. checked the permissions for IWAM_ and they were ok. then it dawned on Mark to check the permissions for the ASPNET user. We set those the same as for the IWAM_ user and sure enough success!

Access Server SDK on IIS5 / IIS6

One of the simplest things you should ever need to do with COREid in to install the Access Server SDK and access its functionality via ASP or ASP.NET on IIS6.

The key word here is should.

Sometimes you do everything right:

• Install the binary (theoretically no location requirement)
• Create the AccessGate profile
• Associate the profile with an Access Server
• Run configureaccessgate.exe
• Set OBACCESS_INSTALL_DIR
• Add %OBACCESS_INSTALL_DIR%\oblix\lib to the PATH
• Register the DLLs

And then something like:

validateSDKinstall.asp

< % @LANGUAGE="VBSCRIPT" % >
< % OPTION EXPLICIT % >
< %
dim accessgate
Set accessgate = CreateObject("Netpoint.ObAccessAPI")
accessgate.Initialize
Response.Write "If you see this, all is well"
% >

should run without error. Should.

Sometimes it doesn't.

We've seen a couple of instances lately (7.0.2 / IIS6) where things just don't pan out. The error code that shows up in the IIS logs is 80010105 and in the browser is Error '80010105'. Some googling reveals this is generally, maybe, a network security/permission problem. However, that is not the case with the AccessServerSDK. Upon turning up the log levels on the AccessGate we discovered file system permission errors. Not by what showed up in the oblog.log, but by what did not. Specifically, the log write could not initialize (FileLogWriter::initializeWriter() is the source of the error in the event viewer). This was the first clue that the problem was related to file permissions. The local IWAM account did not have the necessary permissions to write to oblog.log. Once this was corrected, oblog.log started logging and revealed that there still was not sufficient permission to create the necessary lock files.

So, if you run into something like this - check your FS security on AccessServerSDK/oblix.