The "classic" OPC is based on COM. That whole infrastructure is based on idea that when writing a client code, you should not be aware of the physical implications on the server side. Startig the server's process is one of the physical aspects of the server, and as such, it is completely hidden from the clients, for a purpose.

In OPC, the address space of the server - that is, the tree of items and their ItemIDs - supposed to be relatively stable. The server is supposed to provide the "best knowledge" of its address space as it has at the moment. The OPC clients have no way of knowing whether the OPC server has "just started", and maybe for this reason cannot yet provide the proper address space. Normally, OPC servers in such simply wait (block in the incoming call) until the address space is available, so they they always provide the correct information, although it may take longer during startup.
The error you are getting is not directly generated in our component - it comes from the OPC server and we are just passing it through. Basically, the server is saying that an ItemID which is in fact is not valid.
So, the true problem here is with the OPC server - it should not behave in this way, the address space its provides should be available right from the beginning. Which OPC server is this? Have you figured out "how long" it needs to run, before it starts providing the right data?
Besides the above, fortunately, there are ways to get around it, I think. The key to the solution is in the fact that OPC server's address space is supposed to be relatively stable, but not completely. This is difficult to quantify, some servers will never change their configuration, while some may do it let's say one par day, or when the underlying technology is reconfigured - in terms of months. What our component does is that when it encounteres an invalid ItemID report by the server, it marks that item as invalid, and it will not re-try it for a configured amount of time. It will, however, eventually retry, and you will start getting the data. The default period for this (TopicRetrialDelay) is quite long - 5 minutes (it is given in milliseconds, i.e. 300000), and all the failed items are consider for re-trial every minute (TopiRetrialPeriod, 60000 milliseconds). What I suggest is that you set the EasyDAClient.TopicParameters.TopicRetrialDelay to 10000 (milliseconds) and the EasyDAClient.ClientParameters.TopicRetrialPeriod to e.g. 5000 (milliseconds).
This will mean that even if you get the exception(s) first time, in 10-15 seconds (not in 5 minutes as now...) it will be re-tried, and so on. The downside of this is a higher load on the system.