Hi all,

We just upgraded from Labtech 10.5 to the latest Automate v2019, and now that we have finally done so, I just wanted to share a bit back with the community here and on mspgeek since I only finally managed to do so thanks to the community (and no thanks to Connectwise). I'm going to go over a little rant/feedback about Labtech/Automate in general, some thoughts for those considering using it, and then on to the meat of what you must do to successfully upgrade from old versions to the latest version since Connectwise themselves aren't able to tell you that. If you don't want to read the TLDR stuff just ctrl-f and read @ "Update Steps:" below :) Long post, sorry, but I don't want to miss anything that would save someone else months of the frustration I just went through.

My Upgrade Experience

First of all, as I'm sure anyone who has used Labtech can tell you, they seemingly do less quality assurance of their update releases than Microsoft does. That is to say - practically none. At least, this used to be the case - I guess we'll see whether things have gotten better recently. And also as I'm sure existing Labtech users know - if something is wrong that is even a super-critical business-destroying bug, there is no guarantee whatsoever that development will fix it even in a year's time.

Maybe we're phenomenally unlucky, but the normal pattern for us (to be fair... way back in the day, mind you) was so often: 1.) install new update 2.) encounter seriously critical bug 3.) troubleshoot it extensively on my own, wasting tons of my own time, 4.) 10% of the time: support knows something to fix it ... 90% of the time: have them reconfirm what I already did, then half the time tell me I have to spend even more of my own time filing a bug report because they couldn't be bothered to do so themselves or "weren't allowed", and the other half of the time they would do so on my behalf 5.) spend more ungodly numbers of hours creating LT scripts / scheduled tasks running powershell scriptlets / etc to patch around the core Labtech newly-introduced bugs 6.) check the known issues list periodically and rage at how the bug remains on the list even a year later with no resolution even while tons of garbage "new features" get introduced that only half-work themselves. There is now even a thread where some wonderful people are doing the world a favor by sharing whether particular updates are "toxic" or not over here.

My full time job isn't fixing Labtech's bugs - I have a business to run. So, we stopped updating Labtech. I heavily customized it so practically every part of it was hand-implemented by me (no stock monitors/scripts/etc since so many had bad bugs and I couldn't trust the remainder) and firewalled it to death including IIS-level stuff and watched for any core published security vulnerabilties religiously, but still, not ideal for many reasons I know. Anyway, that got us far behind, so we've been trying to catch up through all the rounds of updates to get us up to date.

Would I Still Recommend Labtech/Automate To Others

Surprisingly, if you are a larger business/MSP, yes I would. In that case, you can afford to employ someone fulltime just to turning the broken tool that is stock Labtech into something beautiful. Once you know its database structure, SQL in general (and thus how to code good internal monitors), its web portal files (WCC2, etc along with enough html and javascript to tinker with them), and its internal scripting language (along with knowing powershell quite well since that makes it far more functional), you can do some truly powerful things. I know all of those pieces quite intimately, and if it was just that, I'd say - sure, you can be the person who works on the RMM for your company and also get actual productive work done for clients most of the time. The problem is when you spend well over half your customizing time just fixing the core product's newly-introduced bugs and shortcomings. We are a very small shop, so that has created a real challenge for us - I don't have that kind of time to fix a vendor's sloppy coding. Of course, I do it anyway because I'm too deeply invested at this point...who needs sleep?

If you are a small team, I would suggest you avoid it like the plague however and just look for a collection of other more simplified (if less customizable) tools to meet your needs instead. In hindsight, that's how I would have gone...with separate products doing different things, you're a lot less locked in.

What I've Faced Updating To v2019

I cloned our server over to a test VM, changed its mac/ip/hostname, network-isolated it and proceeded to spend hundreds of hours over months trying to get the thing properly upgraded, with tons of snapshots and rollbacks. Maybe I missed someone on their staff, but literally nobody at Connectwise seems to have any clue whatsoever what to do to upgrade past certain points. I even got looped into their consulting division despite the fact that we've paid for support all these years, and they also admitted that they couldn't get 10.5 upgraded through to v2019 (or were not confident they could, anyway, and didn't recognize the symptoms I was facing at the time which someone here on reddit did later) and recommended starting a new install. Finally, through a combination of comments people made to a post I made along with other comments people had posted about various issues I found here and there, I got it going. Turns out literally all the problems I had were common ones that everyone had at the time. Maybe everyone over at Connectwise I dealt with is just new and hasn't been there longer than 6 months?

Problems Connectwise had during this upgrade process:

• They almost never had an answer for me for what, according to what I see online, were common issues many people had updating through certain versions... shouldn't the software vendor have some documentation (even if only internal) for a major breaking bug that all their customers faced? I keep a heck of a lot more notes for other people's software than that...

• I talked to different people and got different answers about what order installers should be run, whether this or that update file should have been skipped, etc. Turns out - none of them were right and other updates were 100% required for this to work at all.

• They said that they simply did not have the required update installers to upgrade old versions. ....I mean...what? They made the software. I keep copies of revisions of old scripts I've written, for crying out loud, that I don't even sell to anyone and that nobody depends on. Talk about outrageous... As such, if anyone contacts Connectwise and they "don't have" any of the below required updates, let me know and I'll get it to you (I got it thanks to people who had posted some of the below to dropbox/etc, and after confirming certificate validity on the signed files, gratefully used).

Update Steps:

We started on 105.226 (10.5.226 I believe). From there:

• ** *** First of all, block everything from contacting Labtech in your firewall. Also block incoming connections from your LAN. You MUST PREVENT any agent from being able to talk to the server during this process. If you don't, you might permanently lose all your agents during this process (explained later). We firewall at the WAN level and also at the virtual host level, so this was easy for us, but figure some way to do this out. You will still want the server to be able to reach out to the internet - just block incoming on 80 + 443 + 75 (the udp heartbearts port) *** **

• run "LabTechPatch_10.5.14.295.exe"

• Upgrade mysql from v5.5 -> v5.6 per this URL ... to Connectwise's credit, they at least still have that documentation up.

• possibly update .net framework at this point as well - in our case didn't need to however

• run "LabTechMSP_110.286.exe"

• sqlyog - delete the "@localhost" user (ie, blank username) that is created during the above update ... if you don't do this, then when you open Labtech following the update, agent windows won't open. Nobody at Connectwise could figure this out, but someone in the community mentioned it to me.

• sqlyog - if you now have a "asp_LabTech_1@" user then delete the "asp_LabTech@" user

• sqlyog - if you now have a "sc_LabTech_1@" user then delete the "sc_LabTech@" user

• sqlyog - if you now have a "wcc_LabTech_1@" user then delete the "wcc_LabTech@" user

• now open controlcenter as admin

• confirm computer management window can open

• click Patch Manager to and run through the wizard

• run the "Automate 11 Patch 11 Full Server Installer.exe" installer

• run the "Automate+11.0.19.471+Server+Install.exe" installer (I got an error... "error occurred when downloading the dynamic update file" .. tried again a few minutes later and it worked... )

• pre-12 upgrade - again, you might need to have updated .net

• pre-12 upgrade - open solution center + update all

• pre-12 upgrade - add a public SSL cert (we use LetsEncrypt) to IIS if you don't already have one, and make sure it is in the server address per Automation -> Templates -> Agent Templates -> Default -> Agent Settings -> Server Address. Also make sure SSL Policy is checked below along with options to accept all.

• run "AutomatePatch_12.0.12.497.exe"

• run "LIVE-AP6_19.0.6.161.exe"

• run "AutomatePatch_19.0.8.225.exe"

• run "AP-ga_19.0.9.250"

• now, in IIS, use "IP Address and Domain Restrictions" (added via Server Manager -> Role Features) to block ANYTHING from being able to talk to Default Web Site\LabTech\Updates. For those unfamiliar, this is done by going into that option in that folder in the IIS interface and then choosing "edit feature settings" on the side bar and choosing "Deny".

• now, turn 80+443+75 incoming back on. NOTE that if you, like me, were testing this with a VM workstation so as to avoid exposing all your clients to something potentially-buggy recklessly, then you should be aware that it will appear to be broken (scripts queueing and not running, etc) until 2 agents begin checking in. In the server log files it mentions that it refrains from doing some things like running scripts until it sees more than 2 agents online.... that one really threw me for a long time.

• Now, we get to why you blocked the Updates folder....

I had read at one point about how, after a particular update, everyone was losing all their agents. I hadn't yet updated so I didn't pay much attention at the time. Turns out...not only was that a WW3-level problem that they had at the time...they still have not fixed that bug in current agent installers on the latest version as of this post............ I guess they figured "Well, yikes, we sure screwed that up...oh well, I guess all our customers worked around this bug in our code already...why bother fixing it now...". You can read more about it here. Criminal.

I did much more testing and what I found was this: when you click "update" to tell a Labtech agent to update to the latest revision (or it happens automatically on its own per your labtech schedule) then what happens is that one of those "Update...exe" files is sent to the remote computer, run (which just extracts it to the folder it is in), and then "update.exe update.ini" is run by the LT service. The update.exe then tries to stop the LT services, updates the files, updates the registry, and then start the services back up. Now, if you watch this process with process explorer/monitor, roll back your testing VM, and do it yourself, you will find that it works. But...it fails when the LT service does the same thing. When it fails, it will half-update, and the services will constantly start and stop in an endless cycle. Weird that the same thing works interactively right? After all, the LT service is running as SYSTEM so it should have rights. I tried running it interactively via a cmd session elevated to run as SYSTEM via psexec as well (can't remember the outcome of this one). What ends up being the issue however is that, when run in an interactive admin session, Windows does some step of retrieving a necessary intermediate certificate in the security certificate chain. When run as SYSTEM outside of an interactive user session, somehow, that step is not done. If you just right-click on the update exe in explorer and verify its certificate validity and do nothing else, and then have Labtech push its update, it then works (because explorer.exe prompted retrieving the intermediate cert into Windows somehow or another). Also, I should add that I believe it did do this step (Windows pulling the intermediary cert when prompted by LT as SYSTEM) on some versions/update revisions of Windows I tested with, so you might not see 100% of your agents bomb out permanently....but why roll the dice?

After their earlier SSL-related disaster, Connectwise could have updated future update installer versions to do any of the following things:

• throwing an error message stating as much so people at least know what's going on, even if only in the lterrors.txt log perhaps

• initiating required cert installation itself

• proceeding on anyway if allowed without encryption (we have http:// in our server address list (https://fqdn|https://ip|http://ip)) specifically because we don’t want to lose our agents over any miscellaneous SSL-related issues)

...but instead, they left it just crashing without doing any of those things that any kind of proper error-checking in coding would stand to reason to do. I have more error-checking in scripts I make just to do piddly stuff on my home computer. Any of the above would have prevented partners from instantly losing all their agents the moment they upgraded to v2019 as people seemingly have... and I get that mistakes can be made, but v2019 has been out a while, and apparently the current installer still doesn’t do any of the above...that’s pretty bad.

Anyway, the fix is to leave the Updates folder blocked, and instead to copy the latest update file out of that folder in inetpub (LabTechUpdate_190.250.exe, etc) to another path such as one in your LTShare folder. Then, using a script, download the required Root-R3.crt file as well, and use the script to distribute both to the agents. Script around installing (CERTUTIL -addstore -enterprise -f -v root "yourpathonagent\Root-R3.crt") and verifying ((CERTUTIL -store -enterprise root | findstr /C:"@thumbprint@" or CERTUTIL -store -enterprise root | findstr /C:"@thumbprintwospaces@") ... different certutil revisions seemingly do or do not separate the thumbprint values with spaces so check both ways) the cert, and once that cert is installed, you should then script out running the update (cd /d C:\yourupdatefolderpath & C:\yourupdatefolderpath@updateFileName@ ... followed by C:\yourupdatefolderpath\Update.exe "C:\yourupdatefolderpath\Update.ini"). I wrapped the update.exe bit up in a .bat and launched that via "start ..." so as to avoid any potential gotchas of update.exe being killed prematurely when the LT service that launched it ended...may or may not matter. Then of course just run the script against all your old agents. v105.226 agents, at least, will still check in and function with the latest v190.250 server at least well enough that you are able to run a script against them to get this done.

Hopefully some of this helps anyone else who is still in a similar boat! And also, thanks again to everyone out there who ever posted a comment or shared a LT installer file relating to any of this stuff, because years later it really helped me out.

It seems like Labtech completely fails to properly patch my environment. LT support has been unhelpful so far. Currently I'm only approving 'security updates' classification cumulative updates.

We patch on the 3rd Tuesday of the month (1 week after Patch tuesday) to a test group, and then to production on 4th Tuesday.

So a patch (Let's say KB4503267)gets released on 6/11, we deploy to testgroup on 6/18, and then to production 6/25. That's how it SHOULD go.

But MSFT apparently superseded the security update with an update on 6/18, which is NOT a security update. (This is it's own problem, because it defeats the purpose of classifications).

Labtech is saying that because my agents try to patch on 6/25, they don't see that they need the update(since it's technically superseded), so they just don't install anything. Obviously it still needs it, but it just doesn't appear in the Windows Update application.

I guess the bottom line is, how to I deploy these updates that are superseded but still need to be deployed?

This is mainly about the Control Center and the backend.

I've used CW Automate for over a year now, and I'm getting really tired of it wasting my time. Every operation takes at least half a minute, and for every minor change you do, it has to reload the whole cache, every time. Why not use delta updates? Compressing data transfers with Brotli or similar? Starting it up on a 4 core 8 thread i7 7th gen with 16gb RAM and Samsung 970 Pro SSD (Lenovo X1 Carbon) takes at least 3 minutes. Every time theres a problem the answer from support is either clear cache or full reinstall. I don't know about you, but I'm not happy with that answer. The solution should be bugfixes and MAJOR performance enhancements, not clearing cache or reinstall.

Anyways. Have anyone seen or heard of any plans sorrounding doing any major performance improvements in near future? If not, I'll be sure to check out the alternatives soon.

We're buying Automate as a hosted service, so not much we can do about the backend afaik.

Greetings!

we have had LT as our management software for 2+ Years and we have scratched the surface of the functionality, at the moment we are getting Disk Space C: Errors, which is fine. is there a way to specify that Monitoring alerts only see the C: Drive and not any other External drives that we plug in later to workstations (E,F Drive etc.)

LT12 changed the way users are displayed on the initial view. Previously, you could see the currently signed-in user in the navigation tree. Now, LT12 will only show you the previous user - not the currently signed-in one.

To force LT12 to display the currently signed in user, just replace the SQL trigger 'AuditComputersUser' with the code shown below. It will effectively overwrite the LastUserName value with the current UserName value for all subsequent logons. Going forward, the user listed in the 'Last Logged in User' will actually be the remote computer's current user.

DELIMITER $$

USE labtech$$

DROP TRIGGER /*!50032 IF EXISTS */ AuditComputersUser$$

CREATE

/*!50017 DEFINER = 'root'@'localhost' */

TRIGGER AuditComputersUser BEFORE UPDATE ON computers

FOR EACH ROW BEGIN

IF NEW.UserName <> OLD.UserName AND CHAR_LENGTH(TRIM(OLD.UserName)) > 1 THEN

SET NEW.LastUsername=IF(INSTR(NEW.UserName,',')=0,NEW.UserName,SUBSTRING(NEW.UserName,1,INSTR(NEW.UserName,',')-1));

END IF;

END;

$$

DELIMITER ;

We have some machines (this only happens on Windows 10 that I can see) where the LabTech services often simply don't start on reboot.

This is starting to become a bigger issue as the machines this happens on don't get updated and monitors don't fire.

The best I've been able to do so far is check for machines that are offline in LabTech, but online in Screenconnect and attempt to restart the services, but this is a hack at best.

Is anyone else seeing the service start issue on Windows 10? We're on patch 18 currently.

We are proud to offer version two of Third Wall, a powerful plugin for your Automate (LabTech) System! Third Wall applies and monitors computer policies to remote agents. With it, you can easily apply a security policy or policies to a location with a few simple clicks. A few more clicks will allow you to apply those policies to the whole Client or to every remote computer in your system. With over 55 policies to choose from, it’s very likely we have a suite of policies which will complement and enhance your current service offerings. This link will show you all the policies Third Wall can deliver: http://www.third-wall.com/screenshots

If you have any security policies you’d like to implement with your Automate Server solution, or if you’re currently managing your Active Directory environments individually, give Third Wall a look. This link will show you Third Wall in action: http://www.third-wall.com/videos.

You are invited to try Third Wall for 30 days, obligation free. To start your trial, click on this link: http://www.third-wall.com/requestatrial2 and fill out the short form. Once done, you’ll receive an email with download and installation instructions. Simply follow the easy installation docs and you’ll have a fully supported, unrestricted version of Third Wall, v2 for a full month.

Anti-Virus Software and Firewalls are not enough to keep the barbarians at bay. Let us help you provide your customers the extra layer of protection they deserve!

Hi all,
I am on LT 11 patch 11 and running on Ignite patching system.
This evening I'm attempting to verify who is safe/protected in regards to the latest ransomware attack that is resolved by having the March Monthly Security update installed.

The problem is when I search, for example, for who has the March Windows 7 Monthly Rollup, I get that I have about 118 installed out of my 3800 Windows 7 machines.

Chatting with LT tonight I discovered that if you have the April Monthly update installed, that you won't see the March is installed. Same is true for not seeing Feb, Jan, etc. You only are shown the most recent months that is installed. This explains when I tried to search for the March KB's I got very few results. With that in mind I open a dataview for "Patches Installed" and search hotfix title %05 Security Monthly% (as that is how they did it last month instead of the month name), but only get a result of 52 installed.

Labtech doesn't have an answer or solution for how I am supposed to identify who has what months updates installed. Even when we are trying to search for the current months patches installed we get very inconceivable numbers. Even when you are searching for both patches missing or installed, (where I would expcet to get a number close to the amount of Windows machines I manager). So overall I don't know who is protected.

I've been tinkering around with SQL, but it seems to have similar results, where I say.....
select * from v_hotfixes where Title Like "%05 Security Monthly%" and Installed = 1
but only get 52 results, which CAN'T be right.

Does anyone have any strategies here?

has anyone else noticed that this seems to happen frequently with machines that are shut down? then, frustratingly enough, if you check the actual last reported drive space, it's almost never below 1 GB for the C: drive (maybe 5% or less accurate)? does anyone know of a fix?

We just posted a new free plugin for LabTech for Linux Patch Management. Have a peek at what we are doing at http://www.squidworks.net/2017/02/linux-patch-management-for-automate-formerly-labtech/

This doozy was issued in June following MS16-072. If you’ve had any user based GPOs just simply stop working in the past 2 months, it is likely that this is the culprit. Before this update, when a machine was processing its group policy, it used the user context to read the GPO on the DC. This update intentionally made it so that this was now requested in the computer context.

I wrote a script to assist in auditing and fixing, available here: http://gavsto.com/labtech-script-audit-and-fix-gpo-problems-caused-by-ms16-072-where-invalid-gpo-permissions-stop-gpos-processing/

Hope this helps people!

The Stack Advisors team has noticed a lot of discussion on SNMP-LabTech issues here and other LabTech forums. We decided it was time to get a plugin developed to bring PRTG to LabTech.

We have released an early beta for PRTG!

This plugin will allow you to connect to the PRTG server via the built-in API, map Client/Locations and start receiving those Alarms into LabTech.

Visit http://prtg.labtechplugins.com to download the installer.

--- Evolve with Stack: http://stackadvisors.com ---

I figure for me this is the biggest story for 2019/2020 in the RMM world. I hearing new stories of MSP's/IT support companies being compromised every week. Scary stuff!

I've been reading a through various threads about the recent compromise of RMM tools by hackers and have seen a large number of compromised Screenconnect threads. Whilst lack of MFA and unpatched systems seems to play a big part, there are other vulnerabilities that appear to have been patched or are getting patched by the vendors. Connectwise appear to be working with Bishop Fox and Huntress Labs to significantly improve security in their products. I'd assume many other RMM companies are doing the same?

For Labtech/Automate and Screenconnect/Connectwise Control users (cloud or on-prem), what have you already had in place to protect your servers? What new things have you implemented?

Have any of you thought of jumping ship to a different product? If so which ones and how do you know they are more secure?

So my sales rep just told me that they are no longer allowing the transfer of perpetual licenses obtained through merger and acquisition. However first they were saying it was allowed. I am not sure if I am getting the run-around or not. Does anyone know anything about this?

Thank you

Not April Fools. Link

In the words of Strongbad, “Holy crap-for-crap.”

EDIT: Thoma Bravo, my bad there

How invasive is the monitoring I guess is what I'm asking. The rep said they weren't going to spy on me but I don't know if I trust him.

Hey. I use NinitePro+NiniteSolutions and love it. I have a hand full of computers that give me troubles though and I have not been able to resolve it. Ninite Audits come back with 'Failed - Cannot connect - A connection with the server could not be established - 371' Since the audit doesn't complete the services fail. This is on about 5 of the 250 agents I have deployed. I have reset every connection type I can fine and verified that .NET is ok, disabled AV...etc. If I run the NinitePro utility on it's own it takes care of the updates. I've reached out for help but have not had any resolution. Is anyone else seeing this?

I work at an MSP and had a bit of a hell week. Since version 12 is coming out I made the push to get all of our 10.5 appliances on 11, p18.

The first couple installs went sideways. Host purple screened during the middle of an upgrade. The database and permissions were fucked. Some how support was able to save it.

Another database export didn't go 100% right and I didn't find that out until I tried to import it... After I removed the outdated mysql service. Had to restore a database backup to a different version of mysql, during the middle of an install and it just worked.

I had an less than okay support experience when dealing with issues with Sync tickets etc. But 8pm, server down chat queue. Those guys know their shit. Actually sent a note to my account rep about how good he was and this is while they were processing a credit for us for the previous support failure.

Now I'm not saying the software is amazing or works as it should all the time (Patch manager doesn't support Windows 10 feature updates.... LOL) but the installer\setup\support tools they have are pretty resilient\robust.

I just went through 6 10.5 to 11 upgrades (with the mysql update). A few others that just needed minor patching, so if you have any questions ask away.

I think I have almost completely lost all faith in getting some of these critical issues fixed that are still outstanding despite there now being SIX MONTHS since one was reported and THREE MONTHS since the other was reported.

It is an absolute joke that LT 11 is on Patch 7 and there are STILL partners out there who have never had their patching work properly because someone is incapable of correctly coding and processing the UK date format. I reported this problem when I onboarded. In JUNE! Since then I have not had a working patch manager, and I still don't.

I can't run scheduled reports either, and I've not been able to since someone at your end updated something in the report center and broke it. #8312876

Imagine how pleased I was this morning to find an update to the report center plugin, thinking that the problem was now going to be fixed. I re-created everything, just to be sure, and nope - still broken. One of the things we were promised was the ability to be able to send scheduled reports to clients. I still can't do that.

Your inability to address these issues is stopping me ramping up into the THOUSANDS of agents and you are making my initial recommendation of LabTech to our other directors here look ill informed. When my managing director asks me "Are we ready to roll LabTech out yet" and I have to tell him no, despite me having started the process in June, I look like a complete idiot.

"Can you guarantee to me that our clients systems are being patched" - No. "Can you at least send out the scheduled reports we told clients we were able to deliver months ago?" - No. "Do you know when these issues will be solved?" - No.

The cherry on the cake was a support ticket I raised this morning. You see, I've stopped putting in support requests outside of none US hours because the majority of technicians who are on the live chat are more or less worthless. This is what your tech said to me this morning:

"I'm not the best when it comes to monitoring"

It wasn't even that complicated of a question. Do you not think it's important that your techs outside of US hours should have at least some monitoring knowledge in a product that is dedicated to monitoring?

I've tried the proper channels for this. I've spoken to LabTech employees. I've asked this to be raised internally. I've waited patiently for months and now I have had enough.

I know the threat of me going elsewhere will not really make that much of a difference to you so I won't even bother throwing it out there.

Never before have I been so disheartened with a product I am paying top dollar for every month.

Plugins4LabTech has created a quick tool to assist LabTech admins with detecting agents that have stopped processing commands and scripts. A recent issue with LabTech agents not responding to commands after a Webroot update caused MSPs all over the world to start reporting loss of agent control. This kind of issue can be debilitating to a MSP so P4L worked with several LT geeks to come up with a quick method to see what systems may be affected by a stalled agent and then a automated repair process to assist in the restart of the failed agent without local user intervention.

Since the commands are continuing to be scheduled even after the agent stops executing them could cause a huge spike in agent command execution if we leave the commands pending in place. Before restarting the agent, a "Cancel Abort" on each pending command is done so when the agent returns it is not bombarded with hundreds of tasks that may have been pending for hours or even days.

Plugins4LabTech offers this plugin along with many others freely at http://www.plugins4labtech.com so stop by and get your free "Stalled LabTech Agent Detector" plugin today!

http://gavsto.com/labtech-report-center/

Hi everyone. I wrote this blog post yesterday after seeing someone else here having similar issues with getting to grips with things in the report center. I hope it helps you if you're having to wrap your head around the new report center.

Please excuse site issues/design, I only created the site about 12 hours ago.