StifleR Server 126.96.36.199 and StifleR Agent 2.1.0.
1. This is by no means an in-depth analysis of a best practice upgrade but in this example core function and visualization was maintained through the upgrade.
2. In all cases the Server should be upgraded first. The 2.1 client is not supported on the 2.0 server and will not appear.
3. Upgrade preferably on a whole location at a time basis but at least by whole subnet.
4. The 1.9 client does not send up the Performance and Resource data that can be consumed by the v2.3 server. This limits some of the dashboards during the upgrade.
Before you start
1. Read the installation section of the StifleR
2. Backup and tidy before upgrade.
a. Before running the Uninstall take a backup of the StifleR.Service.exe.config, files just in case you have some custom settings that you may need to refer to later. The contents of the StifleR installation folder are deleted as part of the upgrade so the old StifleR.Service.exe.config file will be deleted.
b. If you are using a custom internal StifleRulez.xml file don’t forget to update this with the latest after you upgrade.
c. Backup and then delete the StifleR Windows Event Log for a fresh start.
d. Backup the %ProgramData%\StifleR Folder which, in a default scenario, will contain any customized GenerateLocations.ps1 and ModifyLocations.ps1 files.
3. Stop the StifleRServer and StifleRBeacon services prior to upgrade.
4. After upgrade, you will need to reconfigure IIS again and remove the Negotiate Provider under Windows Authentication on the StifleR Dashboard website.
5. Cntrl-F5 is your friend when it comes to viewing the Dashboards after the upgrade.
6. StifleR Security Groups remain unchanged in StifleR Server v2.3
1. Simple lab has DP Server and CM server that hosts all StifleR components.
2. Six clients used for testing on two subnets of three clients each.
192.168.2.0 containing clients 2PWS01, 2PWS02 and 2PWS03
is Parent to
192.168.3.0 containing clients 2PWS04, 2PWS05 and 2PWS06
3. A single client on 192.168.4.0 in order to have a second Parent location
4. Default installation performed on all components and basic post installation checks made to confirm everything working as expected
5. Windows Updates and BITS test package both appear in the dashboards
6. Bandwidth control checked to be operating effectively at basic level
7. A Domain group was added to the Administrators group for the Parent subnet. A User with membership of the StifleR Dashboard Access security Group was made a member of this group
Server only upgraded to v2.3
1. The main issue with the Server only having been upgraded is that there are no WMI client objects. The 1.9 client does not send up the information required by the 2.x server to create a client object. Under normal circumstances a client Instance is created in WMI the first time that a client connects. This record is persistent in the DB going forward.
2. You will see Client names listed in some dashboards, Lists and in “Search Clients” results but clicking on these links will direct you to a client information screen without any information in any field. If you try to go via the Search Client result you will firstly get an error.
3. As per the screen shot above, the client search box will only return a single result.
4. What we do have in this partly upgraded scenario is Connection Instances in WMI which do contain information about individual clients, but these Instances are not persistent and are removed when the client disconnects. Connection Class Instances in StifleR show live Instances only.
5. Clicking on the Clients/Clients Overview link from the main menu shows “6 clients online of 0”. This indicates that there are six client connections but 0 can post 2.x content. If you hover over this donut graph you will see “Old clients do not add to the Database, check clients version report!”
NOTE: in order to obtain a list of 188.8.131.52 clients you could run something like the following PowerShell snippet:
PS> Get-WMIObject -NameSpace “root/stifleR” -QUERY “SELECT * FROM Connections WHERE version = ‘184.108.40.206’” | Format-List ComputerName, ClientIPAddress, Version
6. The Read/Blue Leader lists are populated however if you click on an individual Leader client name you will get directed back to the Splash screen
Three clients on 192.168.3.0 (child) network upgraded
1. The upgraded clients can send up data to the Server and therefore Client Instances for these machines will now appear in WMI.
2. Upgraded clients will appear as “Roaming” for up to 15 minutes after installation.
3. The new clients will appear in the Search Clients and if selected will link to a populated Details screen
4. If you click on a 1.9 client in any list, you will receive an empty client info screen.
5. When “2PWS” was entered into the “Search Clients” box you would normally expect all lab clients to be returned (effectively you search for 2PWS*). Instead all three of the 2.0 clients were returned along with only one of the 1.9 clients. It was possible to search for a specific 1.9 client but only one ever appeared in a wild card object search. Maybe other unexpected results in a large environment.
6. The Clients Overview screen will indicate that some clients have been upgraded as follows:
7. Functionality appears fine with subnet/location bandwidth controls functioning as expected
8. There were no errors noted in the dashboards apart from when clicking on a 1.9 client object in the Client Search Results screen
9. At several spots in the dashboards when clicking on links you may be returned to the Splash screen. These are usually links that may require multiple client input to complete and with the mix of clients this cannot happen. Better than an error.
10. The Administrators group was present in the Parent Subnet dashboard page and members have administrative subnet access and functionality
11. The log files do not seem to contain any error messages.
Three clients on 192.168.2.0 (Parent) network upgraded
1. All looks normal as expected.
2. Full dashboard function
3. All client objects visible and data populated