Transcript
video. Thank you for joining our product office hours this week. This is our second installment of product office hours. Today, we're going to really focus on what's new in RMM scripting. So I have a Jankia on with me today. He's going to do the bulk of the work, and I get to turn off the camera and just listen and answer questions. But we're going to talk about a couple of new things that are coming into scripting. We're going to spend time on Q&A. We'll talk about what the upcoming sessions are for the next few weeks, so you can plan on whether or not that's an interesting session for you, and also let you know where you can get all of these videos, which we're also uploading to a channel on YouTube. So for those who haven't been on this before, this is our regular office hours. We had done something like this about a year ago, really focused only on RMM. Product office hours are focused on everything to do with ASIO. Sometimes it might be RMM sessions. Sometimes there might be PSA and ASIO sessions, sometimes security sessions. So that's why we're making sure to post the schedule ahead of time and kind of see what areas we're talking about. Usually we'll talk about at least one new thing that is just releasing now or about to release in the next few days, and a lot of times some additional best practice, some usually related to that same area of the product. So our last session, we went quite a bit into PSA sync between PSA and RMM today into scripting. There is a Q&A, and we have a couple of other people from the product team that are on as well to answer questions in the Q&A. So please put your questions in the Q&A of the GoToWebinar, and we will answer them as we're going through. We'll answer, but at the very end, we'll answer as many additional questions as we can, maybe read out some of the ones we've previously answered. And with that, Jankya, I'd like to turn it over to you. Please take us through what's new in scripting for RMM. Thank you so much, Jason. So there's a couple of items that I'll be talking about today, and we'll have a couple of demos as well. Starting off with script sharing, this has been a request from partners where they want their users to have the ability to share scripts across users so that they can collaborate on the same script, create, edit, and update the same scripts. It allows for collaboration between users and also ensures that we are doing that in a controlled and secure manner. And the next one is run as a logged in user. These partners have been requesting for this as well. There's multiple use cases here where they want to run scripts in the logged in users context where they want to either show messages to users who have logged in for a reboot or change their wallpapers or change desktop backgrounds. The use cases here are multiple. Today, we only supported running tasks in system context. We are also going to give them running them in the current logged in user context. So with that, I'm going to start off with the first item, which is script sharing. Before going there, we have planned an early access release or a limited partner release for script sharing in the first week of September 2025. This will be followed by a global release for all partners. For runners logged in user, we've already done an early release for limited partners. The global release will happen tomorrow for all. Okay, when it comes to script sharing, before I get into the demo, I want to share certain concepts that need to be understood. When a user is playing with the script sharing console in the script in the script editor today, you essentially are in characterized home. You have four permissions view create update and delete what we are going to introduce with this change is more granularity with these permissions. So what you will see is for view update and delete you will get four granular permissions, which would be full access my access shared access and role-based access full access will essentially be for a private first for a role like primary super admin or super admin my access and we'll talk about this more is when someone would like to restrict a script just to the creator or the author of the script shared access is when a user would like to share that script with all other users and role-based access permission is when a user would like to share the script with other users who have a particular role assigned to them. Now these permissions go hand in hand with sharing levels. And when I talk about sharing levels, I'm going to give you a sneak peek. This is the existing script editor today when this goes into production a user is a user who is entitled or who has the permission to share scripts is going to see something like share with only me or this is basically the sharing access that the user will have. It's going to let the video run us slightly ahead. When I click on that I get three options, which is share with only me specific roles and everyone now, this is the same sharing level that I mentioned one of the things to consider here is the sharing level and the permissions in connect wise home will go hand in hand. So if a particular script is shared only with me, I need to have my access permissions so that those two things can work together and I actually get to view that particular script. Now in this example, I'm only referring to view but the same rules will apply to update and delete as well. And similarly if if I share if I share a script with a particular role, I need to have role-based access if I share it with everyone. I need to have shared access and for full access. It really doesn't matter what the sharing level is. This is basically the primary super admin and super admin who are going to have full rights on that particular script now manage access in another permission and manage access permission is essentially going to control what I just showed was the share with me only. So whichever user is enabled for that permission will be able or will have the power to share scripts across roles just with himself or with everyone. So these are the items that need to be considered when you look at the new script editor options for script sharing. I'm going to do a demo of exactly what I shared so that we can look at a live demo. So the first script that I created just going to go a little back as you can see I've created a script and I'm going to give it a role-based access and I've actually shared it with technician. So what I've done is created a script went to sharing level and said share with specific roles and shared this with technician. Like I mentioned for a technician to have the ability to view this script. The technician must have the permission of a role-based access that I had shown in my PPT. So we will look at a live scenario here. Once I do that, I'm going to save my script. Now this script is shared with a technician role. What I'm going to do next is navigate to two different user roles. The first role is going to be manager and the second role is going to be a technician when I go to a manager role. I'm going to focus on the permissions that that manager has. We will see that for that particular manager. We only have the shared access permission here again. This is from a demo perspective when it comes to all users. They will they are mostly going to have my access because they're going to have access to whatever they've created. But right now a manager has shared access. He does not have role-based access, which means this particular manager will not be able to view the script that I just created. Now the next screen that you are seeing is actually for a technician and as you can see a technician has role-based access. So when I log in with a technician user, the technician user will be able to see that particular script that I created. I'm going to let the video run. The first login is for the manager where which had shared access, which means that the manager should not be able to view the script. So as you can see, the manager is not able to see the script sharing script sharing testing script that I had created. The next user that I'm going to demo is going to be the technician and the technician should be able to see this particular script. All right, so this is the technician user login. I'm going to go to the search and look for that script. And as you can see, I have access to that particular script. Now, I did mention this earlier, but I would like to reiterate the same permissions or the same rules are going to apply to update and delete permissions as well. So based on what you've checked under update and delete, you will see icons appear for edit and delete for this particular script. Okay, the next piece that I will be doing is actually editing this. Now what we want to do is the script was actually created by a primary super admin. So I'm good and I have all the access there. I'm going to go back and put it in everyone mode so that I can show that someone who has a shared permission access will now be able to see this. Yeah, so as you can see I put it in everyone mode and I save the scripts as you recall my manager had shared permission and shared permission goes with everyone. So the manager should now be able to see it and because I've moved this into everyone and this is no longer in a role-based script sharing mode. The technician should no longer be able to see this. Okay. Now this is the login for manager and when I search for this script, you will be able to see that the manager is now able to find the same script. We will look at the login for the technician next which has the role-based permission and the technician will not be able to find this script and. All right. So as you can see, we move between modes and as we move between modes it respected the permissions for that particular user role that we had specifically manager and technician the third scenario. I'm not running it through is basically putting it into my mode and what would happen is neither the manager nor the technician would be able to see it because the script would just be restricted to the user who created it and any primary super admin or admin who any primary super admin or admin they who has basic full access permission that has grant that has been granted to them under connect wise home. So that's the first demo. I do want to move next to run as logged in user and I need to stop share and share my screen again for a second. Okay, I will be playing next. I will be playing the demo for runners locked in user. Yes, we can see it. All right. So this is a functionality that I believe partners have been asking for quite some time and this is currently in testing phase and to be shipped out pretty soon. Currently, we are looking at an EA release date of around end of this month, but I'll definitely share out more details. As I mentioned earlier, this is already released into EA and GA will happen tomorrow. Now before I get started, so what I've done is I've actually navigated to the page where we will see the option to run a script or a step of that particular script as a logged in user or in system context. So what you can basically do here is for every step that you have in the script editor. You have the flexibility to choose if you would like to run that particular step as locked in user or in system context. Now what I've done here is I've written four steps. I have two PowerShells and between each of those PowerShells. I have a script lock to show what output it is, but I'm going to talk through the first PowerShell that I have this PowerShell essentially is a pop-up message or a box message that's going to be thrown on the user machine when a when a user is currently logged into that machine that and I'll shortly demo that as well that the you if the user is currently logged in this is the message that's going to show up on on that particular machine. And then I have a script block for that and on the next PowerShell what I've done is try to capture the name of the user that's basically logged in on that particular machine. So I'll run this run this particular script first. I still have a few other items to share as well, but I'll do a short demo of this and I'll also show how this particular output comes in. So this particular machine is a machine that I've essentially logged into and I'm going to share that machine on this screen. Okay, I'm moving this particular screen away. I'm going to hit run from that screen and this is the machine that I have essentially logged into. Please confirm that you can see that particular machine on my screen before I hit from. Yep. Okay. I've scheduled the task on that particular machine. All right. So there you see the same message that I had written as part of that PowerShell is thrown. I'm going to say okay right now the message is there twice and that's because of troubleshooting that we are trying to do. That's purely from a testing perspective. It's only going to be shown once because I've written the message once. Now once I do okay and okay essentially I'm going to bring this back. Does that work with like an RDP server where there might be six people logged in actively? Yeah, so if there are multiple people logged in Tony, it's going to basically look at I believe it's going to arrange the users in alphabetical order and it's going to return the first user that it finds because out of six it doesn't know which user to pick. So we have a rule of organizing the users first so that it stays consistent every time if it picks more than one user at a given point of time. Okay, I was just thinking potentially use case of notifications on an RDP server saying hey we're going to reboot at 11 p.m. make sure to save your work and you want everyone to get that message that's on the server. Yeah, okay but I'll still run it again once with my team with this specific use case because we did consider the fact that there would be multiple users logged in but let me circle back check-in and I'll get that information. I mean it's abnormal compared to all the others. By far this single user would be in most instances. I would just want to make sure people are clear about that. Okay, all right so as we can see the task completed successfully. All right, so as you can see the kind of the PowerShell that I had written basically was a show box which meant it stops until you hit okay and okay. There's obviously different ways of showing that message and that's why you see the two okays there. This is again because of the troubleshooting with that we've put in that you see it two times. So you basically see the user which is admin which was currently logged in onto that particular machine. Now what I've also done was I wrote another script and I'll show that script to you. It's the same script. I added a third PowerShell only this time I ran this particular PowerShell in system context. So what's basically happening is you have the first PowerShell that runs as a current logged in user the second PowerShell that runs as a current logged in user and the third one that's going to run in system context. So so as you can see on the previous one, I got this run as current logged in user because my entire script was purely current logged in user if I have a combination there what it's going to show me is actually something as mixed because now you schedule part of the script as current locked in user and part of the script as system user. So So as you can see the same piece of output game where the first two script steps were run in current logged in user context and it showed the username admin and okay okay on top but when I ran it in system context as you are aware NT authority is the system that has the maximum permissions and when you run it in system context is actually is reflecting that it's actually running the system context here. Also as you can see the run as that we saw that it is the runner shows as mixed because you chose because it was a mix of choosing run as logged in user and system. Now one other thing that I do want to call out is this mixed or run as logged in user or system will be purely based on your script definition on based on how you define the steps over here. If the all of those steps are system then the runners will show a system if these are make a combination of mixed steps is going to show mix and if this is all current logged in user is going to show current logged in user one other item that I do want to call out is today or the first release is only going to be for Windows. So what we've done is we put a small validation here that if you choose Mac OS and if you try to save this script for current logged in user it's going to throw your message locked in user context is only supported for Windows. This is just to prevent a user from scheduling it so that it doesn't go downstream and fail subsequent release is going to include logged in user for Mac OS and Linux at that point of time. This particular validation will be removed. All right. Okay. Thank you. That essentially concludes the second demo that I had for run as logged in user. Jason I'm going to give it back to you. Yeah. Thank you. Thank you. The the demo within a demo was definitely trippy to watch through but I think it's great to show kind of as you were showing that to partner and to see their raw questions. I think it's great to show those. So it sounds like there were a number of people that had issues viewing the screen. We're still trying to work through how that happened with with go to. But in any case this like all of the sessions we're doing is part of a YouTube channel. We'll show the link to that. We put the link in as one of the Q&A questions but we'll share the link here in a second. Following the rest of the schedule for August next week we're going to go through deep with patching especially third party patching with more than 6,000 now actually more than 7,000 new titles added to third party patching which is great. And we'll go over some of the best practice policies as we work with thousands of partners. We see partners that have different types of workstations and server schedules and what that really means to overall patch compliance. We want to share some of those best practices. And then August 27th is a giant ask me anything. We're going to have the entire PM team on to answer just about any question related to RMM but we'll also show a preview of the new device with the new device list as well. There's something that's coming out a little bit later in the fall but the real focus for the 47th is a giant ask us anything questions with the entire PM team. But as always we keep this on University the overall schedule and we'll be I think next week we'll be adding the schedule for September. I'm going to go to the next slide. There is a quick QR code in a second here. Here's the quick QR code. Again we've created a single YouTube channel. All of these recordings are going on that YouTube channel. If you just want to subscribe to that channel you'll get all of these recordings and share them with other technicians on your team especially very targeted ones as each one of these sessions is focused on a different area. So with that we had a number of questions that come in. Let's move on to Q&A and start with a couple. There was a question specifically about our super admins able to view all scripts. The super admins today can view scripts that are created by any technician client site managers. How will that work in the future. Yes so primary super admins and super admins essentially will have full access rights so they should be able to view all scripts that have been created by any other user role and based on the permissions basically primary super admins and admins have all the permissions which will translate to full access. So yes they will be able to look at it. Okay a next question came in and says will this work if the user does not have an admin role. Can you share with somebody who does not have an admin role. Or sorry if the end user is not an admin. Sorry if the end user is not an admin. I read that wrong. Yes so if you share it with a technician who is basically not an admin role if the technician has the right permissions that go along with the sharing level that you put that script in then it should work for them. So like I mentioned it worked for manager and technician when they had the right permissions with manager having the permission of sharing shared access and technician having the permission of role based access when the scripts were in those respective modes. And when you run a script as user on the endpoint and that user is not an admin what happens to that script. So this is for run as log just trying to get some clarity. When you're running a script as a logged on user the question is will it work if the end user is not an admin on their machine. Yes. Depends on what the script is trying to do I suppose. Exactly yes. Great great. Coming up here for another one. Oh that's a similar similar question sorry. In regards to running a script as a user if you are presenting some form and waiting for an input is there a timeout for that for that script. So right now I don't believe there was I will have to check this and I'll make sure that I get back on this. Okay the each script itself has a default timeout. Yes it does. So if it if it runs into that then it will go to the default timeout which I think each script step we have a default timeout so which would be 15 minutes but I'll definitely get back. I believe it's 15 minutes as a pro. And then you know it's always is a good best practice when you are building a PowerShell script is to put as much of that error handling into that script and so if you are waiting for the input to come in and then you are waiting for error handling into that script and so if you are waiting for the end user to do something building your own timeout into that form is is generally a good thing to do. However ultimate timeout as you mentioned Ajank is 15 minutes per step so you can't do that beyond the minutes. Let me see here. Script permissions so this is jumping back to the the script permissions. Does this allow you to share scripts with the MSP rights with a tenant or site manager? I'm sorry can you come again? Oh this is a question back on sharing scripts. For script permissions will this feature allow you an admin to create a script and share with the client site manager? Yes so you can you can share it with the client site manager like I mentioned you can share it what we will do is show you the list of full roles that you have provided this for this role has the necessary permissions given to them and you put that script in the right in the right sharing level a CSM should be able to see the script as well and you can even you you would also be able to control permissions with respect to if they're only able to view it or also be able to edit it or update it. Okay a very quick one that came in can you remind everybody for the release time frame for both of the features we talked about today the run as logged on user and sharing scripts? Okay thank you I did want to clarify that so for run as logged on user tomorrow we will be doing a global release for windows and by end of month we should have a global release that includes run as logged in user for linux and mac for script sharing we would have a limited partner release in the first week of September and in a matter of one to two weeks after that that is when we should be looking at planning it for a global release. All right one last maybe we have time for two more questions a question came in this is related to sharing also sharing with client-side managers if you share a script with everyone uh over the set of those selects and everyone will that share with client-side manager? If the client-side manager has the shared permission then the client-side manager will be able to view it but if you just share it with everyone and your client-side manager does not have the shared access permission the client-side manager will not see this. Great great let's see if we can get one more question here if role-based permissions are selected will users see all roles or only their roles this is more to deal with how custom role management is made more so than scripting but I wanted to chat through that and I'll go ahead I'll go go for it. Okay right so today I think the idea is for managing it only primary super admins and super admins should have the rights to actually go ahead and look at the roles but any any role that has the manage access permission given to them in that tasking domain should be able to see all that so you should be careful on who you assign that permission to because they will get a lot of power to share it with other roles. Great great thank you and that brings us right to the end of the half hour uh we answered a few other uh items in the the Q&A thank you very much for everybody attending I apologize for those who were not able to see the screen then we'll put this up onto uh YouTube and you should be able to watch it through then as well as uh share it with other colleagues or or friends of yours so thank you thank you for presenting we look forward to seeing everybody next week uh when we go through third party patch thank you Jason thank you everyone
