The tool is a derivate from Collection Commander, a Configuration Manager addon to manage On-Premise Clients/Servers over PowerShell remoting. But the architecture of DevCDR is fundamental different. With DevCDR, the DevCDR-Agent will open a secure channel to the backend service (Port 443) which is using the existing connection to interact with the DevCDR-Agent.
The technology behind is SignalR as it supports real-time communication over Web-Sockets. There is no database on the backend involved because the devices will send their status in realtime as soon as they have a connection to the server.
The Web-Frontend is also using SignalR to automatically refresh if there is feedback from a device. You can trigger activities against one or mutiple clients with a simple right click and you will see the results of your command in real-time!! There are many predefined commands available or you can just paste and run any PowerShell scripts you want. The PowerShell script will be sendt to the agent and executed under the SYSTEM context of the device.
Devices can be assigned to groups to keep the overview in the console. Or you can host multiple Instances of DevCDR on the same server to segregate access to the devices.
DevCDR integrates with RuckZuck.tools, so you can assign any software from the RuckZuck repository to your devices with a few clicks and you will get the status of the installation in real-time. The DevCDR-Agent contains the RuckZuck binaries, so there is no need to install any RuckZuck-Tools nor the OneGet Provider for Ruckzuck.
Other Software Package Managers or repositories like chocolatey.org, can be accessed by using custom PowerShell commands.
The OperatingSystem Version on the Main-Table includes the minor-Revision (4th part of the OS Version), wich represents the Patch-Level of the Operating System. This number gives a quick overview of the current patch state.
To query or install software updates, DevCDR is using the PSWindowsUpdate module from PSGallery. As the detection and installation of WindowsUpdate may take some time, these commands are running asynchronous. This allows to trigger other activities while a scan or update is installing.
Note: The PSWindowsUpdate will be installed automatically on first Scan or Update-Installation
DevCDR is using the PowerShell scripts from my previous Blog to detect, install or upgrade Windows-Drivers from the Microsoft Driver-Catalog. These commands are running asynchronous as it may take some time to detect or install drivers.
In the near future, DevCDR will integrate JainDB to store inventory data. JainDB will do the data deduplication and archiving and it provides a REST-API for reporting with Excel or Power BI.
There is a read-only Demo Instance available devcdr.azurewebsites.net where the context menu can be opened, but you will not be able to trigger any activities. Send me a mail to get access to an unlimited instance for testing…
Or watch the following demo video:
DevCDR is an OpenSource Project and not a commercial sollution with warranty and support. The targed audience of this project are Developers and System-Integrators. System-Integrators for example can extend and offer DevCDR as a service for their customers (by following the GNU GPL License Rule).
The Tool itself is designed to be used from IT-Pros with PowerShell knowledge.
SignalR is capable to handle thousands of concurrent connections (SignalR Performance). But the architecture of the Web-Frontend will become a bottleneck in large environments as it loads all data from all devices (within the instance) to the browser. All the filtering and grouping is running within the browser and not on the Server! For large ammounts of devices, the architecture must be changed or the devices must be separated and assigned to different instances of DevCDR.
There is no max. recommended number of devices DevCDR can handle. The biggest number I had for testing was 200 active devices... but let me know if you have seen more.
Every managed device needs to install a service. For x64 Windows Operating Systems there is a Windows-Installer package that can be installed with the following command (as Admin):
msiexec -i https://devcdr.azurewebsites.net/DevCDRAgent.msi INSTANCE=default /qn REBOOT=REALLYSUPPRESS. A package for X86 may follow or you can copy the executable and .config File to a X86 Windows Device and install the service by using the command:
Note: The property INSTANCE must reflect an existing Instance-Name on the Server
The Agent Requires .NET 4.6 and PowerShell V4.0 or higher.
DevCDR Server is a Web-Application that can be hosted on any IIS Server (also On-Premise if you want) with .NET 4.7 installed.
In Azure, you can use a simple "Web App" running on a Free (F1) ServicePlan or better. Just verify that "Web sockets" are enabled in the "Application settings":
To publish DevCDR on a self hosted Server, I recommend to upload (publish) the contet from VisualStudio directly as there are some Tasks to do:
- In VS2017 update "Authentication with Azure Active Directory" under "Connected Services", with your Azure AD Domain, Client ID and Redirect URL.
- The Default Page "Demo" does point to a non-existing instance (xLab). You will never see any device on the Demo-Page. But as the Demo page does not require authentication it's recommendet to keep the page, just update the content of the page by editing
Views\DevCDR\Demo.cshtmland make a nice startup screen.
- The available Instance is named "Default" and requieres Authentication. If you want to grant specific Users or Groups (requires at least Azure Active Directory "Basic") you have to change the
Controllers\DevCDRControll.cs. As soon as authentication is working, you will see the Default instance as on option on the Main Menu.
- To edit activities in the context menu, edit
Views\Shared\_ContextMenu.cshtml. Feel free to share your context menu extensions on github.com/rzander/DevCDR.
Please provide feedback on github.com/rzander/DevCDR. It does not matter if you report a bug or just some thoughts…