У нас вы можете посмотреть бесплатно Decommissioning Software | Phase 6 of the Software Asset Lifecycle или скачать в максимальном доступном качестве, видео которое было загружено на ютуб. Для загрузки выберите вариант из формы ниже:
Если кнопки скачивания не
загрузились
НАЖМИТЕ ЗДЕСЬ или обновите страницу
Если возникают проблемы со скачиванием видео, пожалуйста напишите в поддержку по адресу внизу
страницы.
Спасибо за использование сервиса ClipSaver.ru
Learn more here: https://www.anglepoint.com/lightning-... This phase covers the steps of removing a software installation and ensuring that there is no remaining compliance risk. Every item in the Software Catalog that has been packaged for deployment should also have a corresponding uninstallation package. This will facilitate the maximum potential for automation. Linking to the previous lifecycle phase of Deploying and Monitoring, if a metering report is run indicating a specific instance of software has not been actively used for a pre-determined time period, this could trigger an automated job in SCCM that would utilize the uninstallation package. Varying levels of automation could be built in here, from full end-to-end automation, to having the SAM Team first review the metering report and sending notifications before submitting a ticket for decommissioning. It is important to remember that you should ALWAYS double check a potentially deinstalled or decommissioned application. Are there components that were not fully removed by your tool? Were elements changed in the registry? Are there third party components included with the installation that may have been missed? Best practice is to run Discovery and Inventory for the affected devices, then perform your de-installation, then run Discovery and Inventory AGAIN to ensure that all traces of the application have truly been removed from the machine. As mentioned in the Deploying and Monitoring lifecycle phase, the majority of software publishers will focus on whether there is a POTENTIAL to use software – in other words if any discoverable trace of the application can still be found in the IT environment. When software is no longer being used, it should be re-harvested to build up a license inventory, thereby ensuring that the investment made by the organization is maximized. Only software that is actively being used should be installed and therefore consuming a license entitlement. There are a couple of other scenarios where we should be de-installing or decommissioning software. First, if the underlying hardware that the software is installed on has reached the end of its useful life or is being sent for IT Asset Disposal. Instead of utilizing our Discovery solution or ITAM Repository agents, typically what happens here is that the hard drive is wiped, and then shredded or degaussed to ensure it is unusable. Best practice is to ensure that the software installation records associated with this hardware are removed (usually this happens on the next Discovery scan). In this way you will build up a repository of spare licenses. As mentioned in the Assignment and Distribute License phase, before these spare licenses are re-assigned it is crucial to understand the terms and conditions involved with the specific license contract for that software publisher. Another scenario involves legacy or outdated software. The Information Security department, IT Architecture, as well as Application Owners should have a regular cadence of meetings established with the SAM Team to update them on applications that have reached the end of their support life. This means that their software publisher is no longer offering security patches and will not take support calls to fix the software if there are issues. In these instances, it is recommended that this software be removed from the end users devices so it does not pose a security threat to the organization. Removing this software will not be to re-harvest the license for further use, but rather to decommission it entirely.