Back in June 2025, Microsoft announced that it would enhance Windows 365 security by disabling clipboard and other redirects by default. Depending on your environment, you might need to undo this change. I'm gonna go over my trial and error of controlling these settings via Intune after spending months with a useless non-Premier Microsoft Support case with a bunch of AI slop troubleshooting by the support team. I turned to my own AI slop, which gave me a hint to actually search for something else to get my own fleet with a working copy and paste again.

If you only need text/image/file copy and paste back (the default also blocked printer redirect and plug-and-play devices, which we won't cover). These are all you need. Settings catalog, search for Device and Resource Redirection, add Do not allow Clipboard redirection and Do not allow drive redirection as Disabled. The drive redirection is for copy and pasting files, clipboard for text/images/rich text/HTML.

However, if you're like me and messed around with the other 4 settings about limiting the content of what can be copied and pasted, you might be stuck with it disabled altogether. When you enable one of these 4 settings (Restrict clipboard transfer to and from server/client), you get a choice of gradual control on what type of content can be copied and pasted; it ranges from nothing can be copied and pasted to just plain text to images and rich text. In these settings, server refers to the Windows 365 device, and client is the device you're connecting from (or host machine).

In my initial testing, I had played around with these settings and had learned since that if any of these were previously set, the registry remains and won't be unset, which we know is how GPO has always worked. What I didn't know was that if any of these 4 settings were set to deny copy/paste, deny takes precedence regardless of Device vs User setting. That is to say, denying always wins, great for security, but doesn't follow other types of Device vs User settings - confusing!

The other issue with having had these enabled is that putting it back to disable does not bring back the ability to copy and paste, regardless of your setting in "Do not allow clipboard redirection". It leaves the setting written in the registry, so you have to clear them out via other means (or leave them enabled with the highest allowed setting, disable just tells Intune not to set them anymore).

These are the 4 registry keys related to these 4 settings should you choose to just get rid of these settings completely from your Intune policies. Thanks to the hint from AI making me look under HKCU Terminal Services and it giving me the wrong answer about what SCClipLevel is. Thanks to this blog for showing me what the settings actually are and what they mean after searching for SCClipLevel.

Path: HKLM:\Software\Policies\Microsoft\Windows NT\Terminal Services
Values: SCClipLevel (Server to Client) and CSClipLevel (Client to Server)

Path: HKCU:\Software\Policies\Microsoft\Windows NT\Terminal Services
Values: SCClipLevel (Server to Client) and CSClipLevel (Client to Server)

These keys are not documented on any Microsoft website, so big thanks to the community for translating these settings.

Delete those keys with the deployment tool of your choice.

A quick reference of how to delete it with PowerShell: Remove-ItemProperty -Path $registryPath -Name $valueName

Had to dig a bit for this one as it was not immediately clear to me.

When you are trying to remote from a Mac to an AzureAD (or Entra ID) joined Windows device using Microsoft's Remote Desktop app, you have to use a special username.

You need to use: AzureAD\UPN
Example: AzureAD\userid@example.com

You'll also need to turn off Network Level Auth for it to work, which I don't recommend. However, if you're desperate to remote in, these are the required settings.

First off, credit to these people, if you want to read about the subject in details:
https://call4cloud.nl/2021/05/the-sysnative-witch-project/
https://blog.italik.co.uk/running-powershell-scripts-using-intune/

In moving some scripts I've written for SCCM apps using variables like $env:ProgramFiles or writing to the registry, I tried to reuse the same install command line and detection scripts. But on 64-bit systems, leaving the install line as powershell -ExecutionPolicy Bypass -File Install-Script.ps1 will run in the context of a 32-bit cmd console (because Intune's Win32 App runs in 32-bit, as the name suggests), and the dectection script will run in 64-bit from checking the box that you want to run it in 64-bit.

On your 64-bit Windows workstations, if you used $env:ProgramFiles in your install script and also in your detection script, you end up with installs in C:\Program Files (x86) and detection looking in C:\Program Files.

So how do we make sure our script runs in 64-bit? Change your install and uninstall command line to specifically call for the 64-bit powershell.exe.

%windir%\SysNative\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -file Install-Script.ps1

If you want to test this, the SysNative folder alias is only accessible in 32-bit cmd.exe. You can access that in C:\Windows\SysWOW64\cmd.exe

To check what architecture your PoSh/cmd is in:
cmd: echo "%PROCESSOR_ARCHITECTURE%"
PoSh: $env:PROCESSOR_ARCHITECTURE

There are other options other than changing the Install command line, check out the blogs I linked in the beginning!

First off, you probably shouldn't be doing this, LPR/LPD has been deprecated in Windows since Server 2012. However, it is still useful in a mixed environment.

On-prem Windows Print Servers and macOS clients are going to want to use LPD (if you don't want to use IPP and installing IIS on top just to serve the queues). Another scenario is Azure AD joined only devices without ADConnect Sync to on-prem AD with on-prem domain print servers. You might ask why this specific scenario and I won't tell ya.

Not ready for cloud printing solution yet? Here's something you can use with your deployment system. Assuming your print server is serving LPD already, here's the gist of what's needed.

Dism /online /Enable-Feature /FeatureName:Printing-Foundation-LPRPortMonitor /All

Start-Process -FilePath "C:\Windows\System32\pnputil.exe" -ArgumentList "/add-driver `"$PSScriptRoot\disk1\RICSETUP64.INF`" /install /subdirs" -Wait -NoNewWindow
Add-PrinterDriver -Name "PS Driver for Universal Print"

$InstalledVersion = (Get-PrinterDriver -Name "PS Driver for Universal Print" -ErrorAction SilentlyContinue).DriverVersion
$ver = ((3..0 |ForEach-Object { ($InstalledVersion -shr ($_ * 16)) -band 0xffff }) -join '.')
$MinVersion = [version]"4.32.0.0"

If ($InstalledVersion) {
  If ([version]$ver -ge $MinVersion) { Write-Host "Installed" }
  Else { }
}
Else { }

Add-PrinterPort -HostName $PrintServer -PrinterName $PrinterName
Add-Printer -Name $PrinterName -PortName "$PrintServer:$PrinterName" -DriverName "PS Driver for Universal Print"

That's it, no restart required. Don't look so shocked.

There are some Windows Updates that are only available in the Microsoft Update Catalog. You can import them into WSUS (and thus be able to import them to SCCM) via an ActiveX applet using Internet Explorer as noted in this Microsoft Docs.

However, when I tried to load this applet on my Windows 10 box (with WSUS console installed, as required), the applet had a hard time loading. I tried using the 32-bit version of IE and that made it work only a tiny bit better but not enough to get the to the import part.

I ended up finding a way to import them via PowerShell from this blog. Doing it manually this way does take a bit longer, but having to import hotfixes in the first place is already taking a long time so what's another hour of your life eh?

Find the update you need in the catalog, click on the update and find the GUID in the URL of the newly popped up window with details of the update. You'll also need to download this update.

On your computer with WSUS Console installed, you will need to run PowerShell as the person that has admin and WSUS permissions.

(Get-WSUSServer).ImportUpdateFromCatalogSite('GUID', 'Path_to_msu')

If you are doing it remotely, you'll need a bit more:

(Get-WSUSServer -Name mywsus.fqdn.com -port 8531 -UseSSL:$true).ImportUpdateFromCatalogSite('GUID', 'Path_to_msu')

When it's done, you can double check that it imported by searching the KB number (it doesn't only search KB number, but easiest here):

(Get-WSUSServer -Name mywsus.fqdn.com -port 8531 -UseSSL:$true).SearchUpdates($kbnumber)

Once you've verified that everything is imported, go to your SCCM console and run a Software Updates Sync (Software Library > All Software Update > Synchronize Software Updates in the ribbon). The log for this process is wsyncmgr.log on your SCCM Site Server.

I know what you're thinking, QuickTime 7 for Windows is outdated and should be uninstalled. I agree with you.

However, there are still some apps out there that depends on AVFoundation and aren't using native Windows 10 codecs (Looking at you Avid).

So you just gotta deploy that really old app that hasn't been updated for 3 years and get it to play nice with your deployment tools + Windows. There are a lot of information on how to do this on the web with SCCM or your deployment software of choice; they're all either in a batch file and/or having you extract the MSI files from the downloaded installer. Lately, that method haven't been working right for me because it keeps complaining about a newer version was already install (even though nothing was installed) or it just errors out completely. This is the same type of error I've seen with Cisco AnyConnect (see my previous blog post about this). While this is a Microsoft error, Microsoft has also recommended vendor to work around this so really, it's both of their faults. For some reason, the main installer you download from Apple will not have this error as you would with the lone MSI and it also installs the dependencies it want so I gave it a go.

After a couple attempts, I was going to give up and just use the Apple installer and then uninstall the Apple Software Update, wrapped under a batch file. So I attempted to run the installer in command line with /? to see what kind of options I get. When I did that, I got the msiexec help box instead; which was super weird. So I plugged in my options that I would have used for the QuickTime.msi and see what would have happened. I plugged this whole thing in an elevated command prompt.

QuickTimeInstaller.exe DESKTOP_SHORTCUTS=NO SCHEDULE_ASUW=0 ASUWINSTALLED=0 /q /log "%temp%\QuickTime7_Install.log"

It basically installed without errors and installed all dependencies without software update. Sometimes, re-writing the install procedure is not helpful and you should use the vendor's installer... sometimes.

In an everlasting remediation with Cisco AnyConnect on Windows where 4.5.xxxxx doesn't upgrade properly by just installing a newer version of the product. Cisco has a workaround with 4.6.x but your 4.5 installation is still fucked because a) it's uninstalled in Apps & Feature (Add/Remove if you're old school) but it complains you have a newer version installed if you attempt to install a newer version, or b) it is complaining about "The File 'ManifestTool.exe' is not marked for installation." when attempting to uninstall/reinstall AnyConnect.

So enough of that rant, why did I want to document the versioning? Because Cisco AnyConnect relies a lot of its modules to be the same version of the Core install. I had a need to do some version checking with SCCM and in PowerShell scripting to make sure I can remediate the installation. The problem is, not every developer writes their versions the same way. Most versions are generally written in this format 1.0.123.3456 (see semver.org for some usage examples); however Cisco AnyConnect uses 4, 6, 03049 when queried. Cisco is not the only offender here though; the open source R project version query returns this: 3.5.3.26217 (2019-03-11). If you gave PowerShell a comparison test between 1.4.323.456 and 2.5.323.128, PowerShell can automatically translate them into a version object and compare the 2 versions properly. PowerShell will detect those versions as Major Version, Minor Version, Build Number, Revision Number respectively. For example, you can see your PowerShell's Version table using this command: $PSVersionTable.PSVersion

If you are writing a script, creating a detection method, or a global condition in SCCM, you will have to convert those version numbers into a readable format for PowerShell. If you are a seasoned programmer, you probably know how to do this already. I'm not a seasoned programmer, research + asking questions on PowerShell Slack had given me a lot of insight.

Here's some things to consider when working with version objects:

Convert your number-dot-number string to a version object, remember to quote your string!
$OurVersion=[version]"2.11.1"

Grab the version number using ProductVersion (This command for AnyConnect returns commas); note that I'm using a wild card in the path in case it gets ran on a 32-bit system.

$AnyConnectPath="C:\Program Files*\Cisco\Cisco AnyConnect Secure Mobility Client\vpnui.exe"
$FileVersion=(Get-ChildItem $AnyConnectPath).VersionInfo.ProductVersion

Let's get rid of the commas and convert the string into a version object

$GetFileVersion=(Get-ChildItem $AnyConnectPath).VersionInfo.ProductVersion -replace ', ','.'
$ConvertedACVersion=[version]$GetFileVersion
 

There is another place that product returns a version without commas though (for AnyConnect). You can get it with Get-Command; it is used in older PowerShell versions for other things but works here for AnyConnect.

(Get-Command $AnyConnectPath).Version

So what do we do with the R project and the extra date? Just trim it off.

$AppPath="C:\Program Files\R\R-*\bin\R.exe"
$InstalledVersions=(Get-ChildItem $AppPath).VersionInfo.FileVersion[0]

If there are multiple versions of R installed we split the lines before trimming.

$InstalledVersions=(Get-ChildItem $AppPath).VersionInfo.FileVersion
foreach($line in $InstalledVersions) {
  $s = $line.split()
  $ver = $s[0]
}

In conclusion, we have a few ways to get versions. Here are 2 examples I've used to compare versions.

First one here is a global condition in SCCM. You can turn this into a detection method by adding Write-Host "Installed" along with your $true; the string for Write-Host does not matter.

$AnyConnectPath="C:\Program Files*\Cisco\Cisco AnyConnect Secure Mobility Client\vpnui.exe"
$MinVersion=[version]"4.6.03049"
If (Test-Path $AnyConnectPath) {
    $ACVersion=[version](Get-ChildItem "C:\Program Files*\Cisco\Cisco AnyConnect Secure Mobility Client\vpnui.exe").VersionInfo.ProductVersion
    $MaxVersionInstalled=($ACVersion | Measure-Object -Maximum).maximum
    If ($MaxVersionInstalled -ge $MinVersion) { $true }
    Else { $false }
}
Else { $false }

Here's a snippet of a script also trying to detect the version of AnyConnect. If it's a certain version or newer, run another installer.

$AnyConnectPath="C:\Program Files*\Cisco\Cisco AnyConnect Secure Mobility Client\vpnui.exe"
$MinVersion=[version]"4.6.03049"
If (Test-Path $AnyConnectPath) {
    $GetACVersion=(Get-ChildItem "C:\Program Files*\Cisco\Cisco AnyConnect Secure Mobility Client\vpnui.exe").VersionInfo.ProductVersion -replace ', ','.'
    $ConvertedACVersion=[version]$GetACVersion
    $MaxVersionInstalled=($ConvertedACVersion | Measure-Object -Maximum).maximum
    If ($MaxVersionInstalled -ge $MinVersion) {
    	Start-Process "msiexec.exe" -ArgumentList '/i "installer.msi" /q /lvx* "C:\Windows\Temp\MyProgram-install.log"' -Wait
    }

I had such a hard time finding what some of the variables do in Setaid.ini because I don't have access to the deployment package part of SEMP (I know, most reasons are red tape in my case).

I'll keep this updated when I gather more. Their support page also gets updated too.

https://support.symantec.com/en_US/article.TECH102668.html
https://www.symantec.com/connect/forums/reboot-options#comment-1548481

Under [CUSTOM_SMC_CONFIG]:

KeepPreviousSetting=val
0 = Do not keep previous settings
1 = Keep previous settings
Note: This setting pertains to maintain existing settings in the package creation tab.

DestinationDirectory=installation_path

AddProgramIntoStartMenu=val
0 = Do not an entry to the Start menu
1 = Add an entry to the Start menu

InstallUserInterfaceLevel=val
u = unattended
s = silent
f = interactive

UIRebootMode=val
0 - Display a Yes / No option if reboot is needed
1 - Display pop-up and do reboot when UI level is f, u or s
3 - No pop-up and no reboot when UI level is f, u, or s

Under [LU_CONFIG]:
CONNECT_LU_SERVER=val

0 = Do not run LiveUpdate at the end of the install, which overrides the RUNLIVEUPDATE property
1 = Use the default behavior for running LiveUpdate

Under [FEATURE_SELECTION] , the following entries are valid for SEP 12.1.x (where val is 0 = Don't install the feature and 1 = Install the feature):

Core=val (required)
SAVMain=val
Download= val
OutlookSnapin=val
NotesSnapin= val
Pop3Smtp= val
PTPMain= val
TruScan= val
DCMain= val
NTPMain= val
ITPMain= val
Firewall= val
LANG1033= val

SEP 14.x
SAVMain=val
Download=val
OutlookSnapin=val
NotesSnapin=val
Pop3Smtp=val
PTPMain=val
TruScan=val
DCMain=val
NTPMain=val
ITPMain=val
Firewall=val
Core=val (Required)
Saep=val

Hello! It's been awhile. Doing many things at work now-a-days. Here's something I've been working on in SCCM. We are migrating folks from Windows 7 to Windows 10 (it works with 8 and 8.1 as well), but we have to switch folks to UEFI & Secure Boot & enable TPM for BitLocker encryption. The newer SCCM CB has a tool that allows you to do this without reformatting the drive to UEFI/GPT but we are just going to refresh their install instead since we've been doing this for awhile now.

We are using a State Migration Point (SMP) per site to store user profiles. The User State Migration Tool makes this easy. The hardest part is figuring out how to configure USMT which we won't be covering today. We are going to configure the server you're going to use for storing the user profiles.

These are the guides I used:
https://technet.microsoft.com/en-us/library/bb693655.aspx
https://www.systemcenterdudes.com/how-to-install-sccm-2012-state-migration-point/

• After a new server is brought online, make sure SCCM Client is installed (and restart when it's done if you manually install it); have your SCCM client grab all available software updates if this is your Windows Update of choice (this will take a while)

• In Server Management, add Roles & Features:

  • IIS Role in addition to the defaults:
    • Web Server > Security > Windows Authentication
    • Web Server > Application Development > ISAPI Extensions
    • Management Tools > IIS Management Scripts and Tools
    • Management Tools > IIS 6 Management Compatibility > IIS 6 Metabase Compatibility & IIS 6 WMI Compatibility
  • Remote Differential Compression

• Restart the server

• Create an empty file called NO_SMS_ON_DRIVE.SMS on the root of the C: drive to prevent SCCM from filling up the OS drive

• Create a folder on the data drive (Assuming you have 2 drives!) called UserState, I do this so the root of my data drive is a bit more organize. Some of my sites are small enough that my SMP is the same as my Distribution Point.

• Add new SMP server to Console:

  • Administration > Site Config > Servers and Site System Roles > Create Site System Server
  • Enter the FQDN of your SMP & Site Code, use either your Site Server's computer account or your SCCM service account, either will work.
  • Proxy depends on your infrastructure. Most likely No Proxy needed.
  • Check State Migration Point > Next
  • Click on the "Starburst" icon to configure where the User Profiles should be stored on the server. (i.e.: D:\UserState)
    100MB Reserve and Max client of 50 (or however many connections your server can handle) > OK
  • Depending on the project; Delete After should be configured with a couple days for testing and at least 1 day if the migration fail for any reason. > Next
  • Add Boundary Group (pre-existing ones)

• Check logs to verify your work: SMSSMPSetup.log and SMPmsi.log on SMP (InstallationDrive\SMS\Logs)

• Check for a new folder inside UserState that ends in a $

• Start testing!

When you are trying to run setup /testdbupgrade and you get an error asking for a native client (because you're running the command outside of your DB site or just doesn't have this particular cli that SCCM db test is looking for), you should grab the sqlncli.msi (x64) from Microsoft SQL Server 2012 Feature Pack. Or you can grab it from running setup to get that as a prereq download ($SCCMInstallISORoot\SMSSETUP\BIN\X64\SetupDL.exe).

Also, if you're having trouble pointing to your SQL server using SERVER\dbinstance in your testdbupgrade switch, you can try setup /testdbupgrade $dbinstance /testsqlserver $SERVER

If you work in with SCCM imaging, you've probably seen where your task sequence bombs out saying you're missing a package. Most of the time, it will tell you which package is missing.

That didn't happen today.

It just said that I was missing a package but didn't say which. So I went to grab the SMSTS.log from X:\Windows\Temp\SMSTSLog\smsts.log, threw it on a flash stick to look at it with CMTrace on my computer. (I didn't copy CMTrace to my WinPE, sorry about it)

Wellp, I was thinking how annoying that was and wondered if there's some kind of string I could grep (coming from Macs, this was my first thought).

End results:
type X:\Windows\Temp\SMSTSLog\smsts.log | find "Failed to find"

find is a very simple string search, findstr is a little more powerful but isn't available in a standard WinPE build.

If you ever replaced a HDD in an iMac (pre-flat, and post white kinds), you've probably had a very loud fan and found iStat Menus or SSD Fan Control to fix the noise because you didn't want/need/know about getting a thermal detector. They are both awesome apps so check them out if you've just been living with the fan being on all the time or thinking about installing a SSD in your old iMac.

I recently got iStat Menus because I also needed to see the temps in my dying iMac and it comes with a fan control as well. I still had SSD Fan Control installed because I didn't know about the fan control till later. They now fight to control the HDD Fan but SSD Fan Control always win, leaving the fan running at different speed than what you set in iStat.

I finally bugged the developer over at Exirion for SSD Fan Control for uninstallation help.

I added the unloading of the service first, then remove the daemon and app.

sudo launchctl unload -F "/Library/LaunchDaemons/net.exirion.ssdfanctrl.plist"

sudo rm "/Library/LaunchDaemons/net.exirion.ssdfanctrl.plist"
sudo rm -Rf "/Library/StartupItems/SSDFanControl"
sudo rm -Rf "/Applications/SSD Fan Control.app"

In an attempt to remove .DS_Store files that Finder creates on network shares, I learned about the -exec option in the find command. Sometimes find can feel overwhelming, especially when you've been spoiled by Spotlight or Google, but basically it's formatted this way:

find [options] [path] [expression]

Back to our story about the dot underbar files on network shares. Once upon a time, you had to run defaults write com.apple.desktopservices DSDontWriteNetworkStores true (from https://support.apple.com/en-us/HT1629) for each user to prevent AppleDouble/dot underbar files from clobbering your network shares (in some companies, uniformed looking shares are important). Sometimes you had users that didn't get that defaults written to their user profile and you had to clear out either .DS_Store and AppleDouble files.

Now, in good practice, you should never have to delete the dot underbar and .DS_Store files!

Here are some commands I've used and please be very careful when you use them. You've been warned, and I'm not responsible for your accident disclaimer goes here.

First let's start with a simple search:

Find icons:

find /Library/Printers -name *.icns

In the above example, we're looking for icons to use with our Munki 2 installation, specifically icons that are related to printers (self-service printer installation, perhaps). It says to:
Find in the directory /Library/Printers recursively for files with the name *.icns, standard wildcards apply.

You should never have to delete the dot underbar and .DS_Store files!

.DS_Store cleaning:

find . -name ".DS_Store" -exec rm "{}" \;

In the above example, it says:
Find from the Current Directory, recurisvely (it is recursive by default) that has a file named exactly ".DS_Store" and perform the command rm from the results of the find, and perform it for each result.

AppleDouble cleaning:

find . -type d -exec dot_clean -f "{}" \;

In the above example, it says:
Find from the Current Directory, recursively, that are Directories and perform the command dot_clean -f from the results of the find. The "{}" carries the results and ; breaks the line so it performs the command in every line of the result as we see in the last example. (Added -f to dot_clean so it doesn't recursively search as well, this is just to show our new find prowlness, I'm so punny!) There are more options for dot_clean, so make use of man dot_clean!

There are way more powerful things you can do with find that I haven't even scratched yet. You can always man find for more file types to search for and do different searches with -iname or -xattr.

Sometimes, you want to use a profile to enforce some OS X settings. Whether you're moving away from MCX or Profile Manager is isn't delivering your profiles, you can use Munki to push it out.

You will still need Profile Manager to make profiles, or you can use MCX to Profile to convert your MCX to .mobileconfig (profile!). Then wrap your profile into a .pkg with this tool: make-profile-pkg

It will even generate a recipt and an uninstall shell script to remove the the profile should you ever need to uninstall it! (Or put it in Munki as the uninstall script)

You can use this InstallCheck_Script for Munki to ensure that your profile is installed.

InstallCheck_Script:

#!/bin/sh
# Check if the profile is installed with Munki

HasProfile=$(/usr/bin/profiles -C | /usr/bin/grep "com.apple.mdm.mymdmserver.mydomain.com.12345678-9984-0130-2b83-406c8f235887.alacarte")

# The version of the package
PKG_VERSION="2014.07.08"

# The identifier of the package
PKG_ID="com.github.makeprofilepkg.Settings_for_bss-base"

# The version installed from pkgutil
VERSION_INSTALLED=$(/usr/sbin/pkgutil --pkg-info ${PKG_ID} | /usr/bin/grep version | /usr/bin/sed 's/^[^:]*: //')

if [ -z "${HasProfile}" ]
  then
  # Empty String - Not installed
  exit 0
else
  if [ "$VERSION_INSTALLED" = "$PKG_VERSION" ]
    then
      # Has a matching pkg version and profile identifier - Is installed
      exit 1
    else
      # Has a matching profile identifier but the pkg version is not the same - Not installed
      exit 0
  fi
fi

Make sure you edit the InstallCheck_Script to match your profile identifier. The reason you would want Munki to check the identifier instead of the receipt is because that will stay even if you manually remove the profile. This script will check profiles instead to make sure it's actually active.

So now you have your InstallCheck_Script, you have your .mobileconfig wrapped in a .pkg as the payload, you have your uninstall script. They are all ready to go into the appropriate place in Munki.

I was decomissioning an Xserve from serving MCX (I was turning off Open Directory) to keep it from serving some transitional MCX. Long story short, I deleted the OD. However, the Xserve was still running a print server for Linux boxes and now,
root was gone! Could not sudo or su to root. It kept giving me Unknown user.

It turns out, root was really gone.
The Xserve was running 10.6 server. I was still able to log in as a regular user, but the Linux admin using this server for the printers could not function without sudo (I didn't ask what he needed it for, maybe just needed full lpadmin?)

Anyway, I needed it up and there wasn't a backup (because why would there be in a production environment? /sigh)

I would like to thank frogor again for his guidance.

We attempted some troubleshooting in Single User Mode by booting with Command + s held down.

root was working in Single User Mode, so that was a relief. However, if you try to call it; it just can't be found. We decided to check with dscl to see what it would return if we query for root.

If you try to run dscl . -list /Users, it will not work because your Mac won't understand the current node and it doesn't have the alias for /Users. Also, you can't read it without mounting your system. Do this:
fsck -fy - File System Check

mount -uw / - Mount /

Load your directory, and it will tell you that you can only mess with the localonly node.
launchctl load /System/Library/LaunchDaemons/com.apple.opendirectoryd.plist

In order to list /Users, you need to append the full path /Local/Default. At one point, I thought all users were gone, but I was just using the wrong path.
dscl localonly -list /Local/Default/Users

root was really gone, but root was still in the admin and staff groups dscl localonly -read /Local/Default/Groups/staff and a line still existed for root in /etc/passwd. I attempted to re-create root hoping that only the user record was gone, there are several ways to do this. You can use dscl to create the record, MagerValp's CreateUserPkg.app, or restore a .plist from a known good equal version OS. The last 2 requires Target Disk Mode as you won't be able to authenticate to make changes in regular user mode. gneagle found this link to help out with Target Disk Mode for your Xserve: Xserve User Guide On Page 14, it even tells you how to start TDM without a keyboard.

At this point, frogor had a copy of the /private/var/db/dslocal/nodes/Default/users/root.plist from a 10.6 machine, I had a 10.8 laptop with all the records that root has in dscl. The 10.6 record seem to have less things (the plist is attached on the bottom of this page).

Anyway, on to the commands:

dscl localonly -create /Local/Default/Users/root
dscl localonly -create /Local/Default/Users/root UniqueID 0
dscl localonly -create /Local/Default/Users/root PrimaryGroupID 0
dscl localonly -create /Local/Default/Users/root RealName "System Administrator"
dscl localonly -create /Local/Default/Users/root RecordName root "BUILTIN\Local System"
dscl localonly -create /Local/Default/Users/root AppleMetaNodeLocation /Local/Default
dscl localonly -create /Local/Default/Users/root GeneratedUID FFFFEEEE-DDDD-CCCC-BBBB-AAAA00000000
dscl localonly -create /Local/Default/Users/root NFSHomeDirectory /var/root
dscl localonly -create /Local/Default/Users/root UserShell /bin/sh
dscl localonly -create /Local/Default/Users/root SMBSID S-1-5-18

The root user record is now recreated.
We attmpted reboot into our normal environment and tested that sudo is working and sudo -s was also working. I was very lucky that the rest of the records were intact, but this gave me a whole new insight on using dscl and reading users/groups records on the system.

Here is the root.plist

```




	dsAttrTypeStandard:AppleMetaNodeLocation
	
		/Local/Default
	
	dsAttrTypeStandard:AuthenticationAuthority
	
		;DisabledUser;;ShadowHash;
	
	dsAttrTypeStandard:GeneratedUID
	
		FFFFEEEE-DDDD-CCCC-BBBB-AAAA00000000
	
	dsAttrTypeStandard:NFSHomeDirectory
	
		/var/root
	
	dsAttrTypeStandard:Password
	
		********
	
	dsAttrTypeStandard:PrimaryGroupID
	
		0
	
	dsAttrTypeStandard:RealName
	
		System Administrator
	
	dsAttrTypeStandard:RecordName
	
		root
	
	dsAttrTypeStandard:RecordType
	
		dsRecTypeStandard:Users
	
	dsAttrTypeStandard:SMBSID
	
		S-1-5-18
	
	dsAttrTypeStandard:UniqueID
	
		0
	
	dsAttrTypeStandard:UserShell
	
		/bin/sh
	


```