How to specify credentials to restart or shutdown a remote host with ‘net use’

I recently wanted to shutdown a server on my local network (notably a workgroup) using the Windows shutdown command but encountered an access denied error (or no feedback whatsoever).

I needed to use the administrator credentials of the remote server but shutdown.exe doesn’t accept credentials.

Using ‘net use’ to connect to the IPC$ share on remote host, you can set then call shutdown in that security context:

net use \\hostname\IPC$ mypassword /User:administrator

shutdown /r /t 60 /m \\hostname /f

In the net use command above, replace hostname with the name of your remote host (or maybe an IP address), replace mypassword with the password for the account you’re using, and replace administrator with the name of the local account on the remote host you wish to use (which presumably has the necessary rights to restart or shutdown the server).

In the shutdown command above, replace hostname with the name of your remote host, as per the net use command.

Note: Read the shutdown /? usage. The /r flag will restart the host; change /r to /s if you want to shutdown instead. Other parameters can also be specified. I also typically set the timeout (/t) flag to 0 (zero).

I call both commands back-to-back in a Windows Command Prompt, without running the console as Admin.

See below for a few more tips, links, and PowerShell alternatives.

If you’re used to operating as a domain user you may be asking why any of this is even necessary. It’s necessary in a workgroup context because the remote host has no idea who I am if I just tell it to shutdown from some other computer on the local IP network. It may be possible to an account on one host the necessary privileges on another host but I don’t know for certain and, in my limited experience, this can get hard and weird very quickly!

I used to run a domain controller on my small local network (just for fun) and all of my servers were members of a domain, which made security easy. I got rid of the DC as DHCP and other services were migrated to my internet router and to streamline things. In all regards, having one less server to manage, power, and so on is great. I’ll run a virtualised AD when I need to, e.g. for development purposes).

In addition to a media centre, I also still run a physical file server, primarily for backups. My basic process is to power on the file server once a week to backup the media centre, my laptop, etc and then shut it down again (so the kids don’t fiddle and to keep the noise down).

The backup process is otherwise seamless—the backup services on the file server and clients just pick up where they left off and run to completion without any human interaction (I use CrashPlan and would highly recommend it). I only need to power on the file server and then shut it down.

To shut down, I’d previously connect to the file server via Remote Desktop and then shut down. But that’s too hard. I can tell from the backup client on my laptop when a backup is complete so I just want to quickly shutdown the file server and go to bed.

In a domain environment, I could make sure my domain account was a member of the Administrators group on the file server and then call shutdown.exe from a command prompt on my laptop; without the DC, I need to explicitly provide shutdown.exe with the necessary credentials before actually calling shutdown.exe.

A few other notes: the file server is running Windows Server 2012 and my laptop is running Windows 8.1.

In recent versions of Windows (i.e. 2012+), I’ve read that UAC may interfere with things. You may want to turn it off but can simply add or configure this registry key (I didn’t have to):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Value: LocalAccountTokenFilterPolicy
Data: 1 (to disable) or 0 (to enables filtering)
Type: REG_DWORD (32-bit)

You may need to restart after making this change.

Thank to https://helgeklein.com/blog/2011/08/access-denied-trying-to-connect-to-administrative-shares-on-windows-7/ for this one. See also this Microsoft help article (ID 951016) “Description of User Account Control and remote restrictions in Windows Vista”

Others suggested File and Printer sharing must be allowed in the Windows Firewall.

I believe PowerShell offers similar restart (and stop) commands. I haven’t tried them and can’t say whether they work with the techniques described here but I believe both accept a –credential parameter.

See these references:

https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.management/restart-computer

https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.management/stop-computer

How to determine where an Active Directory object lives

Active Directory's Find… function is pretty handy: by searching from the directory root or any OU, you can search for specific objects by name, etc.

Unfortunately the search results display is a bit barebones and it's never obvious to a non-AD admin like me how to determine where the object actually lives in the hierarchy. Luckily you can drill into a search result item to view an object's properties but unless you're a real AD keener, you still might know how to find the object's location.

To rectify this situation, you'll need to turn on the Advanced Features setting from the Active Directory Users and Computers snap-in's View menu:

The object properties display will now include an Object tab which contains the Canonical name of object field (in other words, the path to the object within the directory):

If you found this post helpful, please support my advertisers.

Troubleshooting user profile sync via FIM

Your initial foray into SharePoint 2010 user profile sync will likely lead you to the FIM client and, if you're anything like me, your mind will boggle at what FIM is, why it has to be involved at all, and where to start when things to horribly wrong.

I won't attempt to enlighten you on the first two subjects but I do want to point out some interesting and non-intuitive FIM user interface screens you may not be aware of and that will help you determine if your UPS setup is on the right path. By the way, you can run the FIM client as soon as the two FIM services are running on your machine (in other words, as soon as UPS has been provisioned but before you run a sync).

If you've got the UPS service in a running state, the next thing you'll likely want to do is run your first (or 50th) sync; in addition to the dodgy status screen within Central Admin itself, you can fire up the FIM client to watch from the bushes (the Operations view) as SharePoint, FIM, SQL Server, and AD do their magic dance. A successful run includes ten operations in my dev environment and I've previously posted a screen shot of this if you're interested.

If you look carefully, the operations view will reveal the user name involved with each operation and list some partition info as well. To dive in deeper, click the Management Agents button in the top menu; in my case, I'm presented with three MAs (if you've got more because you've been struggling with connections, you may be in trouble):

• The first MA named ILMMA connects to the database I specified when setting up UPS ("Sync DB")
• The second MA named MOSS-{GUID} connects to the ProfileImportExportService web service
• The final MA named MOSSAD-{name of my connection as configured in CA} connects to Active Directory

By viewing the properties for each MA (right-click on an MA and select Properties from the context menu or use the Actions pane to the right of the window) I can also examine specific properties to determine exactly what domain name FIM is configured to use and the accounts used to interact with AD, SQL Server, and the web service:

The attentive reader will note there's a lot of farm account action going on here and that's because both FIM services are configured to log on as the farm account and my understanding is they have to be because of the way the relevant timer job(s), which are also run as the farm account, interact with these services (says Spence). I'll also point out my svc_spups account is the account to which I've granted Replicating Directory Changes in AD.

If you found this post helpful, please support my advertisers.

Configuring the People Picker and No exact match was found

SharePoint's people picker is generally one of those things that just kind of works—and fairly well no less. There's a gotcha to that statement however: the people picker works well when the the SharePoint farm exists in the same domain as the users you want to match against, or exists in a second domain where a two-way trust has been established with the first domain.

If your SharePoint web frontends exist in another domain with a one-way trust, you've got some extra work to do. This is the case with our dev setup and DMZ setup: our dev VMs are joined to the dev domain which trusts the corporate domain and our production servers are similarly joined to a web domain that also trusts the corporate domain. Both trusts are one-way.

I'll simplify what needs to be done by stating you simply need to tell SharePoint which forests or domains house the users you're after and provide an account from that domain.

Firstly you'll need to provide a key that will be used to encrypt any passwords you plug in during the next step. Run this on every WFE where "key" is a string of your choosing:

STSADM.exe -o setapppassword -password key

Next, set the peoplepicker-searchadforests property:

STSADM.exe -o setproperty-propertyname peoplepicker-searchadforests -propertyvalue <Valid list of forests or domains> -url <URL of the Web application>

where <Valid list of forests or domains> might look like this:

"domain:mydomain.com,mydomain\myuser,mypassword"

Supply the URL of the web application you want to configure (and note you don't need to set this for Central Admin, set it for a specific web application). Multiple domains and forests can be listed if necessary.

For more information, check out these resources:

• All you want to know about People Picker in SharePoint ( Functionality | Configuration | Troubleshooting ) Part-2
• Peoplepicker-searchadforests: Stsadm property

 If you found this post helpful, please support my advertisers:

Manage Active Directory Users and Groups with PowerShell

With a new dawn and the SharePoint 2010 beta upon us, I figured it was finally time to a) dip my toes into the PowerShell pool and b) learn how to automate the creation of users, groups, organisational units, and other objects within Active Directory. In the PS case, it still seems like an unnecessary evil and, between all the other things on my “TO LEARN” list, it hasn’t been a high priority; that said, it seems to work and I kind of, sort of, maybe just like it. We’ll see… On the automation front, I figured I’ll probably blow away more than my fair share of development environments before my time is up so I might as well make creating the darned things a little bit easier and more repeatable.

My search for information along these lines quickly led me to Quest’s ActiveRoles Management Shell for Active Directory—a set of PowerShell commandlets. The download is free and if you grab it I’d also strongly suggest you pull down the admin guide as well—it’s comprehensive and includes examples. To install, run the .msi and finish the wizard with the defaults.

From there you’ll need to add the related snap-in in a PS window as follows:

Add-PSSnapin Quest.ActiveRoles.ADManagement

The first thing I wanted to create was a user object and this was reasonably straightforward. Be warned some of the commandlets take a lot of arguments, the names of which don’t always correspond to the UI you see in the AD Users and Computers snap-in: password is –UserPassword, for example, and Job Title is simply –Title. Here’s the command I used:

new-QADUser -name 'Bob' -ParentContainer 'OU=DirtyWords,DC=spdev,DC=mediawhole,DC=com' -SamAccountName 'Bob' -UserPassword 'TH1Smis1s' -FirstName 'Bob' -DisplayName 'Bob' -UserPrincipalName 'bob@spsdev.mediawhole.com' -Title CEO

This creates the user but new-QADUser doesn’t allow you set all of the things I want to using the standard parameters. In my case, I also want to set the account to never expire. To do this, I used the set-QADUser commandlet as well, which seems to let you get to much more detail:

set-QADUser 'CN=Bob,OU=DirtyWords,DC=spdev,DC=mediawhole,DC=com' -PasswordNeverExpires $true

Next I created a new group using the new-QADGroup commandlet:

new-QADGroup -ParentContainer 'OU=DirtyWords,DC=spdev,DC=mediawhole,DC=com' -name 'Managers' -samAccountName 'Managers' -grouptype 'Security' -groupscope 'Global'

…before adding my new user to my new group with the add-QADGroupMember commandlet:

add-QADGroupMember -identity 'CN=Managers,OU=DirtyWords,DC=spdev,DC=mediawhole,DC=com' -member 'CN=Bob,OU=DirtyWords,DC=spdev,DC=mediawhole,DC=com'

This last exercise proved somewhat troublesome as the examples in the admin guide and specific documentation about the –member parameter indicated I could supply ‘spsdev\Bob’ in place of the string above I ended up using successfully. The error message was fairly explicit about this:

Add-QADGroupMember : Cannot resolve directory object for the given identity: 'spsdev.mediawhole.com\bob'.

One other commandlet I haven’t yet managed to get working is the new-QADObject commandlet to create a new OU:

new-QADObject -ParentContainer 'DC=spsdev,DC=mediawhole,DC=com' -type 'organizationalUnit' -NamingProperty 'ou' -name 'Dirty Words'

This command fails on the type parameter with;

New-QADObject : A referral was returned from the server…

+ CategoryInfo          : NotSpecified: (:) [New-QADObject], COMException
+ FullyQualifiedErrorId : System.Runtime.InteropServices.COMException,Quest.ActiveRoles.ArsPowerShellSnapIn.Powers
hell.Cmdlets.NewObjectCmdlet

I’ll probably look back at this post one day after figuring this one out and laugh at my lack of understanding but for now it’s got me stumped.

Dirty Words (Michael Hanes) - blog.mediawhole.com mailto:info@mediawole.com