Sage 100

2018 advanced. Installing on a new server with new external IT company. I just had a semi-heated discussion regarding the Sage 100 installation and what resource I will need to be successful. 1. Does UAC need to be turned off during the installation? (IT says absolutely not). 2. Is logging into the server as the local administrator the same as assigning the dhiggs user administrator rights? (IT says absolutely yes). 3. IT claims that because Sage 100 is a 32 bit program it can only reference 4 GB of memory therefore any memory allocated above 4GB is wasted. Thoughts on this please.

- Send them the SPM, if you haven't. This is my CYA 101 move

I sent it to them a month ago and also talked to them at length on the phone about the server specs. The server is about ready to be deployed and he calls me today and lays this crap on me. I am trying to be a team player but this guy is trying my patience / questioning everything. BTW I usually double the recommended memory settings that Sage has in the SPM as they publish the bare minimum.

Want me to call him? I'll tell him I'm head of development. I won't say from where. Maybe he'll fall for it. I just did an UG 2013 to 2018 and had them bump up their memory on the server from 8 to 16 GB Unfortunately, I usually take whatever account they give me that's administrator equivalent. I've never checked to see what the actual rights are. I find if there are going to be issues with privileges you'll know during install. I usually have them shadow me so they can put in the login for that integration engine which is installed during setup.

Sage 100 is not one program, it is a collection for programs, and each user process has a corresponding pvxwin32.exe. The 4GB limit would apply to each exe instance. Generally I tell them that their concerns are valid in theory, but if they want Sage 100 to actually work they need to do what I (and the SPM) am telling them to do. I also find a high correlation between IT stubbornly protesting this and the chance that the new server will show up with just a C:\ drive...

All 3 are technically true, but for #3, each Sage process will only see 4GB of addressable, but there are multiple processes and the cumulative whole of the processes can/will use > 4GB on the server.

I double the fee for high security environments/troublesome IT when I know this ahead of time.

Thanks guys.

20 users. The physical server has 120 GB of memory. 3 VMs : a domain controller, files server, and Sage 100 server. IT is whining about me asking for 32 GB of memory.

Wait until you ask for more cores or to connect unattended remotely. Then you'll hear **real** wining.

What Steve and Phil said. What I've done to show my argument is give them this type of scenario.: If there are 20 users each with the Launcher + avg of 4 screens opens, that is 5 pvxwin32 processes / user running on server. Then multiplied by 20 users that is 100 pvxwin32.exe sessions. If each one takes 48 MB on avg (which is embellished of course), then that is 4.8 GB of RAM needed. Not to mention what the App Server needs itself and CS ODBC Driver (up to 1 GB if heavily used). So there you've exceeded 6 GB already. And what if there is more than 100 sessions --> then more RAM is needed. I'm usually recommending between 8 - 16 GB of RAM for Advanced depending on number of users and other apps (SQL Server, SQL apps, non-SQL apps). If SQL and/or other apps involved then 16 - 32 GB depending on other factors. I also always ask the question of future growth a year from now in terms of Sage new users, new apps on the Sage server, etc and if that's foreseeable then add more RAM. Doug I would be more concerned with asking how many processor cores are allocated.

#1 - ""should"" be true, but I don't know how many issues we've resolved by disabling UAC and reinstalling. (Hint: many). 100% of the time now we disable UAC for the initial server install. #2 - yup... no problem. We use named accounts with local / domain admin rights all the time. #3 - what everyone else said. Per process.

On the question of Local Admin vs DHiggs as admin, the Local Admin might actually be a stronger account but it's best not to install that way. E.g. You know that the Sage service should be running with a domain account so that UNCs executed directly from the server can access other network shares. Might as well do it right to begin with during the installation. Sometimes they need an example and this seems to work a lot: ""You know how when you install SQL Server it defaults the main SQL service and other to LocalSystem but then if you want to use SQL Database Mail or connect to other SQL Servers or uses SSIS, almost always you have to use a domain account, well same here"". * Best scenario to avoid future issues is domain account with Administrators right to the local server which ALSO mean that same account does NOT have to be a domain administrator. * 2nd best scenario is domain account that is member of Power Users group of the local server. This has worked out nicely for me in the past. * 3rd best scenario is use Local Admin then change the service afterward to use domain account.

Never gets old - From Alnoor https://90minds-com.socialcast.com/messages/33659529?ref=stream

I'd would prefer if they would give me the domain administrator pw but that not happening. Maybe I can get dhiggs with domain administrator rights. I appreciate everyone's comments.

They never will. Best you can do is get them to shadow you in the initial install.

What @JeffSchwenk said - do the best you can to build that extra effort into the fee. Anything medical or finance related with stringent security - I allocate much more fee wise toward proiect managing their IT department.

Unfortunately I already quoted the job and have received a signed contract. From now on I am going to add a ""Stringent security"" and ""Dealing with IT that thinks they know everything about Sage 100"" clause / up charge.

Grit your teeth and make a note for the next quote. I find people ignore all types of clauses so you really have to catch it in the early stages. My customers aren't very open to ""your IT is a pain so here's another $1,200 bill"". Been There. Done that. Got the T-Shirt. Don't slug me but once you identify these type of customers they can be pretty profitable because finance doesn't like dealing with IT either and understands why you are charging more.

* Changes in project scope (including unforeseen technical restrictions imposed by company policy) will result in additional charges at a rate of $1,000 / hr. ;-)

@KevinMoyes Seems reasonable to me!

Pretty much anything in or related to these industries is going to have stringent IT: - Medical - Public company - Regulated financial industry - Governmental or Gov't contractors - Anyone who asks you to sign an NDA, provide proof of insurance or undergo a background check

I think that I extremely dislike most IT people. I once had a similar heated discussion with a customer's internal IT manager about turning off UAC to install. He kept saying that my information was like 'the tail wagging the dog'. I should have started barking, for all the good my part of the conversation did. I couldn't budge him.

I usually add a requirements list to any proposal that includes ""Unattended remote access with admin rights"".

@PhilMcIntosh They will give me unattended remote access. Also, they will give dhiggs local admin rights. I want domain admin rights, and I would prefer to have the domain administrator password. I may be incorrect but I have in the back of my mind that assigning dhiggs or any user domain admin rights is not the same a logging in as the domain administrator. Similar to having a SQL user account that has sys admin rights is not the same as logging in as ""sa"".

Doug in my experience, I think that access of dhiggs domain account having Local Admin to the Sage server will be fine. Even if they gave you only access to Power Users group on Sage server it would be okay. The point of setting UAC to None and rebooting prior to that for installation purposes is still important though.

UAC control panel applet is useless in Server 2012. I do the registry change directly.

From page 14 of the Installation and System Administrator's Guide. Does anyone know why Sage would strongly recommend using the Administrator account rather than an account with administrator rights?

...because that was the Best Practice 20 years ago. Nowadays, either the 'Administrator' account is disabled by default, renamed, or used as a honey pot.

Ignorance and expediency. It's an easy question for the 1st level helpdesk to ask: ""are you using THE administrator account?

Nice to know Sage is keeping the installation guide up to date. ;-) Are we supposed to be trying to weed through the bs and figure out what info is relevant to 2018?