New Dayz Server - Dayz.revenantgaming.com:2302

Sipowicz

Server Admin
Staff member
#1
Hello Friends!!

Had an issue with our game machine today that I think I solved. One that I already addressed when I originally wrote our update scripts roughly a year ago. I wanna detail the issue here just in case it falls within in the scope of knowledge for any of our members. We could always use help on keeping the machine(s) maintained, and developing new features. If you have that kind of background and are interested let us know.

***

Our back-up scripts are PowerShell Scripts. In those scripts I use an “Invoke-WebRequest” Command-let. This command parses HTML with “Internet Explorer”. I use this to scrap the most current date for each of our mods.

TCAdmin is the Software we run our game servers with. It runs two background services that manage and monitor the games. "Service Manager", and "TCAdmin Monitor". These background services by default are logged into what is called “Local System” account.

The "TCAdmin Monitor" is what runs the PS Scripts. However with its log-in credentials, and as a service, the “Invoke-WebRequest” command-let our scripts use generates this error:

“Invoke-WebRequest : The response content cannot be parsed because the Internet​
Explorer engine is not available, or Internet Explorer's first-launch​
configuration is not complete. Specify the UseBasicParsing parameter and try​
again.”​

Based on my research….. In most cases, since this function relies on IE, that just means Explorer has not been run from that account yet and needs to be. Unfortunately, In our case, that means Explorer CAN NOT run in the same environment as the TCA Monitor (Local System – Service Environment)(Why I don’t know). I could NOT find a way around that fact. -UseBasicParsing was also not an option as it disables the functions the script needs to find the Data we need.

My solution was to FORCE the TCA monitor to “Log-in” as the “Root” user (I already know any Sys admins reading this are cringing….). This worked to solve the problem. The scripts, and almost everything else worked normally. I say almost because we would occasionally have weird issues with the Web Panel not doing things correctly (I suspected permissions issue related to the user account being used).

Aside from some odd ball issues here and there, scripts were working fine. Until today. With-out warning, and before any system changes (updates, clean-ups, etc), our scripts began generating this error:

"Test-Path : The term 'Test-Path' is not recognized as the name of a cmdlet,​
function, script file, or operable program. Check the spelling of the name, or​
if a path was included, verify that the path is correct and try again.​
At C:\******\******\******\******\autoupdatescript.ps1:15 char:5 (actual path hidden for security reasons)
+ If (Test-Path $updateinprogress) {​
+ ~~~~~~~~~​
+ CategoryInfo : ObjectNotFound: (Test-Path:String) [], CommandNo​
tFoundException​
+ FullyQualifiedErrorId : CommandNotFoundException"​
???????

Right?

I tried a couple of commands to address this error, and subsequent errors. But it became clear there was another issue. The script would just run right. Permissions?

I created a new Basic User (nothing fancy), and forced the Monitor to log with those credentials just for “Ha-Ha’s”, and that did the trick. As of right now, all scripts are working flawlessly again, and the Web Panel is generating NO errors.

Winning?? TO BE HONEST… I don’t know… But it is WORKING… for now…

If you have any ideas about any of this nonsense feel free to post.

Thanks for reading,
Sippo
 
Top