I have written a library thatused storage APIs to register app, add and remove blocks of data.
If I load my library using regular test app (dialog based application) I can register app and add blocks of data and remove them as needed.
When I use the same library with my service, I can register an app, and I can see that ISVS_AllocateBlock returns success but allocated block is always invisible,
even though parameter BlockHidden is always set to false.
Thank you for your input
Thank you for your reply.
One more bit of information. If I use storagedump C++ sample from AMT SDK, I can see my block, but unable to get its contents -ISVS_ReadBlockMtu returns (inside ISVS_ReadBlock) returns 0x000000010 which is PT_STATUS_NOT_PERMITTED.
I am still trying to get some more information, but while we wait, can you tell me what userid you are using? Are you using the "admin" user or did you create your own? If you created a user, does this user have adaquate permissions?
I am using 'admin' and have not created any additional users. As I've stated before,
Icall the same code (a DLL that is linked with iamtD.lib) and the same credentials to connect from two different apps (one is a dialog based app and another one is a service) and getting different results.
I can provide myapplication so you can reproduce this problem.
Webelieve the problem is related to the permissions group that has been set.
When you allocate a block through a registered application then only that application can access the allocated block.
In order to allow other processes (applications) to access that blockyou need to set a permissions group using the ISVS_AddPermissionsGroup API call.
Ifyou do not do that then only the registered application that allocated the block will be able to see it.
Please let us know if this helps,
Gael - Yury has tried this (tried adding read write permissions)and he continues to have this problem.
He is basically trying to do the following
He is stuck and needs help. My question is
1) Isnt this very similar to the sw inventory use case http://software.intel.com/en-us/articles/intel-active-management-technology-use-case-2-software-inve...
2) If so, Are there code samples for sw inventory?
3) How do we resolve this?
All the code samples are in the "Samples" folder in the SDK. Have they looked through the Readme files in the various StorageSamples folder? They may want to look through the APITest Sample which is also in the StorageSample Folder.
Additionally, see the Network Interface Guide and the Storage Administration sample application for more information on how to use AddStorageEaclEntry and AddStorageFpaclEntry.Attempting to run the storage samples without the enterprise name or partnerentries will result in an error.
On the topic of 3PDS local & remote access, I have been bombarded in recent days about reading and writting data from both local and remote Intel AMT interfaces. Many have reported that placing data into 3PDS using the local interface and obtaining it remotely is not working. I can confirm that I have seen the problem myself.
In the last few days, I started adding improved 3PDS support in Commander and started to add support for 3PDS in Outpost, the Intel AMT DTK local agent. I am adding a complete UI for setup and control of block permissions in both Commander and Outpost. So far, I have not found a fix. Once the UI's are build, I expect to be able allow full control over permissions and hopefuly find a fix.
In the mean time, the Intel AMT development team is pointing me to the SDK sample that is supposed to demonstrate this. I have not tried the SDK sample myself, prefering to work on the DTK instead. I expect to be done at the end of this week, in the mean time, I have over 12 hours of airplane traveling to get back to Oregon tomorrow.
Ylian (Intel AMT Blog)
It's the "Virus Signature" samplein the "Storage Samples" of the SDK. A quick update on my work, I have gotten Outpost to see blocks created using Commander so, I am certainly making progress. The usage of 3PDS is not what I initialy expected and so, I am going to have to change Commander a little. My flight back to the US is boarding now, more on this topic soon.
A quick update to say the version v0.33 of the Intel AMT DTK is released with much improved 3PDS support in Commander and added support for it in Intel AMT Outpost. Both Commander and Outpost can now manage storage blocks and set permissions. As a result, it's now much easier to figure out how 3PDS works, it was not obvious to me at first.
Ylian (Intel AMT Blog)
Yes, I really need to blog on the topic of storage because it's not easy to use. I suggest you try the latest version of the DTK, and use Commander and Outpost to try storage before looking at other tools. I added storage into Outpost in the new versions.
It is important to understand that with 3PDS, you can't access any blocks unless you register yourself first. This is true on both local and remote interfaces. When you log in using Commander as administrator you can see all of the registered applications and Commander will "register" as each application with a GUID of all zeros (0000-0000...). This way, you get to browse all of the blocks.
On the local side, you don't get to see other applications in advance, so, you have to give Intel AMT Outpost an Enterprise, Vendors, Application and GUID to register with. If the Enterprise does not exist, the registartion will fail. Once registered, you get to see all the blocks that belong to that exact registration and you may see other blocks depending on permissions.
I suggest you try it out with Commander and Outpost and be aware that what information you use to register to 3PDS makes a big difference in what blocks you see and don't see.
I hope this helps,
Ylian (Intel AMT Blog)