About Thomas.Marcussen

Technology Architect & Evangelist, Microsoft Trainer and Everything System Center Professional with a passion for Technology

Anet A8 Plus upgrade to Marlin 2.0.x

I really wanted to upgrade my Anet A8 Plus with a bed leveling sensor, unfortunately I was not able to find the source code for the firmware stock firmware used.

UPDATED: Some is now available here: ANET 3D Firmware

  1. Download and install the latest Arduino IDE
    1. NOTE: I used 1.8.10, You can always download an older version, if needed.
  2. Download the Anet A8 board definition
  3. Extract the Anet A8 board definition
  4. From the extracted Anet A8 board definition copy the Arduino\Hardware folder to the Arduino installed location (Default: C:\Program Files (x86)\Arduino)
  5. Download the latest Marlin 2.x.x firmware
  6. Extract the Marlin firmware
  7. From the extracted Marlin firmware copy \Config\Examples\Anet\A8plus to the \Marlin\ folder (same location as Marlin.ino)
  8. Connect USB to your Anet motherboard
  9. Open the installed Arduino IDE
  10. Download and Install u8glib by oliver
    1. Click Sketch -> Include Library, Click Manage libraries
    2. Search U8glib – MAKE SURE TO SELECT TO CORRECT ONE! – U8Glib by oliver,
    3. Click Install
    4. Click Close
  11. Click Tools -> Board, Select Anet 1.0 (Optiboot)
    1. NOTE: Small and Fast Bootloader for Arduino and other Atmel AVR chips
  12. Click Port, Select the assigned COM port
    1. NOTE: If you want to check if your connected, Click Tools -> Get Board info. This will return information about the board, if your connected.
  13. Find the line in the Configuration.h: #define ANET_FULL_GRAPHICS_LCD
  14. comment it out like this: //#define ANET_FULL_GRAPHICS_LCD
  15. Find the line: //#define CR10_STOCKDISPLAY
  16. Uncomment it like this: #define CR10_STOCKDISPLAY
  17. Find the line: #define ENDSTOP_INTERRUPTS_FEATURE
  18. comment like this: //#define ENDSTOP_INTERRUPTS_FEATURE
    1. NOTE: The update and consolidation of TMC support into the TMCStepper the library has made the ENDSTOP_INTERRUPTS feature incompatible with TMC drivers, until a workaround can be found.
  19. Now you’re ready to upload the firmware, or add/remove features needed

The Anet V.1.7 board comes with a limited flash ROM (128k – 131,072 and thats including the bootloader). This will not all you to pick all features and add them.

Should you by accident (like me) put a too large firmware or corrupt the bootloader, you will need a USBasp and a 10-to-6 poled adapter.

NOTE:
If You see the following error, flash the bootloader using USBAsp, your sketch is properly too big.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x60

I recommend you to review and edit you own configuration files, but for sample purposes here are mine: [download id=”931″]


MSiX Insider Preview Build 1.2019.522.0

First insider preview release for the upcoming public release in July.

New Features:

  • Support for desktop installers that require restart – read more
    • Auto-login option for restart
  • New options in app settings
    • Specify a default cert to sign packages with
    • Specify exit codes for installers that require restart


Known “bugs/features”

  • Negative reboot exit codes are currently not supported
  • If Default cert is specified, you still need to select to sign your package
  • During remote or VM restarts, there might be an extra login prompt
  • Restore defaults button doesn’t remove certificate password or installer exit codes
  • There are some UI incongruencies

You can find the full history of MSIX Packaging Tool release notes here.


List Packages that run in user context (Run with user’s rights)

Introduction

After last weeks post with the script sample to list Packages that run in user context, there where some good feedback from people still using packages, and requiring a list of packages that install within the user context (Run with user’s rights / Execution mode as user)

It seemed that many was still using Packages, either as a result of legacy migration or to avoid some application re-packaging.

So here is the followup post, with a new script to list all packages and package with programs that run in user context.

From my point of view, its still the same; Using PSADT pretty much any package can be converted to be installed as system, and the needed stuff (registry keys, files etc) in the user context can be added in a structured and controlled way.

I do still come across some applications that i would prefer to have in MSI with all settings etc added, at least for simplicity, for those packages I still prefer to use Advanced Installer.
When talking Advanced Installer, they also have a great support for MSIX, that makes to process so much easier and cost efficient.

This script will list all packages with programs, that is configured to install as user (within the user context)

All you need to do is configure the path to your import module and set the site code.

A file will be created in “C:\TEMP\Packages_and_Programs_Run_Mode_List.csv” with the following format:

“Package Name”,”Package ID”,”Program Name”,”Run with USER’s right”
“My Application”,”BB10001D”,”execute”,”TRUE

With the example above we have a package ‘My Application’ that has a run mode configured: Run with user’s rights

Properties on the program, where the program run enviroment is configured to Run with Users’s rights


Download the script from TechNet Galleryhttps://gallery.technet.microsoft.com/Generate-a-list-of-d8778d4c?redir=0



List Applications that run in user context (Install for User)

Introduction

When deploying applications sometimes they are created to install within the active users context.
This means that the actual installation requires the users to have the needed permissions to the filesystem, registry and etc.
In some cases local administrative rights are needed to perform the application installation, this is not a good practice.

As applications mature for the modern design of the Windows Operating System or we choose to remove the users administrative rights due to security reasons, we may need to list and change the behavior of existing Applications.

This script was created to list applications that is configured to run with Installation behavior: Install for User

The actual output will end up in the export csv file

Script Download [download id=”893″]



Today with the modern management tools and applications, the users should not have local administrative rights on a permanent basis.
Most, if not all applications can be repackaged to deploy without the need for administrative rights.



Useful links:

PowerShell Application Deployment Toolkit: https://psappdeploytoolkit.com
Advanced Installer: https://www.advancedinstaller.com/
Access Director Enterprise: https://ctglobalservices.com/access-director-enterprise/



MSiX Insider Preview Build 1.2019.402.0

Yet another release of the MSIX Packaging tool (1904) is nearing general public release.

Here is the list of features and fixes

  1. Ability to convert on a remote machine.
    1. We talked about that earlier here
  2. Improved management experience in package editor.
    1. Auto versioning recommendations when saving in package editor.
    2. Now supports existing folder addition to package in VFS.
  3. User can specify known valid exit codes for CLI conversions.
  4. Added the ability to time stamp your signed package in all of the workflows where signing is currently available.
    1. You can specify your default time stamp URL and type of time stamp server in the tool Settings page.
  5. Updated AppID generation logic, and added additional validation fro package name and app.
  6. Bug fixes and performance improvements

The detailed history for the app release can be found here


Cleaning up shortcuts

So the issue at hand;
I was replacing a Office application on Windows systems, where i noticed that shortcuts created by the users, was not upgraded/removed when the new office version was installed.

The issue seems to be related to users creating custom shortcuts, directly to exe files.
I some cases the shortcut name was clear, but in other cases the users had chosen something they found fit.

The following PowerShell script was created to remove shortcuts (lnk files) based on the executable. This means you can specific the exe or use a wildcard if there is multiple executable files releated to an application.

$ShortcutLocations = Get-ChildItem -Recurse (“C:\Users”,”C:\ProgramData\Microsoft\Windows\Start Menu”) -Include *.lnk -Force -ErrorAction SilentlyContinue

########
# This script searches for all *.lnk files to "C:\Program files (x86)\App\My Application.exe" or "C:\Program Files\App\My Application.exe"
# It searches in C:\users\* profiles paths, including Users Desktops, %AppData%\Microsoft\Internet Explorer\Quick Launch and in ProgramData...StartMenu
# The name of the link file can have many different names, therefore we must find each shortcut based on path to target exectuable and not on lnk name.
# Then the lnk file must be deleted.
#
# The script should be run with admin rights, otherwise shortcuts will only be deleted for the user running the script.
########

### Specify shortcut's target executable here.
$AppExecutable = "C:\Program files*\Microsoft Office\Office15\*.exe"
# * Due to mask it contains "Program files" and "Program files (x86)" paths both.
###

### Paths to browse and search for shortcuts.
$ShortcutLocations = Get-ChildItem -Recurse ("C:\Users","C:\ProgramData\Microsoft\Windows\Start Menu") -Include *.lnk -Force -ErrorAction SilentlyContinue
# * -Recurse = Includes all subdirectories.
###


### Get properties for shortcuts in the locations

Function Get-ShortcutsProperties {
$Shell = New-Object -ComObject WScript.Shell 
Foreach ($Shortcut in $ShortcutLocations)
{
$Properties = @{
ShortcutName = $Shortcut.Name;
ShortcutFullName = $Shortcut.FullName;
ShortcutLocation = $shortcut.DirectoryName
ShortcutTarget = $Shell.CreateShortcut($Shortcut).targetpath
}
New-Object PSObject -Property $Properties
}
[Runtime.InteropServices.Marshal]::ReleaseComObject($Shell) | Out-Null
}
###

$ShortcutsList = Get-ShortcutsProperties

### Compare shortcut's target path with $AppExecutable and delete it in case of corresponding one
Foreach ($item in $ShortcutsList) {

if ($item.ShortcutTarget -like $AppExecutable) {

Remove-Item -Path $item.ShortcutFullName -Force -ErrorAction SilentlyContinue
 }
}
######## End of the script

Download the PowersShell Script here: [download id=”877″]

MSiX – Remote machine conversions

The MSiX Packaging Tool (1.2019.226.0) Preview now has the ability to connect to a remote machine, where you can run the conversion.
This is great news, and solves the normal issue with contamination on “non-sanitised” machines.

I have always preferred to do my packaging and re-packaging on Hyper-V Virtual Machines
This gives a total control and clean enviroment, with easy ability to get back to a controlled point of reference, using checkpoints.

Getting started with remote machine conversions? Fear not! It is quite simple to get started.

– PowerShell remoting must be enabled for secure access to the remote machine.
– You must be logged on with administrative privileges on the machine.

To enable PowersShell remoting on the machine, run the following command in an elevated PowerShell prompt: Enable-PSRemoting -Force -SkipNetworkProfileCheck

If network/firewall restrictions are in place, remember to allow inbound traffic on port 1599 (MSiX Packaging Tool default port, it can be changed with the settings tab)

If you are connecting using a non-domain joined machine, you must use a certificate to connect over https.
To enable PowerShell remoting and allowing WinRM over https run the following commands in an elevated PowerShell prompt

Enable-PSRemoting -Force -SkipNetworkProfileCheck

New-NetFirewallRule -Name "Allow WinRM HTTPS" -DisplayName "WinRM HTTPS" -Enabled True -Profile Any -Action Allow -Direction Inbound -LocalPort 5986 -Protocol TCP

To generate a self-signed certificate, configure WinRM secure configuration and export the certificate, you can run this script: (or download: [download id=”863″])

$thumbprint = (New-SelfSignedCertificate -DnsName $env:COMPUTERNAME -CertStoreLocation Cert:\LocalMachine\My -KeyExportPolicy NonExportable).Thumbprint
$command = "winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname=""$env:computername"";CertificateThumbprint=""$thumbprint""}"
cmd.exe /C $command
Export-Certificate -Cert Cert:\LocalMachine\My\$thumbprint -FilePath <path_to_cer_file>

On your locale Machine, copy the exported certificate and install it into the Trusted Root Store.
It can be imported with the following command: Import-Certificate -FilePath <path> -CertStoreLocation Cert:\LocalMachine\Root





Configuration Manager 1810 Installation – Prerequisite Check – SQL Server Native Client Version

I came across this error while adopting the Configuration Manager 1810 (Early Update Ring)

[Completed with warning]:Verifies that the version of Microsoft SQL Server Native Client installed on the site server meets the minimum requirements to enable TLS 1.2 support. https://go.microsoft.com/fwlink/?linkid=2026746

I was apparently running an older SQL Native client version, that did not support TLS 1.2 which is required for ConfigMgr 1810.
Review your SQL versions and update to a version that supports TLS 1.2:

This link provides information about the updates that Microsoft is releasing to enable TLS 1.2 support for SQL Server 2017 on Windows, SQL Server 2016, SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, and SQL Server 2014. This article also lists supported client providers.

Download and install the correct update for your existing SQL version.
Reboot and proceed with the 1810 update.

If your looking for the ConfigMgr 1810 package to enable early update ring follow this link

The package adds your hierarchy or standalone primary to the early update ring for Update 1810 for the current branch of System Center Configuration Manager. The package is signed and bundled inside a signed self-extracting executable.

Note: The 1810 update is only applicable to 1710 and higher versions of System Center Configuration Manager

Windows 10 Registry tweak to disable Microsoft Edge Icon for MDT or ConfigMgr

The icon for Microsoft Edge is now placed by default in every user profile.
It is not placed in Public Desktop, but created for each user at logon (DOH!)

Thank god there is way to stop this behavior.

You can simple add the following registry key:
Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer
Value: DisableEdgeDesktopShortcutCreation
Data: 1
Type: REG_DWORD

If your using MDT (Microsoft Deployment Toolkit) or ConfigMgr (System Center Configuration Manager)
You can add the following oneliner task sequence step, to stop the creation of the Microsoft Edge icon.
Commandline: reg.exe add HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer /v DisableEdgeDesktopShortcutCreation /t REG_DWORD /d 1

In case your wondering what i have in the steps to disable Cortana, let me share them:

Registry tweaks for Build and Capture or Windows 10 Deployment task sequences

Disable Cortana Voice:
reg.exe add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE /v DisableVoice /t REG_DWORD /d 1

Disable Cortana Search:
reg add “HKLM\SOFTWARE\Policies\Microsoft\Windows\Windows Search” /v “AllowCortana” /t REG_DWORD /d 0 /f

Disable Cortana Search Box:
reg add “HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Search” /v “SearchboxTaskbarMode” /t REG_DWORD /d 0 /f