Hi, everyone! I'm kind of at the end of my rope here. This is RoboHelp Classic 2019. We're at v.12, cannot update until we vet the updates, but this issue started before the updates.
We have 4 projects, 3 machines with 3 different users. The problem I'm having only happens on one machine. We use svn for source control, using the plugin that Adobe supported in the past for RH Classic.
Things I've tried:
The nature of the issue leads me to believe the problem is something to do with a cached file that's corrupted. Like RoboHelp thinks the search index is already good, so it's not going to rebuild it. And that the topics are good, so it's not going to think about rebuilding them without conditional content (or with it). The project is already set to delete the .cpd file every time it opens. I don't know what other files could be causing the problem and am hoping someone will have an idea of what files would be safe to delete. I did find some cache files in my own roaming profile that I considered deleting on that machine, but I am not sure how safe it is to remove those things.
I'd appreciate any directions or advice anyone might have to help me fix this thing!
What sort of machine is the build machine? Is it a regular windows 10 install or is it a server install or a web server?
I assume the problem appears locally on the build machine? Or is the problem on a web server after the output is published?
Not sure I can help, but possibly these things could make a difference.
It is a server. The machine is scheduled for an OS update soon, but yes, it's a windows server 2012 R2 machine. After the upgrade it will be windows server 2019.
Also, make sure the cpd, ldb, and pss files are not in source control.
And are you generating to the local hard disk or to a network location?
I don't think so. I considered it, and I have asked for another VM to have the build machine run from, but that will take a while because we're in the middle of an acquisition and IT is overloaded. I did try a scenario where the build machine uses source control like we do (created the same folder on the c drive, copied the project over to it like we do, ran svn update), and that did not fix the problem.
Honestly, I am at the point with support that I really want to stay away from them. I clearly told them the last time I contacted them that I could not allow them control of my machine per IT rules, and so I used their screen share from my personal machine and just showed them my work computer throught the remote connection and the rep threw a hissy fit because he couldn't control the machine through the RDP. That leads me to believe that they don't care about my internal security and they're going to try to do it themselves, anyway. It was actually a bit sneaky, but put me off support.
I'm still really thinking it's some system file that's corrupted, it won't re-build the search index or change anything, it's just stuck using some cache. I can't even try a different user, though, because that machine is super restrictive and I'm not allowed to log in to it with any other user profile.
I would heavily suspect that source control on that build machine is messed up in some way. Which way exactly, I couldn't say, but echo Peter's comment that you should reach out to the RH folks at Adobe.
I worked around the source control set up by mimicking the setup that the satellite computers used, and the problem still occurred. It feels to me like a cache file or system file problem, but I'm not allowed to uninstall/reinstall things on that machine. But if it's user, then that won't help, anyway.
If your "build" machine is so locked down you can't do much on it, then I think your only workaround is to generate on one of the machines that doesn't have a problem & manually transfer the output to wherever it belongs.
That's what we're doing right now, but long-term it's got to get fixed. I only have access to it through another person, so I have to annoy people to do any troubleshooting on the machine. They keep it locked up tight, and for good reason, the entire product is there. (There are back-ups, of course, but the goal is to have a pristine environment to run all builds for releases. No third-party software, just bare minimum.)
I had intended to reach out to see if some of my contacts could help but you have effectively made that pointless. The scenario is akin to telling a garage to fix your car but you can't bring it in and even if you could, you wouldn't let them look under the bonnet/hood.
You have a situation where you say things were set up in an unsatisfactory way so fixing that would seem to be the first thing to address. From what I can gather, your IT are not co-operating on that so it can't be fixed.
The next thing would be for someone with the expertise to help but you can't let them. From time to time I screenshare with people and it's a huge hindrance if they can't give you control. You tell them to do something and just before the screen changes you spot something. If I were in control I would not complete the action but no matter how quick you say stop, it's too late. Go back is not always an option, things may have changed.
I understand your situation but IT have got to be brought in. Would they allow a screenshare with one of them present? There is always a kill button if they don't like what Adobe are doing.
I don't know if I can find anyone to help with this but as I said at the beginning, they have to be allowed to look at the setup.
Sorry if this sound like I am trying to kill this thread. I certainly am not but I don't know how anyone can help given all you have explained. It's going to need some serious knowledge and poking around.
If you want me to reach out, let me know but it will end up with someone needing to have access to the engine to fix it.
I mean, I understand to a degree, but I've also worked support in the past and can move the mouse for them without giving them unlimited access to a secured machine that houses our entire product.
I think you misunderstand. It's not the screen share that's the problem. It's the control of the machine. That's what the rep was mad about, I shared the screen with him just fine, he just wanted control of the machine.
It's possible being a server version of Windows could cause problems. Maybe that is something to ask them specifically.
On the build machine, try generating the output to completely different local folder and see if that works. Like C:\test_output or something you've never used.
Perhaps ask IT to double-check the permissions to the folders the build machine is accessing for both source and output.
Or what about antivirus? Perhaps it's particularly aggressive and is preventing files being written because it's scanning?
I understand the concern about giving control but as I have said, there is a button at all times where if support go to places you are not happy with, you can kill control instantly.
However, I think maybe Amber has hit the nail on the head with something I had failed to pick up on. If RoboHelp itself is installed on a server, it is not supported.
What's involved in not running RoboHelp from the server?
Yeah, I tried that angle, too. They were going to set up a windows 10 pristine install just for running builds... and then our company was acquired by a new company. New company uses Flare, so we're all switching to that. I'm not sure that was the answer, though. I really, really think it's something corrupt in the user profile. I bet if I could log in to that machine as a new user, it would work fine. But I can't, and I won't get the opportunity. Flare migration is in full swing, and we'll be moving everything to their madcap central, which will make the build machine redundant, because all the builds for central happen in the cloud.
Thanks for all the help attempts!
Good luck with that. 🙂
I would be interested to learn how you get on with Flare. Always good to know what people who have used both think of each of them. Use the Contact page on my site if you have time a bit further down the road.