Obselete User Story in Sprint

If, during the sprint, we find out that a user story is no longer needed or it can not be worked on due to some external issues. Would the best practice be to leave it until the end of the sprint and move it to the backlog once the sprint has been closed, or is it okay to take it out of the sprint while the sprint is still in progress? 

@John Hayes, Consider if the below lines from the Scrum guide help answer your question.

No changes are made that would endanger the Sprint Goal

Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

If, during the sprint, we find out that a user story is no longer needed or it can not be worked on due to some external issues. Would the best practice be to leave it until the end of the sprint and move it to the backlog once the sprint has been closed, or is it okay to take it out of the sprint while the sprint is still in progress? 

The two cases are different.

In the case where the item cannot be worked on due to external issues, that would be an impediment. One of the services that the Scrum Master provides to the Development Team is assistance in identifying and removing impediments. If I were the team's Scrum Master, I'd want to understand more about why the item was selected for the Sprint if there were external issues. Without knowing all of the details in this particular case, I'd want to make sure the team had the right knowledge and techniques to identify external dependencies and make good risk assessments or mitigations.

In the case where the item was no longer necessary, I'd want to get a good understanding of how something could be added to the Product Backlog, be refined by the team, and accepted into a Sprint only to have it become obsolete or unnecessary. I'd want to see if it's still necessary, but there are higher priority items in the Product Backlog, or if it's truly obsolete and no longer ever needed in the product. If it's no longer needed, my recommendation would be to remove it and ensure the team doesn't spend effort on it or cut the losses if work has been started but it is incomplete. If it's simply a lower priority, I would make sure the team understands that but would not adjust the team's plan for the Sprint and, if it gets complete, it gets complete.

In both cases, though, the details matter. However, I would want to make it a learning experience. Both cases can be disruptive to a team and the team should have the tools to attempt to prevent these from happening.

If, during the sprint, we find out that a user story is no longer needed or it can not be worked on due to some external issues.

The Sprint Backlog is the team’s forecast of the work they need to do to meet the Sprint Goal. They should always keep it up to date and know whether the goal is achievable. What does that forecast now look like?

No amount of guides, guidelines can stop from such kind of issues to happen. In our team we were dependent on services provided by more than one external teams (which were non-agile to every possible extend). Some of our tasks would get stuck because of issues outside power of our team. Getting them resolved needed whole another level to organizational changes and time consuming. Having no immediate solution we started to have some slack stories, some additional refined stories meeting the same sprint goal.

I would suggest you need to dig deeper to find what is causing your user story to get obsolete within the sprint?

I'm going to start with a comment that there is no such thing as best practices.  Even at a team level, I find it hard to say anything is a best practice. Everything is just a thing we do now until we find a better way of doing it. 

Building on that statement...your team needs to decide what is the best thing to do every time this occurs and not create a standard way of handling it.  As everyone above has mentioned you need to determine why either of the situations occurred and make a determination based on that specific information. If you start to see a pattern, then you have something to discuss as a team on how to or even whether you need to prevent it from occurring.  I have seen this kind of thing happen due to lack of adequate refinement and because of a very dynamic problem space being addressed. The first was something we could address, the second was just something we felt had to be dealt with as it occurred. 

There are very few things in software development that has a definitive way to be done. It is a very creative process with many available options.  Technology changes fast and the way you work will have to evolve as well.  Change is inevitable so quit trying to something that will fit all circumstances.  Find something that fits this circumstance and use that knowledge for the next circumstance. Inspect and adapt doesn't only apply to requirements. It applies to everything you do in life.