Issue when printing as a non-administrator

[laurenwb]

Within the past 6 months or so at my organization, we've begun to encounter an issue with printing from Alpha Five v11 Runtime. All PCs here are running on windows 10 Pro. This used to occur occasionally and could be resolved by restarting Alpha, but now occurs 100% of the time. This also coincides with us updating our PCs to a more recent build of Windows 10.

The issue is as follows:
- When attempting to print a form (Print Current Record > Print), nothing happens. No dialog box or anything, though sometimes the cursor spins a bit indicating it's doing something. Nothing comes out of the printer.
- When attempting to preview a form (Print Current Record > Preview), the window goes blank and a dialog box appears which says: "Printer error: preview - hdcPrn is NULL".
- When attempting to print a report (Print > select a printer) a dialog box appears which says: "Internal error: 10003 - Backward access during sequential database processing".

All of these issues go away and printing occurs normally when alpha is run as administrator, but of course, it's a major security issue to have our users armed with administrator credentials so they can run alpha as administrator every time. I've been scouring google for quite a while about this, and I've tried several options.

Everything I've already tried to no avail:
- Running Alpha in compatibility mode for Windows 8, 7, and XP
- Uninstalling and reinstalling Alpha
- Fully wiping and reinstalling Windows, followed by Alpha
- Going into Windows printer settings and making sure AlphaFivePrinterV4 and AlphaFivePrinterV4p5 both have their port set to "NUL:"
- Making sure the form in question is set to "use default printer"-- unlikely to be the issue anyway since reports also won't print

Can anyone offer guidance on this issue? I'm really stumped.

[Ted Giles]

You may be confusing "Run as Administrator" in Win10 and Administrator on Alpha.
If you have set reasonable security, the 2 are different.
Suggest setting Run as Administrator in the DT link.

[laurenwb]

You may be confusing "Run as Administrator" in Win10 and Administrator on Alpha.
If you have set reasonable security, the 2 are different.
Suggest setting Run as Administrator in the DT link.

Are you referring to the desktop shortcut? If I run that as administrator (either by right-clicking or by setting it to always run as administrator), it of course requires the credentials of a domain admin in order to run it, which is a security issue.

What I've found is that on the same PC and same Alpha install, printing will work fine when logged in as a domain administrator account, but have the above issues listed when logged in as a non-administrator account. Unless, of course, a non-administrator account right-clicks Alpha and selects "Run as Administrator", which isn't a workable solution for us since it requires admin credentials anyway.

[glenschild]

This happens everytime a windows 10 update takes place and is a real pain. It knocks out the registry settings for the printer and you have to reset to allow everyone to print. The app I had this issue on migrated to a browser based system about a year ago but found my notes!

In the registry, HKEY_CURRENT_CONFIG -> Software -> "your printer driver name", right click on the entry and select Permissions..., make sure that the Users group has the Allow check box check for Full Control. Done

[laurenwb]

This happens everytime a windows 10 update takes place and is a real pain. It knocks out the registry settings for the printer and you have to reset to allow everyone to print. The app I had this issue on migrated to a browser based system about a year ago but found my notes!

In the registry, HKEY_CURRENT_CONFIG -> Software -> "your printer driver name", right click on the entry and select Permissions..., make sure that the Users group has the Allow check box check for Full Control. Done

Unfortunately, that doesn't seem to have worked. I tried adding Users (which was <local pc name>\Users), and when that didn't work, I tried <domain>\<the specific non-admin user logged in>. Same errors as if I hadn't done anything, and that situation didn't change after a restart. THEN I tried adding "Everyone", still nothing.

(That was editing AlphaFivePrinterV4, AlphaFivePrinterV4p5, and Amyuni Document Converter. After those didn't work I tried giving full control permission for everything in the Software folder as a last-ditch effort... still no dice.)

[Ronald Anusiewicz]

Did you try this?

image.png

[Ted Giles]

Lauren, you are not alone with these problems. We have all had them.
The Administration issue is the easiest to fix.
Using Ron''s image - which is what I was suggesting - you will be able to run the Alpha Engine within Windows as Administration. This allows access to all Alphington Engine requirements.
It does NOT give users Admin privileges to the user's of the software.
Alpha Runtime is pretty locked down and as this seems to be new to you, given it was showing up as a first post, if you need help, send a PM (click on a name in the thread and send a message) with a contact #. Depends where you are situated but most regulars on here are happy to help out.

[laurenwb]

Lauren, you are not alone with these problems. We have all had them.
The Administration issue is the easiest to fix.
Using Ron''s image - which is what I was suggesting - you will be able to run the Alpha Engine within Windows as Administration. This allows access to all Alphington Engine requirements.
It does NOT give users Admin privileges to the user's of the software.
Alpha Runtime is pretty locked down and as this seems to be new to you, given it was showing up as a first post, if you need help, send a PM (click on a name in the thread and send a message) with a contact #. Depends where you are situated but most regulars on here are happy to help out.

I think I may be miscommunicating my issue. Yes, it's true that to have alpha "Run as Administrator" fixes all the printing problems. However, to my knowledge, there is no way to run a program as administrator without either being logged in as an administrator, or entering administrator credentials in the UAC prompt. Using the image from Ron above simply causes the UAC prompt to display requesting credentials when opening the shortcut. This is not a workable solution because my users are not administrators, and it's a security issue to give them administrator credentials to enter into the UAC every time they want to open Alpha.

Additionally, I tried Ron's suggestion of installing directly in C:/, which unfortunately didn't change anything.

[Ronald Anusiewicz]

What are your permissions for the folder where your application files are stored?
Our application files are store in the folder C:\Maint and below is the security settings for that folder.
This is running on Windows server 2012.

image.png

[laurenwb]

What are your permissions for the folder where your application files are stored?
Our application files are store in the folder C:\Maint and below is the security settings for that folder.
This is running on Windows server 2012.

image.png

Unfortunately not that one either, domain users have full control of the database folder on the fileserver, and just to be safe I also tried adding the individual user I'm testing this with to no avail..

[Ted Giles]

What version are you running?
You are just setting run as administration only for Alpha aren't you?
Not for everything, just Alpha.

[laurenwb]

What version are you running?
You are just setting run as administration only for Alpha aren't you?
Not for everything, just Alpha.

Yes, only Alpha. Any time a non-administrator wants to run a program as administrator, they require administrator credentials to be entered in the UAC pop-up.


Something else has occured to me from troubleshooting this, though: I arrived here in 2019, and this organization has been using A5V11 since 2011. The entire time, the way they've used it is to have the database file stored on the local file server, and for each user to open that database file from alpha. But in these forums I keep hearing mention of having Alpha "running on the server". My intuition tells me that whatever that means, it's probably the "best practices" way of doing it, but has never been done here. The fact that we don't do it that way isn't the source of these problems (after all, it worked fine for a decade), but changing it may be the solution.

Is switching to that approach a good idea? Is there further documentation on how to do this around?

[Ted Giles]

There is a much later version of V11.
What is your current build?

I presume you are not running a Shadowed system with everything except the tables held locally?

[laurenwb]

There is a much later version of V11.
What is your current build?

Is there? According to https://downloads.alphasoftware.com/...chDownload.asp , "The current Alpha Five Version 11 build is 3381_4096", which is what I have installed according to the screenshot.

[laurenwb]

I presume you are not running a Shadowed system with everything except the tables held locally?

No, the .adb file and tables are all in a folder on the fileserver.