First, some background as to how we got to this point. At the company I work for, we had a problem. Our Active Directory environment was full of computer accounts that belonged to PCs that had been retired/recycled. This was because the arrangement we had with our sub-companies made it so that they handled the implementation and removal of computer hardware themselves, we just provided them the hardware and operating system image. As a result, there was no real deprovisioning process and the sites dumped the hard drives into a shredder without ever removing them from the domain, leaving thousands of orphaned computer accounts to clutter our AD. As a solution, it was decided to run a script daily that checked to see if each computer had been logged into for the last 30 days, and if it wasn't the PC would be disabled. If it hadn't been logged into for 90 then the PC account would just be deleted from our AD. Problem solved, right?

Well, not quite. See, we run healthcare facilities, and as a result they cannot be with the downtime losing a PC results in, so to hedge against that they purchased two PCs for every one they needed. Therefore, they had a good stock of computers in a closet in case one died for a quick swap out. Issue was, our script deleted the PC objects related to those computers, and as a result nobody could log in as the PC no longer had a trust relationship without it's computer account. IT techies couldn't get in either, as there was no way to get the local admin password as the LAPS attribute wasn't saved anywhere (in retrospect, the script should have saved the LAPS password somewhere before deleting it). So the only option for saving these was a reimage, which (due to a large amount of complexities I won't get into) is a very time consuming and expensive process.

End result? Lots of tickets, close to 100, about PCs pulled from closets that couldn't be logged into. And yea, that's a lot of UPS labels. So I decided we needed to make use of the AD Recycle Bin. Luckily, it was enabled on our domain and just wasn't configured correctly for most admins. When this feature is enabled, every time someone deletes a computer object from Active Directory it isn't deleted, just moved to a new container called "Deleted Objects" in a process called "tombstoning". The resulting "tombstone" object contains most of the properties of the original, and as such can be brought back by a domain administrator. Issue is, it's very unlikely that the person dealing with the calls about these computers is a domain admin, so we need to allow other people to look into the folder.  

Doing this isn't super hard, just it requires a bit of set up in regards to the permissions people are given over this object. Essentially, in order to interact with it as a normal admin, you need to have the same perms as a domain admin would over "Deleted Objects". Also, you need the "reanimate tombstones" permission on the root Active Directory domain in order to bring them back to life. Microsoft has a guide on how to do this, but I find that it's missing a couple of permissions and through trial and error and some old forum threads found the correct perms needed.

Here are the permissions you need to grant to use this tool completely (Can be done on an individual basis, but I would recommend assigning to a security group):

dsacls "dc=fmc,dc=inc" /g "fmcinc\groupname:ca;Reanimate Tombstones"
dsacls "cn=deleted objects,dc=fmc,dc=inc" /g fmcinc\groupname:SDRPWOCCDCLCWSWPRC

This must naturally be run on the DC by a domain admin. Do note that, while maybe not the most sensitive perms in the world, this could result in admins gaining access to sensitive deleted computer accounts. I'm not sure how much of a threat that is in the real world, but in my research I found at least one CTF that required it's abuse. Don't run random commands on your DC because some random in a blog told you it might work. Make sure you know what you're giving out (and in this case it's almost everything in this OU).

Once these permissions were granted, a new problem arose. I will not keep my love of Active Directory Administrative Center (ADAC) a secret, but in this case my trust appears to have been misplaced. See, we use Azure Active Directory Connect to sync our domain to Entra ID (or whatever they call it now). This results in a load of junk "deleted objects" being created for azure-enabled security groups and mailboxes every time the sync runs. This on top of PCs recreating their printer maps (which leads to junk entries being sent to deleted objects). ADAC can only display up to 100,000 entries at once, and in an org as large as ours that just isn't enough. After a struggle, you will just get an error and it will give up.

This is a slight problem, but not an insurmountable one. We could use the LDAP UI, but that's not super fun to work with. The better option is to just use the AD PowerShell module to do the heavy lifting for us.

The command that I'm going to use is this:

Get-ADObject -Filter {((ObjectClass -eq "Computer") -and (isDeleted -eq "TRUE")) -and (Name -like "*pcname*")} -IncludeDeletedObjects -Properties * | Format-List Name, LastKnownParent, Modified, objectSID, ms-Mcs-AdmPwd

Lets go into it how it works for the PowerShell-uninitiated (so if you want to customize it you can). Get-ADObject does exactly what it sounds like. We are just grabbing something from AD. Next, we need to filter it down to what we need.

First, I check to make sure it's a computer (I don't need users although it's unlikely they will appear anyways), and also that it's actually deleted (I don't want to run anything against a normal AD account). As such, (ObjectClass -eq "Computer") -and (isDeleted -eq "TRUE") will check that for us. If both of those are true, I also only want the PC with the name I want back. As such, we'll add another filter (Name -like "*pcname*"). Note the asterisks, I don't actually know what the PC name is a lot of the time but our provisioning script appends the serial number of the PC to the name, so I'm just telling it to look for a PC with that number included somewhere in the name but I don't require it to be exact. At a minimum you will need the right-side asterisk because all deleted object names are appended with `nDEL:<id> and there is absolutely zero way for us to know what that ID is beforehand (not that we need to).

Finally, we need to tell it to look for deleted things, so add -IncludeDeletedObjects and also pull every property, add -Properties *. I then pipe that output into a formatted list to give me the PC name, what OU it used to live in, when it was deleted, what it's SID was, and what the LAPS password was (just in case I can't restore it for some reason). Result looks something like this:

That's great, but how do we play necromancer and bring it back to life? Well, we can just repeat that search again but instead of piping Format-List in we will instead pipe in Restore-ADObject. Also, for good measure lets add the -TargetPath parameter and tell it where it's supposed to go as our wayward script moved everything into a "disabled" OU before it deleted it.  

Let's see it:

Get-ADObject -Filter {((ObjectClass -eq "Computer") -and (isDeleted -eq "TRUE")) -and (Name -like "*pcname*")} -IncludeDeletedObjects | Restore-ADObject -TargetPath "OU=Computers,OU=Your,OU=Site,OU=Here,DC=Contoso,DC=INC"

And just like that, our PC is back from the grave! That being said, if you remember from my background info the PC was disabled first before being deleted, and as our restored object shares all the same properties as before it was deleted, it's still going to be disabled. We could try and run our search again and pipe something else in, but we can't as the tombstone object we were working with has dissapeared! It was deleted when we restored it, so we need to run another search to find it again.

This one is easy tho, same principal as last time, just with only the name as a filter.

Get-ADObject -Filter {Name -Like "stb-5cg032810j"} | Enable-ADAccount

And just like that (and after 30 or so minutes for it to replicate to all DCs), we are back! Downside tho, we have dozens of these left to do and running three commands forever is gonna get old fast. Let's take all these concepts and make a script.

param ($TargetCN, $pcName)
$pcSearchTerm = "*" + $pcName + "*"  
#Checked deleted objects folder for deleted computer objects matching search term  
$deletedPC = Get-ADObject -Filter {((ObjectClass -eq "Computer") -and (isDeleted -eq "TRUE")) -and (Name -like $pcSearchTerm)} -IncludeDeletedObjects -Properties *  
#Lists some info about PC  
$deletedPC | Format-List Name, LastKnownParent, Modified, objectSID, ms-Mcs-AdmPwd  
#Attempts to restore object  
try { $deletedPC | Restore-ADObject -TargetPath $TargetCN}
catch{"PC couldn't be reanimated"}

$revivedPC = Get-ADObject -Filter {Name -like $pcSearchTerm}
try{$revivedPC | Enable-ADAccount}
catch{"Could not re-enable AD Computer Account."}

This is pretty quick and dirty (I don't need every property lol), and the error handling is really not where it needs to be, but this will let me plug and chug a name and bring it back.

Hope this was helpful in some way to you and/or saved you a little more Google searching. Thanks for sticking with me!

~Zeke

So you want to add a 12 volt accessory, say a GPS or a USB charger for your cell phone or Cardo or something to your G310 GS. You could just wire it straight off the battery, but then every time you turn the bike off you need to go to the accessory and turn it off manually. If not, you risk the chance of coming back to a dead bike. Alternatively, you can cut into the ignition harness and put in a relay to run all your 12v accessories, but that is going to violate your warranty and also make a huge mess.

Conveniently, BMW includes two 12v accessory plugs on most of their bikes. On most GS models it lives in the battery compartment, but since the G310R is naked in the front, BMW decided to place it behind the headlamp instead since it was easier to access for the handlebar accessories most people would be installing. Unfortunately, when they made the GS model, they didn't bother to move the accessory ports. That means that it's covered by a load of plastic on the G310GS.

No need to panic, however, the forums are greatly exaggerating how hard it is to actually get to this port and install whatever you want. You DO NOT need to remove the front beak and display surround to access this. As long as you are a bit careful, that is.

What you need:

Step-By-Step Guide:

First, locate the two bolts holding the headlamp from the sides. These are right in front of the turn signals. If i remember correctly these are 6mm hex but i could be wrong on that. Either way, use a metric hex wrench to remove the bolts from both sides.

Next, you need to find the two bolts holding the headlamp in from the bottom. These are the same size as the top ones, but are somewhat awkward to remove since there is a hard plastic hose in the way. Unscrew these, and when removing be careful not to lose the grommet washers as they like to fall out.

Once all the bolts are removed, you need to remove the headlamp. This can be done by carefully bending the plastic of the headlamp surround out of the way and pulling the headlamp through. It is a very tight fit to get it out but it can come out. Just be careful not to stretch the surround too far and crack it or scratch the paint on the surround.

I find it easiest to pull it straight out, and then remove one of the side bolt holes from the surround, then pull the entire thing out sideways.

Once you have the headlamp free from the surround, you'll notice that there is a plug on the top right holding it to the bike. You can easily unplug the headlamp from the bike by pushing the top of the two buttons on the left and right side of the connector. Then just pull it straight up. It wasn't held in particularly tight on my bike.

Set the headlamp aside and let's look at the hole we just made

The ports we are looking for are connected to some dummy plugs on the top right of the headlight surround (next to where the headlamp wire runs). Remove one (or both) by pushing down on the plastic retaining clip release and pulling straight up or down.

From here, all we have to do is connect our female connector plug. Before installing it in the bike, I'd recommend connecting it to your accessory on the bench. I soldered the harness for my zumo XT gps to the harness I purchased and heat shrink'd the connection, but feel free to crimp, wire nut, whatever you think works best for automotive wiring. I know everyone tends to be opinionated on that and I won't be the one to tell you you're doing it wrong.

Once it's on the harness, just plug it to the male side of the connector on the bike and tie down your extra cables. BMW conveniently left a little square hole leading out of this compartment to the bars so you won't need to do any cutting to get your accessories' wires out. From here, just reinstall the headlamp the way it came out. Be mindful of the grommet washers on the top of the headlamp as they like to pop out when putting the headlamp back in. I found it easiest to push the bottom platform of the headlamp against them to where they start to pull out, and just pushed them down and under with my fingers through the holes next to the turn signals.

Once the headlamp is in, it will need to be adjusted according to the settings on your owners manual. That being said, I find the LED headlamps included on the 2022+ models don't actually have any adjustment whatsoever and only go in one way. From there, enjoy your accessories!