Showing results for 
Search instead for 
Do you mean 

Event Log - Desktop History Queue Provider

Copper Contributor
Posts: 53
Country: USA

Re: Event Log - Desktop History Queue Provider

[ Edited ]

Apologies to the OP (princeedwardh): didn't mean to hijack your post here, but my question is the sameSmiley Happy


In our environment, I installed Act with the SQL server on one of our domain's several servers and created & shared the one sales database from the server. I installed Act on workstations without SQL server, and all workstations access only the shared DB on the server.

I get these errors on the server every time I open Act. I open Act on the server only occasionally, and then only to either configure the IIS connection or add/remove a user. It is never used as a regular client application locally on the server and never in relation to e-mail.


I manually ended the "32-bit Act.Outlook.Service (32bit)" process on the server, but it started again when I logged on again. Since it was not in C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp, I just went into the registry and found these two entries under HKLM\Software\Wow6432NOde\Microsoft\Windows\CurrentVersion\Run


"C:\Program Files (x86)\ACT\Act for Web\Act!.exe" -preload
"C:\Program Files (x86)\ACT\Act for Web\Act.Outlook.Service.exe"

I removed those, and now Act.Outlook.Service does not load, and I do not get the error originally reported here, so it seems that once again, I figured out a workaround to one of our many Act woes. Now I still get a string of "Act.Outlook.Service.Desktop" errors, but the semi-official Act answer seems to be "these are normal, so just ignore them" (#1 in this post:

For the life of me, I cannot figure out why any installation program would enable things like this on a server whose only function is to host a database. At the very least, there should be some server-specific instructions on what tinkering is required in order to minimize impact on the server by things that  have no useful purpose on the server. Better yet would be to actually determine if the environment is a server and simply not enable these problematic items, or at least offer relevant options during setup.


Please consider that this is all part of a much larger picture. It is all very frustrating to me as an information systems integrator and manager that, at every turn and with each update, I find new undocumented issues with Act that require tinkering with settings. It is almost as though Act development has really never gotten past the standalone computer concept and that the entire server installation was a compete afterthought, even though it is the only viable option in any kind of large organization that centralizes data, which describes every one of my clients that has more than four or five computers.


So far, I have had all of the issues below, amounting to probably 60+ extra hours now beyond what the Act documentation indicates as required, in the last year since first setup, and all of which I had to figure out either on my own or by helpful posts here on the forum. I have not found a full solution to any of these in the KB:


Had to disable Act Integration scheduled task on the server (figured this out on my own without posting)
Had to switch from the Act user account to the built-in local administrator account to get Act to connect to IIS (figured this out on my own without posting, but it took probably six or eight hours of research & testing to drill down to the issue)

Copper Contributor
Posts: 90
Country: USA

Re: Event Log - Desktop History Queue Provider

Thank You for your thoughtful reply!


OK, none of this ACT stuff is optional or a "nice to have".


Is there a better solution to ACT such that I should abandon ACT now and cut my losses?

Copper Contributor
Posts: 53
Country: USA

Re: Event Log - Desktop History Queue Provider

I have been dealing with Act off and on for about 15 years. From the start, it always felt kind of like QuickBooks did: great for the end user but with undisputable weaknesses in the underlying technology: designed for standalone computers, with sharing among multiple users over the network a nice subsequent feature but one that still seemed very focused on peer-to-peer networks. Especially in a fully functional Windows domain network, which is my primary world, it simply does not rise to the level of "robust" regarding efficiency and network security.


It has been suggested, and it may be true, that I funnel some of my frustrations through as suggestions, but (moderator, if you are reading this), please consider two things:


1. I am an outside consultant, so all the hours I spent here either come directly out of my pocket or, if related sufficiently to solving a problem for my customer, billable to my customer as part of the total cost of ownership of Act. The OP here, I am sure, feels this pain as a business owner/manager, since none of the time spent researching & accommodating or fixing deficiencies in applications is billable.

2. In my experience, the ear of development for most applications is far more tuned to the voice of the end user, since that is the person to whom the software sales staff are marketing the project. Nobody contacts me as a network manager to try to sell Act or QuickBooks, probably because they know I would ask the hard technical questions and find any holes in the answer fairly quickly. answer your question, princeedwardh, the decision to stick with a product ultimately has to be based on whether the pain of implementation is offset by the benefits.


Now, if we could really get through to dev on some of these technical issues, even if only to inspire documentation including the alternative setup required in various environments (such things as not breaking by backups for four months by Act using the wrong account when implementing SQL), it would be fairly simple to follow a few additional setup steps. While that still might seem a bit backwards compared to just having the design correct at the outset, it would be preferable to having to work through all these details here after much trial and error.

Copper Contributor
Posts: 53
Country: USA

Re: Event Log - Desktop History Queue Provider

I did stop the Outlook.Act.Service manually, repair .Net (which was at 4.6.1), but it made no difference. I am still getting the sequence of these four Desktop History Queue Provider errors at logon.


Stopped the Queues Timer
Queues Have Been Processed
Setting Processing to False
Restarting the timer to handle future records


I am sure it is worth noting that I get these only when I log on as system administrator but not when I log on as the end user that actually has e-mail/Act connection configured, I do not get the error. A bit more digging reveals the reason: the developers saw fit to embed the auto-startup of Act.Outlook.Service in KEY_LOCAL_MACHINE, as though it would be required for all users of the computer, instead of HKEY_CURRENT_USER, where it would open only for any user invoking it. The same is true for Act Integration which is embedded in the public Start Menu rather than being placed in the individual user's Start Menu upon first run of Act.


This may be fine in an environment where one user = one standalone computer, but it is moderately problematic in well-configured, efficient, and secure multi-computer environments, since it becomes yet one more small application among many and larger ones that requires specialized knowledge regarding what should show alarm and what can be ignored or requires special configuration to get it out of the way.

In fact, I find now that I must have crossed this bridge in the midst of the many setup issues originally, because when I open msconfig, I find this entry in HKLM along with a previously-disabled instance. So now I have worke dout this process and documented it for future reference as I manage Act:


1. Export the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
2. Remove these two values from that key
 Act! Preloader
3. Remove non-Act startup items from the .reg file
4. Modify the .reg file key from this:
to this:
5. Remove the shortcut to Act Integration from C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup
6. Log on as the end user
7. Import the .reg file above
8. Copy the shortcut to Act Integraton into C:\Users\[AccountName]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup


To put it in perspective: Act is just one small program on one server and a half-dozen workstations in a five-server, 50-workstation environment in a manufacturing environment. This is not to say that Act is unimportant; I fully agree that it is an invaluable asset to sales staff, but one that consumes an inordinate slice of information systems management workload. It is preferable to me to pay the price up front by working out ways to make it behave like a truly scalable application.


In my opinion, this should all be enabled within the current user registry node & start menu upon first e-mail integration with Act by the user. But as I have noted before, IT professionals that spend their weekends figuring this stuff out are not the target audience of the software sales staff, and it is of little consequence to SwiftPage that the customer has to pay thousands of dollars extra to a consultant like me to shoehorn the application into a very normal corporate environment in a way that will minimize its impact on resources while ensuring that I do not detract from the end user experience.

Posts: 451
Country: United_Kingdom

Re: Event Log - Desktop History Queue Provider

Thank you for the in-depth steps and work around to the issue @Brain, I understand the frustration that this issue could cause a user when seeing the errors and for sys admins to try and resolve the issue.


It would be great if @croberts would be able to test the steps provided in his own environment so that we would have additional result to work with.

Copper Contributor
Posts: 153
Country: Belgium

Re: Event Log - Desktop History Queue Provider

@Brain wrote:

In my opinion, this should all be enabled within the current user registry node & start menu upon first e-mail integration with Act by the user. But as I have noted before, IT professionals that spend their weekends figuring this stuff out are not the target audience of the software sales staff, and it is of little consequence to SwiftPage that the customer has to pay thousands of dollars extra to a consultant like me to shoehorn the application into a very normal corporate environment in a way that will minimize its impact on resources while ensuring that I do not detract from the end user experience.


I currently have about 7 and a half years of experience with Act. While the company and the end users love it, we in IT hate it. Pure seething hate.

I can't recall a point in time where Act was completely issue-free. There's always some defect, issue or bug you have to find a workaround for.

There is always stuff not getting fixed untill you cough up for the latest and greatest version (or never getting fixed at all: 2007 called, they want their DPI issues fixed).

Act has taken up a disproportionally large amount of time and resources from our IT department, up to the point that I'd warn any newcommer to take a hard look at the alternatives. Just as we are going to be doing when we find the time for it (if Act doesn't eat all our time).

Copper Contributor
Posts: 53
Country: USA

Re: Event Log - Desktop History Queue Provider

Note to moderator: I think you can see that I am not the only one with frustrations here. We in IT support do not have a lot of extra time, and we logically expect software to fit normal workstation, server, and network topologies without having to dig through the forum or KB to get there. Do you think there is any chance of opening some sort of technology-specific discussion (as opposed to end-user application functionality discussion) with SwiftPage dev management regarding getting these things cleaned up and current?


In my experience, many IT folks, especially those managing Windows domain-size networks, tend to know their stuff pretty well when it comes to network security, server-side application load minimization, correct client/server process segregation, and data protection. These are all areas where Act installation has provided huge surprises that require a lot of extra time to figure out.


Act, just like QuickBooks and a number of other applications that are marketed to standalone-computer businesses, and, I believe, to the detriment of small businesses using enterprise-level technology, really leave me with the impression that they have never really taken seriously the abnormal challenges they pose to those trying to provide technology support. This causes big attitude issues when end users assume that the IT support just does not know how to click OK as well as the end user.


This is not a complaint so much as a plea for someone to take this seriously as a request to open this as a discussion, not on this one issue, but in a way that can have some hope of being taken seriously by those overseeing SwiftPage development as an overlooked class of problems, needs, and suggestions related not to the user experience, but to back-end implementation and support. My impression is that SwiftPage markets to the end user who needs contact management, and once the sale is done, it is up to the technology staff to work around all of the issues. I suspect that things  may work fine in a single-computer or small peer-to-peer network where end users install their own software and assume that clicking OK is all that is required for a successful installation. But in our larger environments, as EUROPOWERGenerators indicates, there are a host of substantial issues.


In my case as an independent contractor, I suppose Act is costing the company $200 per month or something like that (just a wild guess, since I am not privy to the company's finances). But in the year since I first installed it, my client has also had to pay me upwards of $6000 figuring out and working around at least five serious setup complications and server-side functionality issues caused by Act on the servers I manage for them. The best I can expect here is that it might get into a KB article if I press for that, but I should not, in the first place, have to dig through the KB just to find out that the default SQL implementation with Act will make my entire company-wide shadow-copy-based backups crash for four months because the SwiftPage developers used the incorrect logon account.


That was an issue that could have made the entire set of virtual servers unrecoverable for my 50-user client in the case of a disaster recovery attempt before I figured out the problem and corrected it. Yet when I posted that issue, Act's response was that it was not their fault; it was really a SQL server issue. That is simply not true; it began with the Act installation and I distilled it all down to a faulty choice by the SwiftPage developers regarding which account to use for the Act SQL instance service. I understand how they could make this mistake, not being aware of the proliferation of volume-based backups in larger corporate environments, but there is no excuse for a response like that which tried to pass the responsibility off to me. At the very least, I should have been given the option of which account to use (even now, I am not), and there should have been a BIG note in the setup documentation indicating that I must choose the correct account to avoid crashing the entire company's backup!


So where is the aghast response from someone at Act indicating that they are taking seriously the need to resolve--not just document here on the forum or, at best in a KB article--some of these long-standing issues, not with the user interface, but with the scalability of the underlying technology? In my opinion, what we need is some sort of IT-specific user group that can be taken seriously by SwiftPage management. I see this happening with other industry-specific applications I manage, but I do not get a sense that it is a priority for SwiftPage, and I cannot figure out why.


After all, wouldn't you rather get five-star ratings from both users and their support staff instead of five from users and one or zero from support staff?

Posts: 451
Country: United_Kingdom

Re: Event Log - Desktop History Queue Provider

Hi Brain,


We do have a section where you would be able to raise your concerns and issues to our development team: here I am sure they would appreciate your insight into what you have experienced as we would not knowingly cause any problem for a customers or their IT provider, and are always looking to improve our product for all users and environments.


Please understand that we do take issues/defects very seriously and have multiple test environments and some of our ACC's trial the product before release of an update, however it can be very difficult to preempt or identify an issue if it applies to a specific environment/s or cannot be replicated.

You mentioned that you posted regarding the SQL server instance affecting backups, I am sorry as I understand that it would of caused a lot of stress and frustration for yourself and customer before finding the work around.

If possible you be able to provide a link to this issue when it was raised so I could review it in detail?




Copper Contributor
Posts: 53
Country: USA

Re: Event Log - Desktop History Queue Provider

[ Edited ]

Thank you, Horn.


Here is my original post on the backup issue:


And here is where I found that someone else had already crossed this bridge; the verbiage was just different enough that I did not find it right away.

In particular, see this post on the third page of that thread, where the moderator wrote this:


 "Indeed, this is outside of the scope of what's appropriate for the KB. Since this is not an Act! error, but an error that occurs within a third-party backup system when it attempts to access files related to a database/a Microsoft SQL Server instance without appropriate permissions. While the Microsoft SQL Server instance in this specific scenario happens to be the ACT7 instance, this is not an issue that is solely related to Act!. It can happen with any Microsoft SQL Server instance. We are not able to advise on configuration of Microsoft SQL Server or system permissions outside of that which Act! requires in order to operate."


Given the risk that the original issue introduced into some very sophisticated systems, I thank you can see why this attempt made to deflect the issue rather than accept responsibility did not sit well at all with those that have paid the price in increased risk of data loss and in their time. There was some further discussion, but never a final post indicating the promised findings. There are likely others out there that have not yet discovered the problem and will do so only in the event of a disaster recovery attempt. The post that was removed from that thread more or less just called the response above a failure to accept responsibility (verbiage might have been more colorful than mine, though!)


I have just been hoping that my sometimes lengthy, always detailed descriptions here might be passed along, and not just to the KB-writers; these issues need to be solved & prevented, or at least anticipated and provided with setup instructions, not just documented in the KB where we find them only after experiencing the problem. Again, note that I am an outside contractor, and I am not sitting here in a salaried position where I have the luxury of covering this. So I have to either simply swallow the time lost or bill it to my customer, and this is one thing that makes the TCO for Act much higher for the client than they would ever think based on the up-front cost presented by SwiftPage sales staff.


From what I can tell, the link you provided for developers sounds more like an area for developers of third-party add-ins or API-connected applications, and I am hesitant to post there items related to the development of Act itself, not add-ons. What we are discussing here is not an add-on; it is Act itself. In the interest of preventing further expense to my client, I would recommend passing these links along to the actual SwiftPage dev team.


And then there was the issue that took an enormous amount of time to figure out but that I never posted--regarding IIS configuration. I was repeatedly getting authentication errors after installing Act Premium Web and spent many hours working through various IIS-related suggestions on MS forums until I finally worked my way down to this fact: in Act → Tools → Web Site Administration → Add/Remove Database tab, the only account that will actually work to connect the database on a Windows 2012 R2 server is not the domain admin account (also in local administrators group) that I created to run the Act services or any other domain admin account; it must be the built-in/default local administrator account


While I understand this is a new complexity specific to Windows 2012 R2, and I have seen this type of behavior with other server-side applications, nonetheless, in my opinion, it is inexcusable, four or five years after the advent of that OS version, for developers testing installations of any application for newer operating system versions to be logged on as the default administrator 100% of the time when testing. They need to either ensure these processes work with any local or domain administrator account, or they need to document the requirement to be the built-in domain or local admin--preferably the former, since in large environments, the built-in domain or local admin accounts are to be used only for system management, not for software installation/configuration. My hope in posting all of this here is it will somehow wind up in the right hands--the SwiftPage developers.


As it stands now, my instructions to myself for installation/upgrade must include this:

 To fix/prevent IIS “Security Exception” error messages:
  Open Act on the server
  Tools → Web Site Administration
   Web Server tab
    Click Test (will probably succeed even when site not working)
   User Account tab
    Click Test (will probably succeed even when site not working)
   Add/Remove Database tab
    Click Test DB (will probably succeed even when site not working)
    Click Test button next to Virtual directories. If this generates “Security Exception”, need to do the following steps:
    Remove the DB
    Go to the User Account tab
    Change the user to the default local admin account
    Click Test to ensure the password was entered correctly
    Go back to Add/Remove Database tab
    Add the DB again
    Test Virtual directories again. This should now succeed
   Go back to the User Account tab
    Change back to local ActWeb [my local administrator account for running Act services on the server] admin user & password (same as domain admin password)


And I apologize for writing a book here; I just can see no other way to describe these issues with sufficient detail. And I do understand that Act is not intentionally creating problems here. That would make no sense for SwiftPage, fiscally or support-wise. It is just that there are several of these underlying-technology issues that have been posted here with no way of knowing that they are being taken seriously enough to make it to the SwiftPage development managers.


Suggestions from end users are just that: suggestions for ways that an application can serve the end users' needs better. But what comes from support staff can easily be construed as complaints that things are simply inconvenient. This is only because the support staff 1) are a small number of users--probably one for every 10 or even 100 Act end users, 2) live entirely in the realm of overhead expense to the company and 3) do not generally function as end users of the product much.


None of this is simply preference or convenience on my part. I would go so far as to call every issue I have experienced and reported here either a bug or poor setup documentation. But if SwiftPage sees bugs only as those things that either prevent installation or adversely affect end users directly, I suspect our experience and concerns here may fall into a black hole somewhere.


Also, for the record, SwiftPage is not alone in this. Every time a client says, "Here, come install this enterprise software", I do not immediately think "Great! They are solving a problem." I have found I have to start with "I wonder if the developers have tested implementation in fully-secure and well-managed networks"--such things as allowing hidden share use and non-default domain admin accounts for setup.

Posts: 4,041
Country: United_Kingdom

Re: Event Log - Desktop History Queue Provider

Hi Brian,


Thanks for this feedback. I'll use your post as a reference when discussing the highlighted issues further with the Product Management team.


If further technical detail needs to be discussed with any engaging members of staff, this can take place on the posts you have already made on these issues. You're correct in thinking that the Developers Lounge area on the Community is intended for focus on the development of add-ons and integrations with Act.


In regards to your IIS configuration issue, I do believe this can get rather complex when it comes to authenticating with domain admins. I feel like our documentation could be improved in this area.

I'd be interested to know if you have any more success if you were to hardcode the username and password into the web.config file instead of using the Web Site Administration setup feature. You can find instructions on how to do this in the following Knowledgebase: KB 25870