Running a GreedyCraft server with itzg/docker-minecraft-server

A quick guide on spinning up a GreedyCraft server in docker with the itzg/docker-minecraft-server container and docker-compose on Linux.

  1. Download the GreedyCraft server files zip file.
  2. Extract the files to a temporary folder. We need to make some changes.
    • Rename run-linux.sh to run.sh This is the shell file the docker container will expect, if you do not rename the file, the server will fail to start.
    • Edit run.sh to include the JVM custom flags. See the README_SERVER_INSALLATION.txt for more information about this. For example, assuming a 20GB allocation you could use:
java -Xmx20G -Xms20G -Xss4M -Dfile.encoding=GBK -Dsun.rmi.dgc.server.gcInterval=1800000 -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:+AlwaysPreTouch -XX:+UseStringDeduplication -Dfml.ignorePatchDiscrepancies=true -Dfml.ignoreInvalidMinecraftCertificates=true -XX:-OmitStackTraceInFastThrow -XX:+OptimizeStringConcat -XX:+UseAdaptiveGCBoundary -XX:G1HeapRegionSize=32M -jar forge-1.12.2-14.23.5.2855.jar nogui
  • Edit the server.properties files per the README_SERVER_INSALLATION.txt file. As of this writing, ensure your server.properties has the following lines somewhere in it:
difficulty=3
level-type=BIOMESOP
enable-command-block=true
allow-flight=true
  1. Re-zip your files. Name the zip file something like greedy.zip. The file structure in this zip should mirror the one you downloaded.
  2. Copy this zip file wherever you intend your server files to be. For example /var/docker/greedycraft
  3. Edit your docker-compose.yml file and add your configurations. For example, if using 20GB of memory and a data directory of /var/docker/greedycraft and a customized server zip file at /var/docker/greedycraft/greedy.zip a docker-compose.yml file would look something like (Customize memory and such as needed!):
version: "3"
services:
  greedycraft:
    image: itzg/minecraft-server:java8
    container_name: greedycraft
    ports:
      - "25565:25565"
    restart: unless-stopped
    environment:
      EULA: "TRUE"
      SNOOPER_ENABLED: "FALSE"
      MAX_MEMORY: "20G"
      ENABLE_ROLLING_LOGS: "TRUE"
      ENABLE_AUTOPAUSE: "FALSE"
      OVERRIDE_SERVER_PROPERTIES: "TRUE"
      MAX_TICK_TIME: "-1"
      MAX_PLAYERS: "32"
      TYPE: "CURSEFORGE"
      CF_SERVER_MOD: "greedy.zip"
      VERSION: "1.12.2"
    volumes:
      - "/var/docker/greedycraft:/data"
    networks:
      - external

networks:
  external:
  1. If all is well, you should be able to start your server by reloading your compose file by running docker-compose up -d from the same directory as your docker-compose.yml file.
  2. Monitor your server with docker logs greedycraft assuming you named the container greedycraft like in the example above. If you see repeating logs and docker container ls -a shows your container either restarting or with a short uptime, you may have an issue. Stop the container and review the logs to troubleshoot. If you see Stopping aura thread for dim xxx however, then you should be good to go! (Assuming no firewall issues and port-forwarding was setup correctly if running across networks, but those are outside the scope of this quick-guide.)

MIM Portal Patch Fails

Just a quick post. I ran into an issue updating the MIM Portal. Looking at logs, I found a line reading that a step had failed. The step that failed was just a quick command line run of net start fimservice. Odd step to fail on right?

After running the updater a few times I figured out the issue. The service just was not starting within the 5 second or so time limit of the net start command. Net start returned a non-zero return code and the fim portal service updater treated that as a failure.

The fix is pretty easy though. That net start command spawns in a new cmd prompt window. When you see it, just highlight a character inside the cmd prompt window and that will freeze the command. Check to ensure the fimservice service is started, then press the “enter” key while in cmd prompt to allow it to continue. Net start will see the service is running and return zero to the updater and the updater will happily finish up. Just keep in mind, you have to watch out for that cmd prompt, you only have about a 5 second window to catch and pause it!

Event Forwarding and Server Core

I setup Windows Event Forwarding on several servers to log to a Sever Core Event Collector server. I got the GPO setup and all. Since the collector is Core and has no option to open Event Viewer, I opened mmc.exe locally, and attached Event Viewer to remotely manage the Core server subscriptions. Once I was done, I tested it all and… nothing. The event source machines were throwing:

The forwarder is having a problem communicating with subscription manager at address http://collectingserver:5985/wsman/SubscriptionManager/WEC. Error code is 2150859027 and Error Message is The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol.

Turns out, the Subscriptions section of Event Viewer never manages the remote computer even if you selected a remote computer when attaching the snap-in.

What finally clued me in, is I checked the collector build with PowerShell against the remote core server, and nothing popped up. The whole time I thought I was managing the core server, I had instead been setting up the collector on my own machine. So yeah, either use a local instance of the Event Viewer snap-in or wecutil.

Create SCCM Script Detection in PowerShell

This is mostly a post about me being dumb.

When you create an application in PowerShell for SCCM, you usually create detection methods with New-CMDetectionClause* cmdlets like New-CMDetectionClauseFile. So I was expecting there to be a matching New-CMDetectionClauseScript or something like that. But that does not exist. Googling this hardly helped as I kept getting results on how to use PowerShell detection methods, not how to create them from within PowerShell.

Turns out, the script detection method is baked into the Add-CM*Deployment methods. Such as:

$DetectionScript = @"
if ($SomeCondition -eq $true) {
	Write-Host "Installed"
}
exit 0
"@

Add-CMScriptDeploymentType -DeploymentTypeName "SomeDT" -InstallCommand "Setup.bat" -ApplicationName "MyApp" -ScriptText $DetectionScript -ScriptLanguage PowerShell -ContentLocation "\\SomeServer\SomeShare\PackageSource"

It’s in the documentation… I just never considered it could be part of the DeploymentType function and not it’s own DetectionClause function like the other types. It makes sense, don’t get me wrong… It lines up with the form in the admin console when manually creating the script-based detection method. I just did not think of it…

Since I am making a post on this, definitely check out the documentation on how SCCM uses the detection script output: https://learn.microsoft.com/en-us/previous-versions/system-center/system-center-2012-R2/gg682159(v=technet.10)#to-use-a-custom-script-to-determine-the-presence-of-a-deployment-type

MSRA issue after RC4 was disabled

We ran into an issue with Microsoft Remote Assistance (MSRA) after disabling RC4 encryption support. I was having a hell of a time troubleshooting the issue and eventually resorted to WireShark for troubleshooting.

WireShark for the MSRA traffic showed that the Encryption type used for MSRA is AES as it should be. No problem there. Then I looked at the kerberos traffic specifically and seen alternating KRB5KCD_ERR_S_PRINCIPAL_UNKNOWN and KDC_ERR-ETYPE-NOSUPP. So the issue was not MSRA but kerberos.

Diving further I found that the TGS-REQ packet in WireShark showed the principal target was not the machine as I expected, but instead, the end-user. So, fun fact there, when you MSRA to a machine, your kerberos ticket is generated for the end-user, not for the machine account. We checked the “This account supports AES” check boxes in AD for the target user, and still the issue occurred.

I checked the logs on the domain controller and came across one in the Kerberos-Key-Distribution-Center category. It was a KDCEVENT_NO_KEY_INTERSECTION_TGS which stated “While processing a TGS request for the target server, the account did not have a suitable key for generating a kerberos ticket (the missing key has an ID of #). The requested etypes were # 23 #. The accounts available etypes were 23. Changing or resetting the password of will generate a proper key.” This pretty much explicitly stated the fix.

While we had matching supported encryption methods, the target user had to change their password for the AES support to kick in! So, if you disable RC4 support, ensure your user accounts have the AES check boxes set, and then make sure they change their passwords shortly after, or at least before you need to use MSRA to assist them.

Old SCUP update hanging around

We had some users complaining about old Adobe Reader updates not installing from WSUS. The issue was inconvenient, but as soon as SCCM pushed more recent Adobe updates to the user, the issue went away. We decided to expire these old updates and remove them, however there was an issue. Whenever we attempted to publish the update as expired from SCUP, we got Verification of file signature failed for file: <Some cab file path here>. I had issues like this before and tried to remove it using PowerShell/.Net instead. I have had to do this before when we lost our SCUP database file. My go-to code for that is:

#This code largely from https://myitforum.com/how-to-expire-a-custom-update-in-wsus-using-powershell/
#Run this from WSUS for central site server
#Load .NET assembly
[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
#Connect to WSUS server
$wsusrv = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer()
#Get all the non-microsoft updates 
$otherupdates = $wsusrv.GetUpdates() | select * | ? {$_.UpdateSource -ne "MicrosoftUpdate"}
#$wsusrv.GetUpdate($_.id)}} #Get more info on a specific update
$otherupdates | where-object { <#$_.id -eq "" -or #> $_.title -like "*adobe*"} | foreach-object {$wsusrv.ExpirePackage($_.id)}

This still did not work however, the script returned the exact same error as when the update is expired using SCUP. It turns out, the SCUP certificate that signed these cab files had expired about a month prior to this issue. In a last ditch effort, we were able to expire these updates by rolling the server time back to a time when the certificate was still valid. We were then able to re-publish the updates as expired from SCUP and the issue was resolved.

Grand Unified Check Summary – HTML PowerShell Report

I have played around with the idea of making a single-file HTML report easily exportable from PowerShell before. A couple of these used to be hosted in the old version of this blog. We recently had to rebuild a report at my office and I decided it would be a good time to make another go at an HTML reporting framework. This time, something more generalized and customizable.

The end result this time is a framework which will take an HTML template one or more CSS templates, images, custom outputs from scripts, and combine these resources together into a single-file report that could be sent out without any dependency files. The idea behind the separate template elements is to keep the report structure, design, and the scripts relatively separate preventing a massive monolithic monstrosity. If you need to add a new item to the report, say cpu utilization or some other metric, you could just add a new child script. If you need to adjust the colors used in the report, but not the contents itself, you can just edit the CSS file master template or if you need to adjust the structure of the report, you could do so, without ever having to touch the PowerShell scripts responsible for gathering the information being reported.

The main script looks at custom tags in the template itself to fill in the final report with the necessary information from child scripts. If this sounds like something that could be useful, checkout the project on Github.

Additional Adobe Update Server Issues

We ran into additional issues with our Adobe Update Server. The issue was that clients were not using the internal Adobe Update server despite having the override files pointing them to the internal Adobe Update Server. WireShark showed that clients with the override file would connect to the server, download a single file, and then continue any further update attempts utilizing Adobe’s servers. Turns out, in our case, there were some additional URLs being blocked that prevented a complete Adobe Update Server setup. I have no clue which ones, however, if you have this issue, ensure your update server can reach the URLs/domains contained in Adobe’s endpoint documentation.

Going through this process I learned a few troubleshooting/configuration tricks from the client’s side. In no particular order, here are some notes:

  • Try the Remote Update Manager (RUM) locally on the client. It can usually be found at “C:\Program Files (x86)\Common Files\Adobe\OOBE_Enterprise”. If it fails to download from your update server, it should return an error in the console that may point you in the correct direction.
  • Ensure you check the client’s “%TEMP%\CreativeCloud\ACC\ACC.log” and “%TEMP%\CreativeCloud\ACC\AdobeDownload\DLM.log” log files.
  • Turn on directory browsing in IIS (If using IIS to host the update files) and ensure that you can download each type of file from your updates url.
  • Override files must go “C:\Program Files (x86)\Common Files\Adobe\UpdaterResources” and “C:\ProgramData\Adobe\AAMUpdater\1.0”. One of those directories does not exist by default, create it.
  • You can enable the Apps tab for clients in the “C:\Program Files (x86)\Common Files\Adobe\OOBE\Configs\ServiceConfig.xml” file.

Adobe Update Server Sync Issues

I was setting up an Adobe Update Server using the Adobe Update Server Setup Tool, and it was just not working. It kept failing with error codes 2 and 4 in the console. I was pretty sure that it was our proxy that was causing the grief.

I opened procmon and monitored the AUSST tool, I found that it was not even attempting to use the proxy. I checked the C:\Users\<user>\AppData\Local\Temp\AdobeUpdaterServerSetupTool.log but only found what the console was telling me. General network issues. In procmon however, I seen it was writing to a C:\Users\<user>\AppData\Local\Temp\CreativeCloud\ACC\AdobeDownload\DLM.log. The console does not tell you about it however. I opened that one up and got a little further, though not much. It did give a better error then just network issues though. This time it gave me “failed to resolve the proxy setting on the machine” along with error 12180. If you look up 12180, it largely repeats the last error, just that the proxy settings failed. Finally out of desperation I was changing the proxy settings manually and found that, if “Auto Detect” was checked in your proxy settings, then AUSST would just give up proxy, whether you have a pac file, or manually entered proxy settings or not.

I immediately ran into another issue. This one was a bit easier to troubleshoot. It was still failing to download files, but at least it actually made connections. In AdobeUpdaterServerSetupTool.log I seen “Failed to download icons”, “Failed to complete migration” and “Internal error occurred”. Now that I knew about the DLM.log, I checked that too. That was spitting out error 12175. This was again more helpful than the AdobeUpdateServerSetupTool.log’s output. If you look that error up, it roughly translates to SSL error occurred. I popped open WireShark and decided to see if I could find any handshake errors or anything else. I did not, but I did find the URL of the file that the machine was attempting to contact. I put that URL directly into Internet Explorer and immediately was met with a SSL trust error. The Root certificate for Adobe was not installed on the machine. I imported the cert and tool started working after that.

TLDR;

If you get general network type errors in AdobeUpdaterServerSetupTool.log and error 12180/”failed to resolve the proxy setting on the machine” in the DLM.log, uncheck “Auto Detect” in your proxy settings

If you get http security/12175 in DLM.log and possibly “Failed to download icons”, “Failed to complete migration” and “Internal error occurred” in AdobeUpdaterServerSetupTool.log, ensure you don’t have any issues trusting Adobe’s cert chain used on their update server.

Update: I had an additional issue with our update server. You can read it and some general client-side troubleshooting steps in this post.

Managing Adobe CC Users from PowerShell

I wanted to automate our user management of Adobe Creative Cloud. This requires interfacing with Adobe’s user management API. One of the coolest functions I created in this initiative allows you to synchronize an adobe group based on an Active Directory group. I intend to use this AD Group for AppLocker, SCCM deployments, and syncing to Adobe Creative Cloud. This should largely automate the entire Creative Cloud deployment and reduce administrative overhead. The end result will be a single administrative user adds someone to the “Approved CC Users” group, and everything else is hands free.

See the GitHub repo for the PowerShell script and additional information and resources.