Назад | Перейти на главную страницу

Что вызывает побочный ущерб при удалении старых профилей?

#Get user names that have logged onto workstation
$Users = gwmi win32_networkloginprofile | where {$_.name -match "EXP\\"} | where {$_.name -notmatch "srvtasksched"}


$Users | foreach{

    $Name = $_.Name
    $LastLogon = $_.LastLogon

    $LogonTime = [System.datetime]::ParseExact($LastLogon.Substring(0, $LastLogon.IndexOf(".")), "yyyyMMddHHmmss", [System.Globalization.DateTimeFormatInfo]::InvariantInfo)

    if($(Get-Date).Subtract($LogonTime).TotalDays -ge 14)
    {
        #User hasn't logged into workstation in over 2 weeks
        #Get profile path
        $UserSID = $(New-Object System.Security.Principal.NTAccount($Name)).Translate([System.Security.Principal.SecurityIdentifier]).Value
        $UserRegKey = GCI 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList' | where {$_.Name -match $UserSID}

        $ProfilePath = $(Get-ItemProperty $UserRegKey.PSPath -Name ProfileImagePath).ProfileImagePath

        Write-Host "Deleting User $Name"
        gwmi win32_userprofile | where {$_.SID -eq $UserSID} | foreach {$_.Delete()}

    }

}

Это сценарий. Обнаруживает и удаляет домен профили (домен EXP) в системах, которые не входили в систему более 14 дней, и работает.

Однако я начал получать жалобы на то, что сценарий удаляет локальные учетные записи, в частности, одну локальную учетную запись. Предположив, что это невозможно (у меня отличные навыки работы со сценариями, верно?), Я взглянул, запустил сценарий и увидел, что папки профилей для всех локальных учетных записей все еще находятся в папке C: \ Users (рабочие станции Win 7). Ложное заявление.

Вперед, больше жалоб. Я снова запустил скрипт, результат тот же. Однако на этот раз я заметил, что пропала запись в реестре для одной конкретной локальной учетной записи (той, из которой возникают жалобы). После этого я запускал скрипт построчно, разбивая $Users | foreach{ цикл, убедившись, что он захватывает правильные сиды и запускает Win32_UserProfile.delete() на правильных SID - да.

Однако при запуске сценария (это запланированная задача, поэтому я запускал ее «вручную» оттуда) те же локальные идентификаторы безопасности удаляются, а все остальные остаются, что добавляет путаницы; потому что при просмотре действия я вижу, что папки пользователей домена в C: \ Users сразу удаляются, но локальные остаются, что добавляет путаницы.

Сначала я думал, что это ограничено одним локальным профилем, однако после открытия реестра я заметил, что в HKEY_USERS было всего несколько записей:

  1. Моя учетная запись домена от удаленного подключения, и

  2. Проблемная учетная запись, в которую я вошел, чтобы проверить учетная запись все еще существовал, хотя профиль не сделал.

Все остальные идентификаторы безопасности, локальные или доменные, были ушел. Он ограничен одной локальной учетной записью пользователя.

Последствия этого, конечно же, заключаются в том, что когда кто-то входит в локальную учетную запись, все в их папке профиля перезаписывается, однако наблюдение за запуском сценария и удалением всех папок профиля учетных записей домена, но не локальных учетных записей, немного вводит в заблуждение.

Обновить


Я удалил и обновил информацию выше. Кроме того, картинки лучше тысячи слов, так что вот:

  1. Снимок ключа реестра списка профилей и C: \ Users перед запущенный скрипт. Частично пустые идентификаторы безопасности привязаны к учетным записям домена, а выделенные папки профиля - к пользователям домена:

  1. Снимок того же, после скрипт запускается. Остался один SID домена, мой:

Для уточнения хочу знать Зачем при запуске этого сценария локальная учетная запись удаляется. Похоже, либо

  1. Никакие локальные учетные записи не будут удалены (сценарий работает, как задумано)

  2. Все локальные профили будут удалены (скрипт не дискриминирует один локальная учетная запись, даже если это также означает не запустить как задумано).

Не совсем уверен, как это может привлечь местных жителей ... если только -match "EXP \\" не ведет себя так, как ожидалось. Есть ли в названии рабочих станций "EXP"? Возможно ли, что эти локальные учетные записи используются для локального входа в систему и остаются в системе более 14 дней? Ваше 14-дневное окно может быть слишком агрессивным.

В вашем коде используются 2 разных поставщика WMI, которые содержат в основном одинаковую информацию. Предложите более простой цикл (одиночный запрос WMI), в котором вы также (№1) сопоставляете только те учетные записи, SID которых совпадает с SID домена, а также ведете несколько журналов, чтобы упростить диагностику проблем, если проблемы по-прежнему остаются. Измените значение $ sidPrefix, чтобы оно соответствовало значению вашего домена.

$sidPrefix = "S-1-5-99-999999999-"
gwmi Win32_UserProfile | WHERE {$_.sid -match $sidPrefix -AND $_.localpath -match "\\users\\" -AND $_.localpath -notmatch "srvtasksched" } | foreach {
    $name = split-path $_.localpath -leaf
    $lastUse = $_.lastusetime
    $LogonTime = [System.datetime]::ParseExact($lastUse.Substring(0, $lastUse.IndexOf(".")), "yyyyMMddHHmmss", [System.Globalization.DateTimeFormatInfo]::InvariantInfo)
    $now = get-date
    [int]$daysOld = $now.Subtract($LogonTime).TotalDays

    if($daysOld -ge 30)     {
        $info = "$name,$daysOld,$lastUse,$now"
        $info
        $info | out-file -append -enc ascii "C:\temp\profClean.csv"
        #$_.Delete()
    }
}