Part 6 is now live get on it!
As part of my Hypercube Evolution 3D Printer build I had to re-assign the E1 stepper as the second Z motor and the E1 heater cartridge output as the part cooling fan. Here is how I did it!
Re-assigning the E1 stepper output
After downloading the Marlin firmware from github (here) and you open the “Marlin.INO”file in the Arduino IDE. Navigate to the Configuration_adv.H file and look for the below lines. By default the “define Z_DUAL_STEPPER_DRIVERS” line has a // in front of it. All you need to do is remove these 2 forward slashes. That’s it!
// A single Z stepper driver is usually used to drive 2 stepper motors.
// Uncomment this option to use a separate stepper driver for each Z axis motor.
// The next unused E driver will be assigned to the second Z stepper.
#define EXTRUDERS 1
Re-assigning the E1 heater output
After downloading the Marlin firmware from github (here) and you open the “Marlin.INO” file in the Arduino IDE. Navigate to the Configuration_adv.H file and look for the below lines. All you need to change “define E0_AUTO_FAN_PIN -1” to “define E0_AUTO_FAN_PIN 7” you can also adjust the automatic fan switch on set point by changing the number on the line “define EXTRUDER_AUTO_FAN_TEMPERATURE 50”. Remember though these temperatures are in Celsius!
// @section extruder
Extruder cooling fans
Extruder auto fans automatically turn on when their extruders'
temperatures go above EXTRUDER_AUTO_FAN_TEMPERATURE.
Your board's pins file specifies the recommended pins. Override those here
or set to -1 to disable completely.
Multiple extruders can be assigned to the same pin in which case
the fan will turn on when any selected extruder is above the threshold.
define E0_AUTO_FAN_PIN 7
define E1_AUTO_FAN_PIN -1
define E2_AUTO_FAN_PIN -1
define E3_AUTO_FAN_PIN -1
define E4_AUTO_FAN_PIN -1
define CHAMBER_AUTO_FAN_PIN -1
define EXTRUDER_AUTO_FAN_TEMPERATURE 50
define EXTRUDER_AUTO_FAN_SPEED 255 // == full speed
There appears to be a weird issue where in the April 2018 release of Windows 10 group policy fails to refresh the user part of the group policy. Instead you get the message below
Computer Policy update has completed successfully.
User Policy could not be updated successfully. The following errors were encountered:
The processing of Group Policy failed. Windows could not determine if the user and computer accounts are in the same forest. Ensure the user domain name matches the name of a trusted domain that resides in the same forest as the computer account.
To diagnose the failure, review the event log or run GPRESULT /H GPReport.html from the command line to access information about Group Policy results.
This is caused by the netlogon service not running (and being set to manual?!). To resolve the issue you need to do the following:
- Press Win + R on the keyboard to open the run window
- Type in services.msc and click run
- Scroll down and look for Netlogon, if the status is not Running, then that’s why you’re getting this issue
- Double-Click on Netlogon and change the Startup Type to Automatic and click the Start button
- Once the service is running, click the OK button
- Now try running gpupdate again
If you have a large number of computers running Windows 10 and want to fix them all you can make this change using group policy. To do so carry out the following in an appropriate Policy object
- Start Group Policy Management on a Domain controller
- Select the appropriate group policy
- Select Computer Configuration > Preferences > Windows Settings > Services
- Add a new service and use the following settings
- Startup: Automatic
- Service Name: Netlogon (you can pick from the list)
- Service Action: Start Service
- You can also set the service to restart on failure by going to the Recovery tab
- Click OK
All going well this should resolve the group policy issue. If this helped you please let me know!
Every now and then you come across a situation where you just need a computer to log in and start an application without user intervention. While it is not ideal from a security point of view sometimes it is a necessity. On a non domain joined computer you are able to use the netplwiz command to setup an automated login. However on a domain joined computer this option does not exist. To do the same on a domain joined computer you need to use the regedit as administrator. Once open you need to browse down to the follow location “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon“.
From here there is 4 entries you need to change to suite your needs.
- AutoAdminLogin – Needs to be set to 1 to enable auto login
- DefaultDomain – Needs to be set to the domain you are logging into (either PC name or AD name)
- DefaultUserName – Needs to be set to the user that you want to autologin
- DefaultPassword – Needs to be set to the password of that user account. Be aware that this is kept in plain text and can be looked up by any user with access to the registry! If this registry entry is not there you need to add it. (This is just a string registry item.)
After this you can restart the computer and if it is all configured correctly it will login with the user that was specified. You can disable the auto login also by changing the AutoAdminLogin to 0
I have had a issue that has been plaguing me the last few days where I was unable to update the printer drivers on a shared printer. With the error message “Printer settings could not be saved. This operation is not supported.” After a bunch of searching I found that if you unable to change the printer drivers on a Windows Server 2012/R2 Server you need to first untick the share option on the printer. The change the drivers for the printer. After which you can re-share the printer on the network / directory.
Kudo’s go to https://flamingkeys.com as they had the above information on their blog.
Accessing the Distribution List
- Selecting the Home tab and click on the Address Book
Fig 1. The Home tab
Fig 2. The Address Book option on the Home tab
- In the Search section enter the display name of your distribution list. E.g. QualityCommittee
Fig 3. The Search field in the Global Address List (GAL)
- Double click on the distribution list or right click and the select Properties. The details of the central distribution list will be displayed in a new window.
Fig 3. Example of a central distribution list and location of the Modify Members button
- Click on the Modify Members… button
Adding Members to the Distribution List
- Click Add… and then search for the name or user ID of the person you want to add.
- Once you have found the person you want to add either double click on their name or highlight the name and click Add.
- Once you have the people in your list that you want to add click the OK button.
- You should then see them on the list. Click OK.
- Click OK again to close the properties window.
Removing Members from the Distribution List
- Search through the list for the person you want to remove. Highlight their name.
- Click on the Remove button.
I recently installed a batch of updates across all the servers I manage. Everything went smoothly throughout the download, installation and restarting of all the servers bar 1. This particular server was unable to make it past ‘Updating your system 12%’. I tried a number of different tricks such as disabling driver signing and safe mode to no avail.
After some searching through copious forums and articled I found the solution to my problem. First I needed to boot into the startup menu by resetting the VM a number of times. Then I selected the option to open the command prompt. Then all that was required was to enter a DISM command to roll the system image back to before the updates were installed.
The command that was run to do so is as follows.
dism.exe /image:C:\ /cleanup-image /revertpendingactions
After this the server restarted and everything was all working.
We all have one of those old servers sitting quietly humming away in the rack. That everyone knows needs to be replaced but no one wants to touch because it does that really important business function X or stores all the data for app Y that just can’t go down. Then one day something happens to that server and *poof* that server is no more or you get a scare when the RAID card or some other part decides to give up the go.
Recently I found myself in the first scenario where the good all SBS server that’s been quietly humming away decided to have a system board failure on a Sunday morning. Thankfully the tech hoarder that I am I had another server of the same model sitting at home propping up the ol’ nerf gun. What I did know but didn’t want to think about was that this old server I had spare was also just as old as the one that failed. After transferring the drives etc over to the new old server everything looked great and was running without error. However Monday morning at 4am it decided to drop the RAID card and give up. Thankfully I also had a spare one of these (I know so much *stuff*). Thankfully this managed to get the server back to life before the business day started.
At that point I decided I really like my weekends and weekday sleep-ins. After some investigation I had decided that the best thing to do in the short term is to virtualise the server onto some newer more stable hardware. That evening I ran the VMware Standalone converter on the server and just a couple of hours later the server was so I thought happily running away in VMware. The next morning however I awoke to find a number of server failure alerts and a SBS VM that does not want to do anything but sit at the ‘Applying Computer Settings’ screen.
Needless to say the Tuesday at work was not a chill day in the slightest when trying to fire up the physical server it decided that it had done its duty and was not working anymore. Which with the help of some other IT support got us to the conclusion that the VM is the only way forwards. After a number of coffee’s and a fair bit off cussing we found that the reason for the VM freezing and failing to run any services such as exchange was that the old hardware which obviously was no longer connected was still hiding away in the device manager. After removing all the hidden raid cards and chipset devices the VM decided that it is going to work perfectly.
So if you were like me and have a physical server that you have virtualised to VMware and it wont behave take a moment to check out the hidden devices in the device manager. It might just save you a few grey hairs.