Name: Sophos Endpoint Windows Installation: Troubleshooting Common Issues
Uploaded: 2025-06-25T15:30:04.562Z
Duration: 49 min 45 s
Description: Sophos Endpoint Windows Installation: Troubleshooting Common Issues

Transcript for "Sophos Endpoint Windows Installation: Troubleshooting Common Issues": Hi, everyone, and welcome to today's session. I'm Justin. And today, I'm joined by Kushal from our Sophos community support team. Kushal will be behind the scenes for the most part to help answer questions during our q and a. We're also joined by Aman from our digital customer marketing team who will help coordinate things backstage. Whether you're a new user or a seasoned administrator, this session aims to provide clear and practical guidance for troubleshooting installation issues. Now before we get started, I do want to mention that today's session is being recorded. So if there's any content that you'd like to revisit later or share with your team, the recording will be sent out to you and will also be available on the Sophos community. At the end of today's session, we'll have a live q and a, and we encourage you to use the Q and A feature to ask questions throughout the presentation. You can find this on the top right as a separate tab next to chat. We'll address as many of these questions as we can during the live session, and if we're unable to get to your question today, we'll include them in a follow-up post on the Sophos community. You can access and join the Sophos community at community.sophos.com. It's a dedicated place for you to connect with Sophos experts, get your technical questions answered, stay informed on the latest releases, and access additional valuable resources. Lastly, a survey will be sent out at the end of the session. We greatly appreciate it if you could take a moment to fill it out. Your feedback is appreciated and would help us improve future webinars. Now our agenda today begins with a brief overview of the installation process, then we'll follow-up by analyzing the logs and cover some of the common issues that you might see. After that, we'll discuss the resources available to you and where you can find them before wrapping up with our live q and a session. Now let's get started by going over the installation process. When you download the installer file from Sophos Central, that installer is stage one. Stage one contains information about the server it needs to connect to for communication, a registration token to identify which central account to connect to, and information on where to download stage two, the rest of the installer. Including information about where to download stage two rather than including it in the installer allows us to ensure that the latest installer is used regardless of how long ago you downloaded Sophos setup dot exe from Sophos Central. When stage two runs, it will perform a prerequisite check. And if you choose to proceed, the installation will start. Device the device will register to Sophos Central. It'll grab an update policy, download files, and run the individual component installations. Now let's take a look at what a manual installation looks like. When we download the Intercept X Windows installer on Sophos Central and run it, most of the steps we mentioned occur in the background. Initially, it'll download and extract out stage two really quickly, then it'll perform a prerequisite check and pause. You can then click install to continue with the installation if no errors come up during the prereq check. After that, you can see the installer register with Sophos Central, then download a bunch of files, and then finally, it will start some installations. When finished, we will be able to see the Sophos UI icon on the bottom right hand side on the taskbar. Sophos we could see the installation succeeded here. I'll just go ahead and show you, on the bottom right, we should see the Sophos shield. And if you double click that, you could see the device is protected. Now that covers the, what what what would happen during a, successful installation. Now let's go take a look at the logs that it generates. Now jumping into the log analysis, whenever you run Sophos setup dot exe, a log file is generated that includes all these steps performed. This file is saved in c program data, Sophos cloud installer logs, and the name of the file is the date and time stamp. So you can use this to identify when the installer was run on the device, if you're deploying itself via group policy or software manager. This can help you identify if there's an issue with the installation or the deployment of the installer file. If no log is generated, then Sophos setup.exe was never run on the device. Then you'll want to investigate your deployment software or software deployment, tools to identify why the installer is not running. Now when we go ahead and open up that Sophos cloud installer log file, you will see a lot of, log entries. We'll see command line switches that were run, with the installer along with the whole process of the installation that we mentioned earlier. When analyzing the logs, the formatting of the logs will always be the same. It starts with the year, month, date, followed with the letter t for time, and then you'll have the time in hours, seconds, and milliseconds. This is then followed up with the letter zed for Zulu time zone, and then you'll be able to see the severity level and the line entry details. So in our example here, we have, year 2025, April 8, and the time that this was, this log log entry was generated was, zero zero fifty one eighteen in Zulu time format. Severity level is info, and the message of the line details is response status code 200. I do want to mention as well any references to specific paths like this, c program data folder, will be included in the Sophos community host. Now let's go ahead and open up the logs. So if we go ahead and open up Windows Explorer, we can navigate over to the c drive, and the program data folder will be hidden by default. So in order to see us, we will need to enable view hidden items in Windows Explorer. Go ahead and click view on the top panel and then check the box for hidden items. Now that we're able to see the program data folder, we'll want to navigate into it. And then once we're into the program data folder, we'll want to click on Sophos, cloud installer, and then logs. If you don't see the Sophos folder, it would indicate that the Sophos setup dot exe was never run. If we go ahead and run Sophos setup dot exe, you will be able to see that a new log file gets generated even if we simply exit out the installation. So here, we can see a new Sophos, cloud install log file. And, we'll just go ahead and close out the installer here. But what you will notice as well is if you take a look at that file size, you will notice that it's substantially smaller than the, previous one. And that's because there's not much data in it since the installation was not proceeded with. Now if we go ahead and open up the Sophos cloud installer log file, where we've proceeded with the installation, we can see a few things from the start. The first few set of lines indicate if any special parameters have been used, such as if message relays were specified or if the installer was run silently. We can check the line stage one command line options to see what command line switches were used and to identify if there were any typos that were made. If we scroll down, we can see stage two being run. And further down, we'll be able to see the prerequisite checks. The prerequisite checks will be seen as running system check, and we can also see if they have passed or failed. Shortly after, the device registers with Sophos Central in the line, parsing message received for deployment token over here. And this token identifies which central accounts the device will register to. Now we go ahead and scroll down even further, we'll see a lot of get requests and syncing package messages. And this is the download of files needed for installation. You can see the specific files being downloaded, how long it took, and whether or not they are successful. A 200 indicates successful, and these are HTTP status codes. So if you see any code that you're not familiar with, you can perform a web search of HTTP status codes and get a table of what each code means. Now if we go ahead and scroll down further, we will see, or will we will get down to a section of the log where the files are being decoded. And this is the process of extracting out the downloaded SIFT contents into their usable formats. And then finally, if we scroll down even further, we will be able to see, a lot of installing component log files. And this is where the individual component installations take place. And the reason why I'm showing you these log entries is because it could be useful to identify where in the installation process a failure may have occurred. Each step of the installation requires the previous step to have been successful. So for example, if there's an issue with the download of files, then there there would be no component installation log attempts in this log. Likewise, if there are problems with the device registration with Sophos Central, we will not see any information about the download of files or the installation of the individual components. Now let's go ahead and take a look at the cloud installer logs of a device that failed to install. As we saw earlier, before, the log is rather large and to be rather inefficient to analyze the logs line by line. Instead, it's best to use keyboard searching to locate where the installation went wrong. Since the log has severity level for every line entry, we can use this to find out exactly where something went wrong. Log levels or log lines can have a severity level of info, warn, or error. We go ahead and control f to find a notepad. We can search for the keyword error. What we're looking for is a log line with the severity level of error. And if you encounter any lines with the word error in the message, such as these, but the severity level is info, you can generally ignore them. Although the line with the severity level of error is important, you'll also want to read the lines above and below it to try to gather some context around what the installer was doing before and after the failed message. An error may be caused by a previous error, so generally, you'll want to find the first error that comes up in the log. Additionally, if it appears that the installer moves on from an error, it may be a benign error that is not the cause of the failed installation. So you might want to investigate other, log lines with the severity level of error. Now that covers the log analysis. Again, I just like to send a reminder. If you have any questions, feel free to drop it in the q and a section of the, session on the top right. And we will now go over some of the common issues that we may encounter. Now let's go ahead and run through an installation with an issue endpoint. Now when we run the Sophos setup dot exe, notice how the prerequs prerequisite check fails as it cannot connect to Sophos Central. Now this is rather odd because this device does have access to Sophos Central. And we can prove this simply by opening up a web browser and trying to access central.sophos.com. Here, we can see that we're able to connect. So what's going on here? Now as with any installation, what we'll want to start off with is by looking at the installer logs. So let's go ahead and open up Windows Explorer and navigate to c drive, program data, Sophos, cloud installer, Logs. Now if we go ahead and open up the most recent, install log, we can control f to use the find feature and search for that keyword error. The first error line that comes up says, failed to validate server cert terminating HTTP connection. Now this gives us some details on what is failing, but we need some additional context. So reading the log line slightly before the error, we can see the line opening connection to m c s two cloud stationuswest2.prod.hydra.sophos.com. So we know that the installer is attempting to access this address. The few lines under it mention subject certificate failed validation against root CA, and that includes Sophos CA one, Sophos CA two, SOFA SHA two fifty six MCS root CA three and CA four. So based on these log lines, we know that the installer was trying to access a specific address and the root CA's that are being validated. We can go ahead and try to simulate this connection by opening up a web browser and attempting to connect to that exact same URL. So I'll go ahead and copy that URL and then open up a web browser and paste it into the web browser. So in the URL, I type h t t p s colon forward slash forward slash and I'll paste the URL and it returns with a five zero two bad gateway. Certificate verified failed, self signed certificate, and certificate chain. Now if we click the icon to the left of the URL, we will be able to see some additional context on what's going on. Just click connection is secure, and then click the certificate is valid. This shows us the certificate that is being presented by the website. And what we want to look at here is the issue by. We can see that this certificate's issuer has a common name of MITM proxy. If we remember from the error in the logs, there was a subject certificate validation for Sophos CA one, CA two, Sophos shell two fifty six MCS root CA three and CA four. These are none of the expected certificate signers and indicates that this traffic is being HTTPS decrypted. When HTTPS decryption happens, the certificate is replaced, which causes the signer to change. Now if we go ahead and do a quick web search for Sophos domains and ports, we can find a documentation page aligning the domains and ports that need to be excluded. So here, if we go ahead and scroll down, we'll get all the, paths that need to be excluded. Ensure that all your proxies or firewalls in your network are not decrypting this traffic. So I have a simulated, HTTPS decryption going on here. So for me, I'm going to, turn that off so our traffic is no longer being decrypted. And then once everything is configured properly, if we try to navigate to that URL once again, we will get a your connection is not private page, and this is expected behavior. If we go ahead and click the icon, the not secure button next to the URL, and then click on certificate details, we can once again look at this issue by. Now we can see Sophos Shell two fifty six MCS root CA three, which is one of the root CA's listed in this, installation log. So this all looks great, and we can run the installer, the Sophos installation once again. So I'll go ahead and go and run sophossetup.exe. And what you will notice is that you will no longer get this connection error message, and we do have the option to proceed with installation. So proceed with the installation. And once again, if everything is successful, we'll we'll be able to see the Sophos UI icon on the bottom right. Then we double click that. We can see that the device is protected. Now let's go ahead and move to another common scenario. When we go ahead and run through the installation, we will get a failure message shown on the UI here. So So we're able to proceed to pass the prerecords check. And here, it fails out. Once again, we'll want to first go into the Cloud installer log to see what happened. Do a keyword search for error, and let's try to find the log lines with the severity level of error. Here, the first log or the first error line that we can see, the line itself does not provide much information, only stating s u setup exit one. However, if we read around what happened before the line, we will be able to see a line stating installing component, Sophos malicious traffic tech traffic detection 64 bit version 2,025.1 dot nine zero two. And along with that, we can also see another line that says failed to install product NTP sixty four twenty twenty five dot one dot nine zero two. Now this gives us a pointer on where to go next. And note that when Sophos calls the individual component installations, they each have their own installation log. These will be in a separate folder, either in c windows temp or percent 10% depending on if the installation was run by a startup script or locally run by a user. Since I did run Sophos setup dot exe locally, I'll go ahead and navigate to the temp folder and then and then try to find the logs for this n t p 64. So I'll go ahead and open up Windows Explorer for type percent temp percent and sort by date modified. As we know NTP 64 is what failed to install, we'll go look at the NTP, or network threat protection install logs. If you're uncertain what acronym the component is for, you can always look at the version, as it'll always match match the version name mentioned in the log of the file. Now in this log file, we can see the same formatting for the most part. However, the severity has been shortened to I for info, w for worn, and e for error. We'll keep out an eye out for any lines that have the severity level of e. Now we can perform another keyword search for the word error again, and we will find a bunch of log lines, with the severity level of e here. The first line says, start service, failed to start. The dependency service does not exist or has been marked deletion ten seventy five. The Sophos Network Threat Protection service has a bunch of dependencies. If we go ahead and look further down the logs, we can see the SNTP service dependency information. We also see the line, information for service BFE could not be accessed. Error message, the service registry key is missing. Now this tells us that the BFE service could not be accessed, and a quick web search of BFE service would indicate that this is the base filtering engine service. This Windows service is a core service within the Windows Filtering Platform, or WFP, and manages firewall or IBCEC policies by filtering traffic at the user mode level. If we go ahead and open up services.msc on the local computer, we can also find that we're unable to locate the base filtering engine service. Now this service should be on every Windows machine by default, and this may be missing from a previous malware infection that has removed the service to prevent detection. The malware may have been removed, but it's possible that the destructive steps taken by the malware to avoid detection were not restored. We need the base filtering engine service to be running in order to install and run our network threat protection service. To restore this, we will need another machine of the same build. So if your machine with the issue is a Windows ten twenty two h two machine, then you'll want another Windows ten twenty twenty two or 22 h two machine to grab the base filtering engine service off of. So let's go ahead and navigate over to a Windows ten twenty two h two machine and go ahead and open up the registry editor by searching regedit.eac. Navigate to this following location, and once again, any path that we mentioned in this webinar, we will include in the fall of the community post. So go to HKEYLOCALMACHINE, SYSTEM, current control set, services. If we scroll down to BFE, we will have the option to right click BFE and select export. We'll want to provide a name to this key, and then once it's saved, we can copy this, this file over to our issue machine. Now on the issue machine, if we run this file, we can restore the base filtering engine service. Note that it is absolutely important that you grab this key from a machine of the exact same build. As if you try to restore the the key from a different machine, such as from Windows 11 to Windows 10, it can cause many unexpected issues, such as not being able to connect to the LRDP. Now once this is restored, we will need to grab permissions to this key. Navigate over to the registry editor, and the key is going to be in the same path. Simply right click that BFE and select permissions. Click add, and then type everyone. Grant everyone full permission or full control, and then click okay. Now for our changes to take effect, we will need to restart our computer after importing the registry key. So go ahead and restart and get back onto the machine. And after restarting, we can open up services.msc one more time to ensure that the base filter engine service is there and running. And we can see that is the case. Now that the, prerequisites are in place, we should be able to complete the Sophos installation. And this will happen on either the next Sophos endpoint updates, which will happen within an hour, or you can force it to update manually by opening the Sophos UI, going to the up out on the bottom right, and clicking the update now. Now you'll see the update status switch from a failed message to a green check mark to indicate a successful installation and update. We can also see in the status tab, once we we give it a little bit of time, your device is now protected. So this indicates that we now have a healthy machine. Now let's go over to, one other issue that is rather common still, and let's hop on to another machine. Here, we can see what happens when we attempt to install Sophos endpoint on an older Windows 10 device. We will be able to see that the pre prerequisite check fails, and we get a message that's saying Azure code signing is not supported. We're told to update the computer before installation and to check the Sophos KB. If we go ahead and open up the cloud installer logs, we can search again for the severity level of error, and we'll see the exact same information that we saw in the UI of the install installer. If the software was run silently or pushed out silently, to be deployed out, we can see what went wrong in these logs. We can go ahead and bring up that KB article as this will provide us with more information about this error. So we'll go ahead and, drop that into a web browser search, and we can find the KB article here. Now in order to comply with Microsoft's Azure code signing program, Sophos must sign user mode portable executable files using the Azure code signing, digital code signing certificates. The problem is that operating system support for Azure code signing was first made available in September 2021, and it requires the appropriate Windows security updates to be installed. If your Windows devices do not have the required updates to support Azure code signing, our installer won't be trusted and cannot run. And you'll need to make sure that your Windows devices are up to date with the latest Windows updates. Along with this, you'll also need to make sure that your devices have the Microsoft identity verification root certificate authority 2020 and its trusted root certificate authority list. So for this, you will need to to verify, whether or not your device does have the certificate. And in order to do so, you can open up Microsoft management console by pressing Windows key r and typing m m c. On the top left, select file, addremove staffing. Select to add certificates, then select computer accounts, then select the local computer, just hit next, and then hit okay. Go ahead and expand up the certificates, and then expand up trusted root certification authorities, and then click on certificates. Look for Microsoft identity verification root certificate authority 2020, And this should be here by default if your machines are up to date with, updates. But if it isn't, you may have automatic root certificate updates disabled on your group policy. I'll go ahead and pull up another machine that is up to date, and we'll go ahead and go through the exact same steps where we bring up MMC to look at the certificates. And we will be able to see, once we expand up the trust root certification authorities, that the, this specific cert is available here. We can see the issue and everything too. Now to verify if automatic root certificate updates are disabled locally on your device, you can open up the registry editor, and this key is located under h key local machine, software, policies, Microsoft, system certificates, auth route. If you happen to see a key in this location named disable root auto update with a value of one, then this device is not automatically updating root certificates. Now Microsoft distributes a list of companies and organizations that it considers trusted authorities, and then this list is maintained through Windows updates. If you are maintaining this list yourself, you may have this disabled. However, we do require this CA to be trusted in order to function. We do have a link to the Microsoft PKI services in the knowledge base article for this issue. So you can go ahead and download this certificate and distribute it over to your endpoints. You can distribute it via various methods, such as running it on the local device or pushing it out via a group policy. If we click on that CRT file, we can go ahead and download it. And if I open it up, there is the option to install the certificate, onto the local machine, and this will automatically be placed in the trusted root CA's list. If we go ahead and just refresh the, MMC here, we will be able to see that, Microsoft, identity verification root certificate. Now should you have any issues with our product, know that Sophos support is available to assist 247. You can contact us via the Sophos support portal, our Sophos chat support, or call in. If you are calling in, ensure that you have access to the machines with the issues so that we can help investigate. If you're raising a case via the Sophos support portal, we will often ask you to collect the Sophos diagnostic utility log, also known as an SDU log, on the issue machine. It will be helpful if you have this before raising up the case so then we can start investigating immediately. The SDU log contains all the logs related to Sophos on the endpoint that it was run on, along with any system details. This can be extremely useful for troubleshooting issues as it provides our technical support team with most of the same logs as if we are on the machine itself. To collect the SDU log, simply go ahead and open up the Sophos UI on the bottom right, and then click the about button on the bottom right. Then select the open endpoint self help tool, and then click launch SDU on the bottom left. This tool will collect all the Sophos logs on the machine. So we click start. It starts collecting all the logs. And once complete, we will have the option to submit and upload this to Sophos. So here, the, collection has completed. Submit's on the bottom right. And then we have the option to upload to Sophos. When we click on that, it will upload it to Sophos and save the SDU URL into your clipboard. And this URL should be included in your technical support case. Technical support will be able to download the logs with the URL to help troubleshoot your issue. But do note that the logs will not provide any information or context about your issue, so you'll also need to describe what issue you're encountering to your, to Sophos support. You can also generate an SDU directly on Sophos Central by navigating over to that device, clicking on more actions, and then click diagnose. If we go ahead and run, we will start the Sophos diagnostic utility tool. And once this completes, you will be provided with a file name at the bottom of this device's overview page, And all you need to do is just copy this, file name and include it in your, tech technical support ticket. Now as we wrap up, I do want to highlight some of the additional resources that are available to you, and we'll include links to these resources in the chat as well. First, take some time to join the Sophos community at community.sophos.com. This is where you can engage with Sophos staff, including our support and product development teams, and even customers and partners. The community is a great place for you to get your technical questions answered, share insights, and get guidance from the people who help build and support Sophos products. The Sophos assistant provides guided workflows to help you complete essential configuration tasks in Sophos Central and Sophos Firewall, ensuring for a smooth setup process. Visit the Sophos support portal at support.sophos.com for easy access to product resources, knowledge based articles, documentation, and much more. In the support portal, you will can also access our Sophos chat support for real time help from real experts with all any phone queues. Whether it's a quick question or a technical hurdle or a product query, our chat support specialists our chat support specialists are just a few clicks away. Just click the log in to chat button to get started. You can sign up for product and system alerts, including maintenance schedules and any urgent notifications on outages at status.sophos.com. Finally, if you're looking for troubleshooting guides, product demos, or foundational knowledge, check out Sophos Techfits at techfits.sophos.com. Our extensive video library offers step by step tutorials to help you maximize the value of your Sophos products. Now that concludes our formal presentation. And now I'd like to invite Kushal onto the stage as we open up the floor for any questions that you may have. We'll also go over any of the questions that were submitted throughout this presentation. And if we're unable to answer any of the questions today, we will ensure to include them in the follow-up post on the schools' community. Alright. Thanks, Susan. So the first question that we have here, the biggest issue I have with Sophos is if a computer is not communicating for ninety days, then it will fall off and until it gets deleted, thus breaking the PC. If the computer is back online after ninety days, it will not get any updates from Sophos, and you can't simply uninstall it. So for this one, I do believe that we have rolled out a feature by the name of back off and terminate, which will essentially disable tamper protection on a device, after it has been powered off or if it has not checked in to Sophos, for a given period of time. We do have some additional information on this feature. Not quite able to, pull it up right away here, but we will try and include that in the, in the follow-up community post. Justin, would you happen to know if there's a particular, core agent version or something that we need devices to be on for that feature to operate? Yeah. There is a specific version since we did release this, in the specific version in the past. I don't exactly remember the the version, but we we can include the documentation. But, yeah, like you said, this has been a major pain point in the past, and we have released a, a feature to essentially solve this issue. So, going forward, you if your machines are up to date, you should not have to go through the whole, registry or safe mode or anything like that anymore. It should be a simple uninstall. You can just run it normally. That's right. Yeah. Okay. And the next question, the gold image setup switches do not seem to work properly. We constantly get duplicate systems even when using the switches. For this one, did you wanna try and fill this one, Justin? Sure. And then if you have anything, you can definitely chime in as well. This is probably something we would want to investigate further. It should work. It could be, either there's a step missed, which I don't think would be the case here, or the golden image setup process might be performing some steps that we don't expect, and then the device might start registering before it fully completes the setup process. So what I'd probably recommend here is just reach out to support. We'll probably want some logging as well, like that SDU log that we mentioned earlier. And we'll want to just investigate and maybe try to recreate the issue as well to see where in the process, it's going wrong. Mhmm. There is, a wait period that happens once you have finished running the gold image installer in the with the switches. So if the registration happens, as Justin mentioned, before that wait period has elapsed, then that could cause the issue that you're you're experiencing there. Working directly with Sophos support is is definitely the best best course of action if, if you're having this issue specifically, though. Yeah. The thing I'm I would probably keep an eye out for is, during that registration process, the the devices should have a different name at that point. If it still has the original gold image name, it might be detected as a duplicate device. So in this case, yeah, I'd reach out to support. We can probably figure out exactly where it's, going wrong and find steps to mitigate that. Very good. Next question here. Does the installer have any dependencies, or do I need to install anything myself before installing on my Windows device? Yep. Kushal, I'll let you take this one. Oh, sure. Yeah. So we do have some prerequisites listed on, our website. You could just look up Windows endpoint, minimum requirements, and, essentially, that'll just give you an idea as to the hardware requirements, disk space requirements, as well as what that, Justin had demonstrated in terms of the, Azure code signing being a requirement. That that's the usual issue that, we encounter most frequently. But if anything does come up, the the installer will let you know what's going on. And this would demonstrate in session there. You can always have a closer look at the logs to find out more information. Yeah. I believe it's just these, system requirements. We need those all those domains and ports to be excluded. Yeah. Again, those dependencies, I don't think we have any, but if there, were such as, like, the Azure code signing requirement, it will pull it will show up in that prerequisite check. So if you are installing, yourself, I do recommend you at least, do it manually on one of your devices before you push out to the rest of your, devices. Just so if you have an issue, it's, like, right there on your face. You could fix it, on the rest of your devices before they all become an issue. Mhmm. That's right. The next question I see here, where can I download these certificates if my device doesn't update automatically? I believe this is related to the certs that you were demonstrating or kind of navigating through during the session there. Yeah. I think that is referring to the Azure code signing. Mhmm. So on this KB article, again, this is the same KB article that is presented if you do fill that prerequisite check. But in that PKI repository, this is where you could download those certificates. So the one we're looking for specifically was that, Microsoft identity verification root certificate authority 2020. And if we go into this, we can scroll down or just do a keyword search as well. It's somewhere down here. Right here. Okay. And the next question I see here, is there a reference guide to the different types of errors we can expect, and how to resolve them? So for this one, we don't have a specific cheat sheet that has sort of, like, common errors or issues that you can encounter. But, for this type of question, I would suggest going over to the Sophos community. You'll find lots of other customers and and users have encountered similar issues in the past, and we usually interact with them on the on the forums to sort of provide suggestions, additional troubleshooting assistance. And more than likely, you'll be able to find, a similar port, maybe even the exact same issue you're experiencing that, somebody has mentioned previously. So do check out the Sophos community. Nothing for me to add there. Alright. I do have one more question here. What are the best practices for setting up Sophos using a deployment provisioning software like Intune or Autopilot? When redeploying machine, I sometimes encounter duplicate entries with the same name but detected as different machines. Is there anything I can do to avoid that? Just give me a moment. I'm just rereading this. If you have anything to add, go for it. Mhmm. Yeah. Usually, this should not be the case. Typically, when you are redeploying, Sophos onto a endpoint, usually, you would just see an event entry that states that the device has been reprojected. So I would be curious to find out if, maybe something with the, OS version or if any major system changes are happening between the time that the device was previously protected and when it becomes reprojected. Now do you know off the top of your head if there are any, key identifiers that are used on the on the Windows device to determine whether it's the an existing system or a new one? Not that I'm aware of. I believe so during the registration process, it pulls a lot of variables in order to generate a unique identifier for the device. However, if all those parameters match up, it would generate the same identifier again. So it it's possible that, either I I'm trying to identify, what this means when it's when you're saying you're encountering duplicate entries with the same name. And if it's, actually showing a message saying it's a duplicate device, then it would indicate that you are it's getting the same identifier. And in in that case, we'd probably want to look into, like, code image, KB article. There's some steps to try to prevent that. However, we're seeing, like, a second entry in Sophos Central with the exact same name for the same device. Then it could be that the identifier is not being recognized as the same device. And now we're looking into, some parameters changing when it's reregistering. Right. Maybe we can try and find some, some of that information internally, and then we'll see if we can include that in the follow-up community post. That way, if you did want to have a closer look into this, you can always kind of dig into the device and and see if that remains consistent through the times that you're re protecting it. Yeah. By default, I do believe that, older devices are kind of, hidden off of the main dashboard anyways. So you can always kind of change the the sort by in the list of endpoint devices and then just remove the oldest ones, if that suits you best. But, yeah, definitely something to look into there. Great. Okay. Next question. I see there are different levels of logs. What other options are there for logs? I believe you've covered this briefly with the, error or information. It is also possible to enable debug logging, but that will require you to make some registry changes. It's also possible to go into the Sophos endpoint self help tool, and through a couple of steps, you can increase the the log level to verbose. Yep. Generally, we recommend you don't do this unless civil support is requesting it, but, or if you want some more of logging. But, generally, you shouldn't need it. If you wanted to change the product logging, you can, like Michelle said, open up this endpoint self help, elevate your permissions, and then you can just click the drop downs for these specific sections. So if you're having an issue with, let's say, auto update, we can change that logging level to debug, if that's required. But, yeah, there are a few other log levels like always and stuff. Generally, we shouldn't need to change it. Right. And one thing to keep note keep in mind is that the logs will grow quite rapidly in size. So just ensure that you have sufficient disk space and you're not going to, end up, you know, locking up your system because you accidentally left the debug logging on for longer than you expected or something. Yeah. Most definitely. So the logs get extremely large. We have seen, people forget to turn the debug logging back to normal in the past, and it completely fills up the the disk space and, you know, it'll cause other issues as well when you don't have any more disk space. So, yeah, just remember to turn it back. Make a note, either like a timer or something like that to, turn it off once you complete with your analysis. I've I've definitely pricked a a testing VM or two in my my day. Alright. The next question I see here, if the installer fails to launch entirely, is there anywhere else on the device that I could look to find out why? So Sorry. Yeah. Go ahead. Go ahead, please. Okay. Yeah. So for what I like to mention is, we did talk about the Sophos cloud install log that's in that c program data folder. If you're not seeing this run, then you want to see whether or not the log exists. Again, this log file does have, like, a time stamp and a date of when this is run. So you can kind of narrow down whether or not the install is failing to launch or if the install is running at all. If you don't see any cloud install log there, and you're just not able to find any traces whatsoever of the installer having run on the device, you can also look into the Windows event viewer logs, and just check out if, that you see the Sophos setup EXE mentioned anywhere there, or if you see the oh, we don't use MSI packages anymore, do we, for, millions of dollars? No. Okay. So, previously, what we would have done is search for, the MSI process is starting, but, that's no longer the case. Although, you will likely see some, errors, and you can also filter by, you know, the same type of, error levels, information, log worn, so on and so forth. Yeah. So there's that filter current log on the right side. You can Mhmm. Select the, levels we care about. If we hit okay, it only shows those severity levels. So you could just kinda, like, oops, kinda just go down and try to find out if there's anything thing relevant to that and, again, look at the time stamp of when you should have run that installer. Mhmm. And if you're using a deployment tool, such as Intune or, you know, if you're using scripting to deploy the installer, you could also, instead of launching the Sophos setup package, get your scripting tool to launch a different application entirely. And then when you push the script to the device, if you don't see that application start, such as notepad or something, then you'll know that the script isn't quite doing what it's supposed to on the device. So just replacing Sophos setup with the EXE with something else might be a good troubleshooting step to to take on. Yeah. It's a very good, troubleshooting step to narrow down where the issue is happening. Mhmm. Yeah. It really does depend on how you're installing them, so keep that in mind. Next question here. How does the installation change if I'm troubleshooting on macOS devices? Yep. So macOS has different set of logs, and a whole different installation process on that. You can still perform the same, keyword searching for error or fail, to try to find out what information is there. However, that's kind of past the scope of this webinar. I don't know if there's anything you wanna add more to that, Kishol. I do find that, looking into the logs locally on a macOS device is, a bit more difficult than it is on Windows, because Mac tends to just kind of house all of its logs together in one section. I would suggest running the Sophos diagnostic utility on a macOS device and then just exporting that, that zip file. That makes it much easier to really look into the logs and figure out what exactly is going on in the device. That would be my my suggestion for that. Yep. And I believe we have room for, one more question. I think I see, David sent one over. Okay. I will chat one here. If I change the name of a specific device, the host name, after Sophos InterceptorX is installed, the central update, or is there a new machine listed and the old one needs to be removed manually? Yep. I can take this one. So, if you change the name of the device, Sophos Central should receive the new information about the device. There will not be a new machine listed, and the old one does not need to be removed. The existing machine simply just updates its name in Sophos Central. So what happens is the registration process where the machine, populates itself in Sophos Central only happens during the installation process or if you go through, like, the code image steps. If it's already, deployed out, then all of the existing information that's identifiers will stay the same. So, yeah, simply changing the name just updates the name in Sophos Central. You don't need to do anything. You will just see it as is. Mhmm. You will also see an event that says host name change. If you go to Sophos Central and you check out the events and alerts tab, there should be an in informational event that says post name change there. Yeah. To kind of elaborate on what Justin mentioned there, the the device will have a unique identifier, and the unique identifier corresponds to the device entry in Sophos Central. And so those two will always sort of remain the same. So if the host name changes, that shouldn't matter. You'll still see the, the same device entry there. Yeah. Alright. So I believe that's, all the time we have for, questions. So thank you everybody for attending today. And before we wrap up, we'd love to hear your feedback. So please take a moment to fill out the brief survey that has popped up on the right side of your presentation screen. Your input is extremely valuable in helping us improve future sessions. Additionally, the recording of today's session, along with all the resource that resources that we've covered, will be available in the coming few days on the community, the Sophos community at community.solos.com. We appreciate you all for joining us today, and we look forward to connect to connecting with you again on our upcoming webinars. Stay tuned in our socials. Thanks for attending. Bye.