 How's it going? I'm sure we've had tons of awesome conversations and discord and even questions from other sessions and all that good stuff. So excited for another one. Very, very fun. Yeah, awesome. So we're gonna talk about long-term account planning and account management, which includes working through the future of your domain name or domain of one zone. Sorry, domain name. Wow. Domain of one zone and into your account cleanup processes and how to make it sustainable for your school as well. So we've got all that good stuff going on. Yeah. So just thinking through questions for management, like Meredith said, you really wanna make sure that this is sustainable. You don't wanna end up accidentally building in tons of work for yourself. Making sure that your project can scale in a way that's manageable and reach a sort of nice resting point. So thinking about how you wanna scale, how many long-term users do you wanna maintain? And that's not something you necessarily have to decide upfront. Again, you can sort of find that nice resting point and say, all right, we're gonna stick with this. But also thinking about what policies you'd like to set. So for example, saying the default account has one gigabyte of storage, that's the maximum quota. And then we do offer a five gigabyte quota for people who's like faculty who have a particularly important project or something. But once it goes past that quota, once you start needing 10 gigabytes or something like that, in order to make sure resources are distributed fairly, we need to talk about other options for managing those sorts of things. And thinking through your support offerings. So what applications are people gonna use regularly? You don't wanna dedicate yourself to, or you don't wanna commit yourself to saying, yeah, I can support everything and install a Tron. That's gonna be easy, no problem. Because you can't, or at the very least, you really don't want to. And you'll quickly find yourself like supporting like a chatbot software or something like that that you have no idea what it is. So definitely understanding which applications for projects that folks are gonna use on that side. Yeah, so setting your policies upfront. And maybe you revisit them down the road if they're not working, but having something in place that you can reference and you can say, no, it's in the rules. We wrote it down. You can read them here. There's always just a good outlet to have, I find. Yeah, so thinking about planning, we talked about that sort of natural cycle figuring out sort of where you want to rest what the sweet spot is. We can, sorry, just a second. Yeah. Basically, there are a couple of different ways to think through what decommissioning is. Decommissioning is the regular sort of cleanup of your server to look at accounts and say, you have lived on this server for long enough because we want to stay at a nice balance of account numbers. We wanna make sure that the server is serving people as we want it to. It's maybe time for this account to be migrated off or to be deleted if it's no longer being used or something like that. And thinking through that cycle, it'll probably be based on your use cases. So for portfolios, people will probably wanna keep those as long as they're at the institution, but for coursework, coursework happens on a much shorter and much more cyclical basis. So maybe you're taking a look at that every year or something like that every semester. For an academic project, that may want to need to live on even past when a person departs the institution because they hand it off to somebody else, something like that. So in general, looking at your use cases and then thinking through, it's probably better to plan for a longer-term use case than it is for a shorter-term use case just to make sure that people aren't accidentally getting caught up in that net and to make sure that you're not doing more work than you need to. And as you'll figure it out, again, thinking through those policies, what makes sense for you and then testing it out and saying, all right, here's how we're gonna make adjustments. On those policies, you get to set them. You get to, as I said, tailor them to your specific project, to your use cases. And there are a couple of common policies. Generally, some schools say, all right, you can have account access up to one year after you leave the institution. And we also offer you the option to migrate elsewhere, to pick up your account and move it to any other hosting company that uses C-Panel and C-Panel is industry standards. So that's a lot of them. Reclaim is one such company. Move to reclaim. We have no bias here. Totally, totally objective. Another option that we've seen is you keep it for up to one year or period of your choice after signing up, which would be appropriate for those coursework based use cases or for a sandbox space where you say, hey, you have one year from the time of sign up. And after that point, we're going to clear you off. You have one year to do what you want and then you can pick up and go as with the previous example. If you like what you've done and you want to keep it, but you can't stay, you don't have to go home but you can't stay here essentially. Or you might align it with single sign on and this would sort of dovetail with the account access thing. If your institution has a policy of your single sign on access expires six months, eight months, a year after you leave the institution, then because single sign on is used in order to access your domain of one's own account, a user who no longer has single sign on options won't be able to get it. So that's also a good touchstone for if you're saying, all right, you get to keep it for X amount of time after you leave. Well, if people can't sign in six months after they leave, then that's a pretty good place to start determining your timeline for how long you would keep an account for them. Absolutely, we've seen a lot of schools work with the SSO option for deprovisioning accounts. A lot of times the timeline is long enough for folks to communicate to the users to let them know what's going on and the students have time to prepare their account to move to another service to maintain their domain and identity from there for sure. Yeah, definitely. Meredith, did you wanna talk through this policy? Yeah, of course. So within the indefinitely policy, this means you're not maintaining, removing accounts after a certain amount of time, you're just kind of keeping them in place on the server based on the options there, but you can see an infinite growth happen pretty quickly where as the project continues on, it grows larger and larger, more media is embedded in the site and more visitors coming to the site itself. So a lot of times this indefinite policy isn't recommended because you can see quickly that account management can be a bear and you can see impact to other accounts on the larger accounts. And we're talking, we're getting up into the gigabyte's worth of space. So kind of setting that package limit also helps with the indefinite option because that way you can kind of track how large an account grows and put a stop to it if needed on that side. It is good to maintain any longer term projects if needed as well. Yeah, I would also say that just thinking back to that idea of what applications you're willing to support, are you continuing to offer support for these accounts indefinitely and how does that scale if you're potentially going to have infinite accounts on your servers don't recommend that, what kind of strain is that gonna put on you when you try and just support users with those accounts? Absolutely, for sure. For sure. All right, so in addition to the indefinite policy there's what's called the unused policy and this is based on information gathering that you create that you add through either logins or disk usage on that side. So the WordPress portal has a last login plugin that we set up that tracks based on the sign-in to the WordPress portal itself. It also is generated in what we have a script that generates a CSV file with this option. It tracks based on your SSO sign-in as well so you can see when a user last logged in. So if they signed up maybe in January of this year and you're tracking over the summer but they haven't logged in since January it's probably a good tell-tale that the account isn't necessarily used on that side. You can also look at the disk space. So account, like if account has megabytes worth of data on it it's more than likely just a blank account that you can remove. Yeah, exactly. And the last login script in addition to that sort of last time they logged in does include some data on how large an account is. So it's particularly useful for being able to filter through that data. And if you have multiple criteria that you want to apply that helps as well. Absolutely, awesome. So now that you've set all of your policies now when do you check them to make sure that your accounts are tracked to remove from the server? If you're working with the graduation or departure workflow you can either do this once or twice a year based on the graduation schedule during slower times of the year. So throughout the summer or throughout the winter break that's a good point. One year after creation you can say hey we're gonna remove any account in July. That is close to a year old. You can also use the account creation dates in WHMCS as a good tell. And you can even make that like a monthly sort of workflow if you'd like or quarterly, quarterly is more recommended. So you're not making too much work for yourself on that side. So maybe quarterly. The unused option is a little bit more consistent or needs a little bit more attention in consistency where you set times to check in. So again that maybe once or twice a year quarterly whatever you feel works best based on the account numbers you have definitely recommend setting a specific schedule for the unused option for sure. Absolutely. Cool. And with this workflow you can kind of get a sense of how accounts kind of end up like what size the accounts end up being and that sort of thing. So typically like is a WordPress site hovering around two gigabytes, three gigabytes. And then occasionally you'll find that you have a larger account that could be a larger project longstanding project and that sort of thing. Some like if you find that there are accounts that are becoming increasingly large you can track that through maybe like support requests or any of your disk usage checks. Good tell tell sign is that if the bandwidth usage increases that means a lot more visitors are going to the site. The best recommendation there is to offer migrating to another service through reclaimed shared hosting or a virtual server, all that good stuff. And even optimizing the website to help bring the size down to maintain the account. You can offload images to another service like through Flickr or Amazon web services that's three storage, all that stuff is good. And a caching plugin is gonna be your best friend at that point that will help speed things up for users when they're loading or visiting the site. Also help decrease the impact to other accounts on the server. 100%. Yeah, this is part of what we were talking about at the beginning with regards to like the policies that you set of once you hit five gigabytes if you really need to go larger, you can't. You need to, we'll figure out a place for your project to live, but it's not fair to the other users on the server or you better have a really good reason. This is a major academic project at the institution, something like that. And even then, Meredith, as you were saying, the bandwidth for a particular account, the more traffic that it's getting, the more that can impact the user experience both for the particular account in question and for other users. So sometimes having it live in its own home means it can get more resources as it needs. Absolutely. Awesome. So when you shift into the removal process, you're gonna start with your gathering of information and you wanna look for a list of your accounts that are on the server. You can work with us to get this list or through the last login script. We do also have an installation on application script that we can set up and run for you on request on that side. And then there's also a general CSV file that you can get from WHM. You can export a list of accounts through the list accounts page on your root access. So let us know if you need any help on that side on getting a list, we're happy to help out there and we're gonna share resources on the last login script, general best practices and all that stuff as well. So it'll be really helpful. Yeah. And once you have your list, we do have some recommendations on managing, the managing this to pair down as much as possible based on what you wanna remove. We do have an automated script that is based out of the CSV file. So we wanna make sure that we're saving that as a CSV. Also using the email address associated with the account, but making sure to note that if the account has multiple accounts or if that email address has multiple accounts associated with it, you wanna make sure to note those because our script does not differentiate between multiple accounts. It wipes based on the email address. Yeah. The idea of being, if a user is leaving, then well, their emails going away. So that sort of thing. Absolutely. So that's important to make sure to flag if needed. So that way if like a longer research project is happening or a club account, like a student club has an account on the server, that way it's maintained and they don't have to rebuild the site once the semester starts again from there. So once you have the list set up and you have it organized based on the email address and noted the accounts that you don't need or the email address that has multiple accounts, send the CSV file our way. At that point, you can set a timeline for how long you want the process to go. We recommend suspending the account first and then terminate the account from the server after a couple of weeks, months, how long you wanna maintain that. So typically we see sometimes two weeks, sometimes one month suspension and then I'll terminate. This way if for whatever reason there's an error in the script or the student comes back to the school or whatever policy you set and the user notices their account is suspended, they can reach back to you and let us know that the account is still active. That way we can save the account if needed. Once the account is removed from the server, we keep backups for 30 days through Jet backup. So within that window, we have time to restore the account. So it's important to let us know what the timeline is that you'd like in regards to suspension and termination on that side. Then you'll also wanna communicate to the users on the list using the mass email tool in WHMCS with client groups is actually really handy and really helpful to knock it out right away versus sending an email individually to each user. And let us know if you need help with any client groups or anything like that. We have scripts. We do have scripts. Absolutely, so we can help you set up those and then the email tool will be very handy. We use that a lot. In that email, we definitely recommend that you send them resources on what to do. So that includes like moving to reclaim if you wanted to continue your domain name, what backup options you have, if you wanna just keep a copy of your account locally or you wanna take it to another hosting company and all that good stuff. So we have a guide on the language to use when you're writing this email to the student. So it's really helpful to have a good base template if you need to on that side. And we'll be able to share that at the end of the slides and then I believe again in chat, probably. Yeah, absolutely. Yeah, and if you do have any other questions during this premiere as we're talking, definitely let us know in Discord that we can take a look for sure and keep the chat going. Once we have that list and you determine that timeframe, the magical script comes in that our infrastructure team has created and we process that list through WHM. And then we set our timelines internally so we can follow up and make sure that the list that you have is still correct within the ticket and then we process from there. If you find that the list is very small and you wanna maybe take this on yourself, first of all, don't feel like you have to, we can definitely help you with all of this. If you have like one or two accounts you wanna remove from the server, we highly recommend that you use WHMCS for this. That is gonna be what communicates to your WordPress portal and WHM. So that way one, if the user ever signs in for whatever reason, they're prompted to the right spot and move to the right spot to restart their account or know to reach out to you for more help on that side. And leave the record of WHMCS in the account if needed, that will help us track down where it could have gone. But if you have any questions about the process of removing accounts on a one-off basis, definitely let us know too. But don't feel like you have to do this all on your own with our scripts, it's so easy, for sure. Awesome, so we just have some more information on resources, our general account cleanup category within our Hope Center, how we gather data within the unused policy setup and more migration information and the language used to send account notifications when we're removing accounts. This will all be posted in Discord so we can share the resources there, for sure. Yeah, so I'm just thinking through, it looks like we have maybe a couple of minutes, so I'm gonna keep you here, Meredith, you're my prisoner. And just talk about those communication timelines in terms of what a shorter timeline versus a longer timeline might look like. So that suspending accounts for two weeks and then terminating, suspending them for a month and then terminating is, I think, often what we see used with schools that are using that sort of unused method, the idea of, hey, if you're not using this, we'll send out an email that says, by the way, we're getting rid of this and if you don't notice after a month, that's kind of on you. Whereas for schools that are deprovisioning with people graduating, they might start a couple months in advance communicating and saying, all right, if you're graduating in June, we're sending out an email in March to tell you, if you're graduating in June and you want your account, you gotta take it with you. And then we all know that people don't read their emails and so you send another email in April and then you send another email at the start of May, I said graduating in June, but you send maybe a couple of emails that says, here's how you take your account with you if you wanna take it. Reminder that we will not keep it for you after this point. Here's what your timeline is. And so depending on what policy you have in place, different communication styles and timelines may be more appropriate. Absolutely, yeah. And it does take a couple of cycles of account removal to kind of get that base down. So again, like all of these policies are definitely really customizable to what makes sense for your institution, your domain of one's own instance. So we don't like to necessarily say, this is the way to go. And we've seen with other schools, the longer that they've been around, they've changed their policies to allow them to adapt to any need that they might have throughout the termination process or removal process for sure. Yeah, absolutely. We never wanna be prescriptive about this, really the whole point of this conversation is like, there's so many options. And even within those options, there's a lot of different ways to customize what you're doing and think through what makes sense for you. We don't have a set way of doing it because we know that everyone's got a different situation and a different management style that they wanna go with. Absolutely, yeah. Awesome. So as we've got the couple of minutes left, keep adding those questions into Discord and we'll keep chatting through the process and any questions there. But as sort of like a kind of a final thought process, having a little bit of policy upfront will definitely help you keep track of accounts and make sure that the account management side of things is a little bit easier for you as you grow. It helps you keep the project scalable and manageable within your group so you're not taking on too much at once. Take advantage of reclaim automations. We have our CSV scripts that help remove accounts from the server, mass mail tools, adding client groups. We're here to help you go through the base of getting accounts removed. So as you're getting set up and all of that good stuff and also putting out there, keep talking in Discord again, we can always go through examples of different timelines, different policies that schools have set up. So let us know what you've got for your school and we can definitely highlight those as well. Yeah, and if you ever write in and say, I think it's time, but I don't know what to do, you can just send us a support ticket and we can talk through your options with you again just think through in your particular case, what sounds good? What sounds reasonable? We're happy to have those conversations. For sure, awesome. That was account management and cleanup and we'll keep chatting in Discord for sure. See you at Discord. See ya. Bye.