Community
Showing results for 
Search instead for 
Do you mean 
Reply

Event Log - Desktop History Queue Provider

Copper Contributor
Posts: 49
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:https://community.act.com/t5/Act-Premium/Frequently-repeated-log-entry-Starting-up-database/m-p/3288...)


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)
https://community.act.com/t5/Act-Premium/Customize-share-name/m-p/340706#M46362
https://community.act.com/t5/Act-Premium/Granting-backup-user-access-to-Act-database/m-p/328839#M433...
https://community.act.com/t5/Act/Installation-of-ACT-reproducibly-destroys-ability-to-make-Image/m-p...
https://community.act.com/t5/forums/editpage/board-id/Prem/message-id/46397

Copper Contributor
Posts: 67
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?

Highlighted
Copper Contributor
Posts: 49
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.

 

So...to 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: 49
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.Outlook.Service
 Act! Preloader
3. Remove non-Act startup items from the .reg file
4. Modify the .reg file key from this:
 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
to this:
 HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
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.

Moderator
Posts: 264
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: 148
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: 49
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?

Moderator
Posts: 264
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?