Blog - Title

August, 2012

  • One of us: What it was like to interview for a support role at Microsoft

    Hello, Kim here again. We get many questions about what to expect when interviewing at Microsoft. I’m coming up on my two year anniversary at Microsoft and I thought I would share my experience in the hope that it might help you if you are interested in applying to Microsoft Support; if nothing else, there is some educational and entertainment value in reading about me being interviewed by Ned. :)

    Everyone at Microsoft has a unique story to tell about how they were hired. On the support side of Microsoft, many of us were initially hired as contractors and later offered a full-time position. Others were college hires, starting our first real jobs here. It seems some have just been here forever. Then there are a few of us, myself included, that were industry hires. Over the years, I've submitted my résumé to Microsoft a number of times. I have always wanted to work for Microsoft, but never really expected to be contacted since there aren’t many Microsoft positions available in central Indiana (where I’m from). I had a good job and wasn’t particularly unhappy in it, but the opportunity to move up was limited in my current role. I casually looked for a new position for a couple of months and had been offered one job, but it just didn't feel like the right fit. Around the same time, I submitted my résumé to Microsoft for a Support Engineer position on the Directory Services support team in Charlotte. Much to my surprise, I received an email that began a wild ride of excitement, anxiety, anticipation, and fear that ultimately resulted in my moving from the corn fields of the Midwest (there is actually more than corn in Indiana, btw) to the land of sweet tea.

    I never expected that Microsoft would contact me due to the sheer volume of résumés they receive daily and the fact that the position was in Charlotte and I was not. About a week after I submitted my résumé, I received an email requesting a phone interview with the Directory Services team. I, of course, responded immediately and a phone interview was set up for three days from the current date. When I submitted my résumé, I didn’t think I’d be contacted and if I was, I definitely thought I’d have more than three days to prepare! The excitement lasted about 30 seconds before the reality of the situation set in . . . I was going to have an interview with Microsoft in three days! Just to add to the anxiety level, Ned Pyle (queue the Halloween theme) was going to do my phone screen!

    Preparation - Phone Screen

    I didn't know where to start to prepare. As with any phone screen, you have no idea what types of questions you will be asked. Would it be a technical interview; would it just be a review of my résumé and my qualifications? I didn’t know what to expect. I assumed that since Ned was calling me that there would be some technical aspect to it, but I wasn’t sure. There’s no wiki article on how to interview at Microsoft. :) On top of that, I'd heard rumors of questions about manhole covers and all kinds of other strange problem-solving questions. This was definitely going to be more difficult than any other interview I’d ever had.

    Once I got over the initial panic, I decided I needed to start with the basics. This was a position for the Directory Services team, so I dug out all of the training books from the last eight years of working with Active Directory and put together a list of topics I knew I needed to review. I also did a Bing search on Active Directory Interview questions and I found a couple of lists of general AD questions. Finally, I went to the source, the AskDS blog, and searched for information on "hiring" and found a link to Post-Graduate AD Studies.

    My resource list looked something like this:

    1. Post-Graduate AD Studies (thanks, Ned)

    2. O'Reilly Active Directory book (older version)

    3. Training manual from Active Directory Troubleshooting course that was offered by MCS many years ago

    4. Training manuals from a SANS SEC505 Securing Windows course

    5. MS Press Active Directory Pocket Consultant

    6. MS Press Windows Group Policy Guide

    7. AD Interview Questions Bing search



    I only had three days to study, so I decided to start with reviewing the areas that I was weakest in and most comfortable with. For me, these were:

    1. PKI (ugh)

    2. AD Replication (good)

    3. Kerberos (ick)

    4. Authentication (meh)

    5. Group Policy (very good)

    The SANS manuals had good slides and decent descriptions, so that is where I started. Everyone has different levels of experience and different study habits. What works for me is writing. If I write something down, it seems to solidify it in my mind. I reviewed each of the topics above and focused on writing down the parts either that were new to me or that I needed to focus on in more detail. This approach meant that I was reading both the topics I already understood (as a refresher) and writing down the topics I needed to work on. Next, I went through the various lists of AD interview questions I had found and made sure that I could at least answer all of the questions at a high level. This involved doing some research for some of the questions. The websites with the lists of questions were a good resource because they didn’t give me the answers. I didn’t just want to be able to recite some random acronyms. I wanted to understand, at least at a high level, what all of the basic concepts were and be able to relate them to one another. I knew that I was going to need to have broad knowledge of many topics and then deep knowledge in others.

    The worst part of all of this studying was that I didn't have enough lead-time to request time off from work to focus on it. So, while I was eating lunch, I was studying. While I was waiting on servers to build, I was studying. While I was waiting on VMs to clone, guess what? I was studying. :) By the end of the three days of studying, I was pretty much a nervous wreck and ready for this phone screen to end.

    The Phone Screen

    This is where you'd like me to tell you what questions Ned asked me, but . . . that isn't going to happen. Bwahahaha. :-)

    What I can tell you about the interview is that it wasn't solely about rote knowledge, which is good since I had prepared for more than just how to spell AD & PKI. Knowing the high-level concepts was good; he asked a few random questions to see how far I could explain some of the technologies. It was more important to know what to do with this information and how to troubleshoot given what you know about a particular technology. If you can't apply the concepts to a real world scenario then the knowledge is useless. Throughout the interview, there were times where I couldn't come up with the right words or terms for something and I imagined Ned sitting there playing with his beard out of boredom.


    In those situations, I found Ned was awake and tried to help me through them or skipped to something else that eventually got me back to the part I’d been struggling with but this time with better results. For that, I was grateful and it helped me keep my nerves in check as well. While trying to answer the flood of questions and keep my nerves in check, I tried to keep a list of the topics we were discussing just in case I got a follow-up interview. Although I’d like to say that I totally rocked out the phone interview and that I’m awesome (ok, I’m pretty cool), I actually thought I’d done alright, but not necessarily well enough to get a follow-up interview. Overall, I didn’t feel like I had been able to come up with responses quickly enough and Ned guided me around a couple of topics before I finally understood what he was getting at a few more times than I would have liked.

    On-site interview scheduled - WOOT!

    Much to my own disbelief, I did receive that follow-up email to schedule an in-person interview down in sunny Charlotte, NC. Fortunately, I had a little more time to prepare, mainly due to the nature of an on-site interview that is out of state. Logistics were in my favor this time! As I recall, I had about two weeks between when I received notification of the on-site interview and the actual scheduled interview date. This was definitely better than the three days I had to prepare for the phone screen.

    With more time, I decided that I would take some days off work to focus on studying. Maybe this is extreme, but that is how important it was to me to get this job. I figured that this was my one shot to get this right and I was going to do everything I possibly could to ensure that I was as prepared as I could possibly be.

    This time, I started studying with the list of questions from my phone interview with Ned. I wanted to make sure that if Ned was in my face-to-face interview that I would be able to answer those questions the second time. Then I reviewed all of the questions and notes that I had prepared for my phone interview. Finally, I really started digging in on the Post-Graduate AD Studies from the AskDS blog. I take full responsibility for the small forest of trees I killed in printing all of this material off. I read as much as I could of each of the Core Technology Reading and then I chose three or four areas from the Post Graduate Technology Reading to dig into deeper.

    Obviously, I didn't study all day for two weeks. I'd read and then go for a short walk. As the time passed, I began to realize how long two weeks is. Having two weeks to prepare is awesome, but the stress of waking up every day knowing what you need to do and then dealing with the anxiety of just wanting it to be over is harder than I thought it would be. I tried to review my notes at least once a day and then read more of the in-depth content with the goal of ensuring that I had some relatively deep knowledge in some areas, knew the troubleshooting tools and processes, and for the areas I couldn’t go so deep into that I at least knew the lingo and how the pieces fit together. I certainly didn’t want to get all the way to Charlotte and have some basic question come at me and just sit there staring at the conference room table blankly. :-/

    By the time I was ready to leave for my interview, I knew that I’d done everything I could to prepare and I just had to hope that the hard work paid off and that my brain cells held out for another day.

    The On-site interview

    I arrived in Charlotte the evening before the interview. I studied on the flight and then a little the night before. Again, just reviewing my notes and the SANS guide on PKI and Kerberos. I tried not to overdo it. If I wasn't ready at this point, I never would be.

    I got to the site a little early that day, so I sat in the car and read more PKI and FRS notes. Then I took about 5 minutes and tried to relax and get my nerves under control (nice try).

    The interview itself was intense. It was scheduled for an hour, but by the time I got out of the conference room I’d been in there two and a half hours. There were engineers and managers from both Texas (video conference) and Charlotte in the room. The questions pretty much started where we had left off from the phone interview in terms of complexity. I didn’t get a gimme on the starting point. I think we went for about an hour before they took pity on me and let me get more caffeine and started loading me up on chocolate. By the time I got to the management portion of the interview, I was shaking pretty intensely (probably from all that soda and chocolate that they kept giving me) and I was glad that I’d brought copies of my résumé so I could remember the last 10 years of my work history.

    The thing that I appreciated most about the entire process was how understanding everyone was. They know how scary this can be and how nervous people are when they come in for an interview. Although I was incredibly nervous, everyone made me feel comfortable and I felt like they genuinely wanted me to succeed. The management portion of the interview was definitely easier, but they did ask some tough questions as well. I also made sure that I had come prepared with several questions of my own to ask them.

    When I finally walked out of the conference room, I felt like a train had hit me. Emotionally I was shot, physically I was somewhere between wired and exhausted. It was definitely the most grueling interview I’d ever experienced, but I knew that I’d done everything I could to prepare. The coolest part happened as I was escorted to my car. As we were finishing our formalities, my host got a phone call on his cell phone and it was for me. This was probably the weirdest thing that had ever happened to me at an interview. I took his cell phone and it was one of the managers that had participated in my interview, she was calling to let me know that they were going to make me an offer and wanted to let me know before I left so I wouldn’t be worried about it all the way home on the plane. Getting that phone call before I left was an amazing feeling. I’d just been through a grueling interview that I’d spent weeks (really my entire career) preparing for and finding out my hard work had paid off was an unbelievable feeling. It didn’t become real until I got my blue badge a few days after my start date.

    Hindsight is 20/20

    Looking back at my career and my preparation for this role, is there anything that I would do differently to better prepare? Career-wise, I’d say that I did a good job of preparing for this role. I took increasingly more challenging roles from both a technical and a leadership perspective. I led projects that required me to be both the technical leader (designing, planning, testing, documenting a system) and a project leader (collaborating with other teams, managing schedules, reporting progress to management, dealing with road blocks and competing priorities). These experiences have given me insight and perspective on the environments and processes that my customers work with daily.

    If I could do anything differently, I’d say that I would have dug in a little deeper on technologies that I didn’t deal with as part of my roles. For instance, learning more about SQL and IIS or even Exchange would have helped me better understand to what degree my technologies are critical to the functionality of others. Often our support cases center on the integration of multiple technologies, so having a better understanding of those technologies can be beneficial.

    If you are newer to the industry, focusing on troubleshooting methodologies is a must. The job of support is to assist with troubleshooting in order to resolve technical issues. The entire interview process, from the phone-screen to the on-site interview, focused on my ability to be presented with a situation I am not familiar with and use my knowledge of technology and troubleshooting tools to isolate the problem. If you haven’t reviewed Mark Renoden’s post on Effective Troubleshooting, I highly recommend it. This is what being in support is all about.

    Just don’t be these guys

    So, what's it really like?

    Working in support at Microsoft is by far the most technically demanding role I’ve had during the course of my career. Every day is a new challenge. Every day you work on a problem you’ve never seen before. It’s a lot like working in an Emergency room at times. Systems are down, businesses are losing money, the pressure is high and the expectations are even higher. Fortunately, not all cases are critsits (severity A) and the people I work with are amazing. My row is comprised of some of the most intelligent but “unique” people I’ve ever worked with. In ten minutes on the row, you can participate in a conversation about how the code in Group Policy chooses a Domain Controller for writes and which MIDI rendition of “Jump” is the best (for the record, they are all bad). While the cases are difficult and the pressure is intense, the work environment allows us to be ourselves and we are never short on laughs.

    The last two years have been an incredible journey. I’ve learned more at Microsoft in two years than I did in five out in the industry. I get to work on some of the largest environments in the world and help people every day. While this isn't a prescription for how to prepare for an interview at Microsoft, it worked for me; and if you're crazy enough to want to work with Ned and the rest of us maybe it will work for you too. GOOD LUCK!

    - Kim “Office 2013 has amazing beard search capabilities” Nichols

  • Monthly Mail Sack: Yes, I Finally Admit It Edition

    Heya folks, Ned here again. Rather than continue the lie that this series comes out every Friday like it once did, I am taking the corporate approach and rebranding the mail sack. Maybe we’ll have the occasional Collector’s Edition versions.

    This week month, I answer your questions on:

    Let’s incentivize our value props!


    Everywhere I look, I find documentation saying that when Kerberos skew exceeds five minutes in a Windows forest, the sky falls and the four horsemen arrive.

    I recall years ago at a Microsoft summit when I brought that time skew issue up and the developer I was speaking to said no, that isn't the case anymore, you can log on fine. I recently re-tested that and sure enough, no amount of skew on my member machine against a DC prevents me from authenticating.

    Looking at the network trace I see the KRB_APP_ERR_SKEW response for the AS REQ which is followed by breaking down of the kerb connection which is immediately followed by reestablishing the kerb connection again and another AS REQ that works just fine and is responded to with a proper AS REP.

    My first question is.... Am I missing something?

    My second question is... While I realize that third party Kerb clients may or may not have this functionality, are there instances where it doesn't work within Windows Kerb clients? Or could it affect other scenarios like AD replication?


    Nope, you’re not missing anything. If I try to logon from my highly-skewed Windows client and apply group policy, the network traffic will look approximately like:




    Packet Data Summary




    AS Request Cname: client$ Realm: CONTOSO.COM Sname:








    AS Request Cname: client$ Realm: CONTOSO.COM Sname: krbtgt/CONTOSO.COM




    AS Response Ticket[Realm: CONTOSO.COM, Sname: krbtgt/CONTOSO.COM]




    TGS Request Realm: CONTOSO.COM Sname: cifs/DC.CONTOSO.COM








    TGS Request Realm: CONTOSO.COM Sname: cifs/DC.CONTOSO.COM




    TGS Response Cname: client$

    When your client sends a time stamp that is outside the range of Maximum tolerance for computer clock synchronization, the DC comes back with that KRB_APP_ERR_SKEW error – but it also contains an encrypted copy of his own time stamp. The client uses that to create a valid time stamp to send back. This doesn’t decrease security in the design because we are still using encryption and requiring knowledge of the secrets,  plus there is still only – by default – 5 minutes for an attacker to break the encryption and start impersonating the principal or attempt replay attacks. Which is not feasible with even XP’s 11 year old cipher suites, much less Windows 8’s.

    This isn’t some Microsoft wackiness either – RFC 4430 states:

    If the server clock and the client clock are off by more than the policy-determined clock skew limit (usually 5 minutes), the server MUST return a KRB_AP_ERR_SKEW. The optional client's time in the KRB-ERROR SHOULD be filled out.

    If the server protects the error by adding the Cksum field and returning the correct client's time, the client SHOULD compute the difference (in seconds) between the two clocks based upon the client and server time contained in the KRB-ERROR message.

    The client SHOULD store this clock difference and use it to adjust its clock in subsequent messages. If the error is not protected, the client MUST NOT use the difference to adjust subsequent messages, because doing so would allow an attacker to construct authenticators that can be used to mount replay attacks.

    Hmmm… SHOULD. Here’s where things get more muddy and I address your second question. No one actually has to honor this skew correction:

    1. Windows 2000 didn’t always honor it. But it’s dead as fried chicken, so who cares.
    2. Not all third parties honor it.
    3. Windows XP and Windows Server 2003 do honor it, but there were bugs that sometimes prevented it (long gone, AFAIK). Later Windows OSes do of course and I know of no regressions.
    4. If the clock of the client computer is faster than the clock time of the domain controller plus the lifetime of Kerberos ticket (10 hours, by default), the Kerberos ticket is invalid and auth fails.
    5. Some non-client logon application scenarios enforce the strict skew tolerance and don’t care to adjust, because of other time needs tied to Kerberos and security. AD replication is one of them – event LSASRV 40960 with extended error 0xc000133 comes to mind in this scenario, as does trying to run DSSite.msc “replicate now” and getting back error 0x576 “There is a time and / or date difference between the client and the server.” I have recent case evidence of Dcpromo enforcing the 5 minutes with Kerberos strictly, even in Windows Server 2008 R2, although I have not personally tried to validate it. I’ve seen it with appliances and firewalls too.

    With that RFC’s indecisiveness and the other caveats, we beat the “just make sure it’s no more than 5 minutes” drum in all of our docs and here on AskDS. It’s too much trouble to get into what-ifs.

    We have a KB tucked away on this here but it is nearly un-findable.

    Awesome question.


    I’ve found articles on using Windows PowerShell to locate all domain controllers in a domain, and even all GCs in a forest, but I can’t find one to return all DCs in a forest. Get-AdDomainController seems to be limited to a single domain. Is this possible?


    It’s trickier than you might think. I can think of two ways to do this; perhaps commenters will have others. The first is to get the domains in the forest, then find one domain controller in each domain and ask it to list all the domain controllers in its own domain. This gets around the limitation of Get-AdDomainController for a single domain (single line wrapped).

    (get-adforest).domains | foreach {Get-ADDomainController -discover -DomainName $_} | foreach {Get-addomaincontroller -filter * -server $_} | ft hostname

    The second is to go directly to the the native  .NET AD DS forest class to return the domains for the forest, then loop through each one returning the domain controllers (single lined wrapped).

    [system.directoryservices.activedirectory.Forest]::GetCurrentForest().domains | foreach {$_.DomainControllers} | foreach {$_.hostname}

    This also lead to updated TechNet content. Good work, Internet!


    Hi, I've been reading up on RID issuance management and the new RID Master changes in Windows Server 2012. They still leave me with a question, however: why are RIDs even needed in a SID? Can't the SID be incremented on it's own? The domain identifier seems to be an adequately large number, larger than the 30-bit RID anyway. I know there's a good reason for it, but I just can't find any material that says why there are separate domain ID and relative ID in a SID.


    The main reason was a SID needs the domain identifier portion to have a contextual meaning. By using the same domain identifier on all security principals from that domain, we can quickly and easily identify SIDs issued from one domain or another within a forest. This is useful for a variety of security reasons under the hood.

    That also allows us a useful technique called “SID compression”, where we want to save space in a user’s security data in memory. For example, let’s say I am a member of five domain security groups:


    With a constant domain identifier portion on all five, I now have the option to use one domain SID portion on all the other associated ones, without using all the memory up with duplicate data:


    The consistent domain portion also fixes a big problem: if all of the SIDs held no special domain context, keeping track of where they were issued from would be a much bigger task. We’d need some sort of big master database (“The SID Master”?) in an environment that understood all forests and domains and local computers and everything. Otherwise we’d have a higher chance of duplication through differing parts of a company. Since the domain portion of the SID unique and the RID portion is an unsigned integer that only climbs, it’s pretty easy for RID masters to take care of that case in each domain.

    You can read more about this in coma-inducing detail here:


    When I want to set folder and application redirection for our user in different forest (with a forest trust) in our Remote Desktop Services server farm, I cannot find users or groups from other domain. Is there a workaround?


    The Object Picker in this case doesn’t allow you to select objects from the other forest – this is a limitation of the UI the that Folder Redirection folks put in place. They write their own FR GP management tools, not the GP team.

    Windows, by default, does not process group policy from user logon across a forest—it automatically uses loopback Replace.  Therefore, you can configure a Folder Redirection policy in the resource domain for users and link that policy to the OU in the domain where the Terminal Servers reside.  Only users from a different forest should receive the folder redirection policy, which you can then base on a group in the local forest.


    Does USMT support migrating multi-monitor settings from Windows XP computers, such as which one is primary, the resolutions, etc.?


    USMT 4.0 does not supported migrating any monitor settings from any OS to any OS (screen resolution, monitor layout, multi-monitor, etc.). Migrating hardware settings and drivers from one computer to another is dangerous, so USMT does not attempt it. I strongly discourage you from trying to make this work through custom XML for the same reason – you may end up with unusable machines.

    Starting in USMT 5.0, a new replacement manifest – Windows 7 to Windows 7, Windows 7 to Windows 8, or Windows 8 to Windows 8 only – named “” was added. For the first time in USMT, it migrates:

    <pattern type="Registry">HKLM\System\CurrentControlSet\Control\GraphicsDrivers\Connectivity\* [*]</pattern>
    <pattern type="Registry">HKLM\System\CurrentControlSet\Control\GraphicsDrivers\Configuration\* [*]</pattern>

    This is OK on Win7 and Win8 because the OS itself knows what valid and invalid are in that context and discards/fixes things as necessary. I.e. this is safe is only because USMT doesn’t actually do anything but copy some values and relies on the OS to fix things after migration is over.


    Our proprietary application is having memory pressure issues and it manifests when someone runs gpupdate or waits for GP to refresh; some times it’s bad enough to cause a crash.  I was curious if there was a way to stop the policy refresh from occurring.


    Only in Vista and later does preventing total refresh become possible vaguely possible; you could prevent the group policy service from running at all (no, I am not going to explain how). The internet is filled with thousands of people repeating a myth that preventing GP refresh is possible with an imaginary registry value on Win2003/XP – it isn’t.

    What you could do here is prevent background refresh altogether. See the policies in the “administrative templates\system\group policy” section of GP:

    1. You could enable policy “group policy refresh interval for computers” and apply it to that one server. You could set the background refresh interval to 45 days (the max). That way it be far more likely to reboot in the meantime for a patch Tuesday or whatever and never have a chance to refresh automatically.

    2. You could also enable each of the group policy extension policies (ex: “disk quota policy processing”, “registry policy processing”) and set the “do not apply during periodic background processing” option on each one.  This may not actually prevent GPUPDATE /FORCE though – each CSE may decide to ignore your background refresh setting; you will have to test, as this sounds boring.

    Keep in mind for #1 that there are two of those background refresh policies – one per user (“group policy refresh interval for users”), one per computer (“group policy refresh interval for computers”). They both operate in terms of each boot up or each interactive logon, on a per computer/per user basis respectively. I.e. if you logon as a user, you apply your policy. Policy will not refresh for 45 days for that user if you were to stay logged on that whole time. If you log off at 22 days and log back on, you get apply policy, because that is not a refresh – it’s interactive logon foreground policy application.

    Ditto for computers, only replace “logon” with “boot up”. So it will apply the policy at every boot up, but since your computers reboot daily, never again until the next bootup.

    After those thoughts… get a better server or a better app. :)


    I’m testing Virtualized Domain Controller cloning in Windows Server 2012 on Hyper-V and I have DCs with snapshots. Bad bad bad, I know, but we have our reasons and we at least know that we need to delete them when cloning.

    Is there a way to keep the snapshots on the source computer, but not use VM exports? I.e. I just want the new copied VM to not have the old source machine’s snapshots.


    Yes, through the new Hyper-V disk management Windows PowerShell cmdlets or through the management snap-in.

    Graphical method

    1. Examine the settings of your VM and determine which disk is the active one. When using snapshots, it will be an AVHD/X file.


    2. Inspect that disk and you see the parent as well.


    3. Now use the Edit Disk… option in the Hyper-V manager to select that AVHD/X file:


    4. Merge the disk to a new copy:



    Windows PowerShell method

    Much simpler, although slightly counter-intuitive. Just use:


    For example, to export the entire chain of a VM's disk snapshots and parent disk into a new single disk with no snapshots named DC4-CLONED.VHDX:


    You don’t actually have to convert the disk type in this scenario (note how I went from dynamic to dynamic). There is also Merge-VHD for more complex differencing disk and snapshot scenarios, but it requires some extra finagling and disk copying, and  isn’t usually necessary. The graphical merge option works well there too.

    As a side note, the original Understand And Troubleshoot VDC guide now redirects to TechNet. Coming soon(ish) is an RTM-updated version of the original guide, in web format, with new architecture, troubleshooting, and other info. I robbed part of my answer above from it – as you can tell by the higher quality screenshots than you usually see on AskDS – and I’ll be sure to announce it. Hard.


    It has always been my opinion that if a DC with a FSMO role went down, the best approach is to seize the role on another DC, rebuild the failed DC from scratch, then transfer the role back. It’s also been my opinion that as long as you have more than one DC, and there has not been any data loss, or corruption, it is better to not restore.

    What is the Microsoft take on this?


    This is one of those “it depends” scenarios:

    1. The downside to restoring from (usually proprietary) backup solutions is that the restore process just isn’t something most customers test and work out the kinks on until it actually happens; tons of time is spent digging out the right tapes, find the right software, looking up the restore process, contacting that vendor, etc. Often times a restore doesn’t work at all, so all the attempts are just wasted effort. I freely admit that my judgment is tainted through my MS Support experience here – customers do not call us to say how great their backups worked, only that they have a down DC and they can’t get their backups to restore.

    The upside is if your recent backup contained local changes that had never replicated outbound due to latency, restoring them (even non-auth) still means that those changes will have a chance to replicate out. E.g. if someone changed their password or some group was created on that server and captured by the backup, you are not losing any changes. It also includes all the other things that you might not have been aware of – such as custom DFS configurations, operating as a DNS server that a bunch of machines were solely pointed to, 3rd party applications pointed directly to the DC by IP/Name for LDAP or PDC or whatever (looking at you, Open Source software!), etc. You don’t have to be as “aware”, per se.

    2. The downside to seizing the FSMO roles and cutting your losses is the converse of my previous point around latent changes; those objects and attributes that could not replicate out but were caught by the backup are gone forever. You also might miss some of those one-offs where someone was specifically targeting that server – but you will hear from them, don’t worry; it won’t be too hard to put things back.

    The upside is you get back in business much faster in most cases; I can usually rebuild a Win2008 R2 server and make it a DC before you even find the guy that has the combo to the backup tape vault. You also don’t get the interruptions in service for Windows from missing FSMO roles, such as DCs that were low on their RID pool and now cannot retrieve more (this only matters with default, obviously; some customers raise their pool sizes to combat this effect). It’s typically a more reliable approach too – after all, your backup may contain the same time bomb of settings or corruption or whatever that made your DC go offline in the first place. Moreover, the backup is unlikely to contain the most recent changes regardless – backups usually run overnight, so any un-replicated originating updates made during the day are going to be nuked in both cases.

    For all these reasons, we in MS Support generally recommend a rebuild rather than a restore, all things being equal. Ideally, you fix the actual server and do neither!

    As a side note, restoring the RID master used to cause issues that we first fixed in Win2000 SP3. This unfortunately has live on as a myth that you cannot safely restore the RID master. Nevertheless, if someone impatiently seizes that role, then someone else restores that backup, you get a new problem where you cannot issue RIDs anymore. Your DC will also refuse to claim role ownership with a restored RID Master (or any FSMO role) if your restored server has an AD replication problem that prevents at least one good replication with a partner. Keep those in mind for planning no matter how the argument turns out!


    I am trying out Windows Server 2012 and its new Minimal Server Interface. Is there a way to use WMI to determine if a server is running with a Full Installation, Core Installation, or a Minimal Shell installation?


    Indeed, although it’s not made it way to MSDN quite yet. The Win32_ServerFeature class returns a few new properties in our latest operating system. You can use WMIC or Windows PowerShell to browse the installed ones. For example:


    The “99” ID is Server Graphical Shell, which means, in practical terms, “Full Installation”. If 99 alone is not present, that means it’s a minshell server. If the “478” ID is also missing, it’s a Core server.

    E.g. if you wanted to apply some group policy that only applied to MinShell servers, you’d set your query to return true if 99 was not present but 478 was present.

    Other Stuff

    Speaking of which, Windows Server 2012 General Availability is September 4th. If you manage to miss the run up, you might want to visit an optometrist and/or social media consultant.

    Stop worrying so much about the end of the world and think it through.

    So awesome:

    And so fake :(

    If you are married to a psychotic Solitaire player who poo-poo’ed switching totally to the Windows 8 Consumer Preview because they could not get their mainline fix of card games, we have you covered now in Windows 8 RTM. Just run the Store app and swipe for the Charms Bar, then search for Solitaire.


    It’s free and exactly 17 times better than the old in-box version:

    OMG Lisa, stop yelling at me! 

    Is this the greatest geek advert of all time?

    Yes. Yes it is.

    When people ask me why I stopped listening to Metallica after the Black Album, this is how I reply:

    Hetfield in Milan
    Ride the lightning Mercedes

    We have quite a few fresh, youthful faces here in MS Support these days and someone asked me what “Mall Hair” was when I mentioned it. If you graduated high school between 1984 and 1994 in the Midwestern United States, you already know.

    Finally – I am heading to Sydney in late September to yammer in-depth about Windows Server 2012 and Windows 8. Anyone have any good ideas for things to do? So far I’ve heard “bridge climb”, which is apparently the way Australians trick idiot tourists into paying for death. They probably follow it up with “funnel-web spider petting zoo” and “swim with the saltwater crocodiles”. Lunatics.

    Until next time,

    - Ned “I bet James Hetfield knows where I can get a tropical drink by the pool” Pyle

  • AD Replication Status Tool is Live

    Hey all, Ned here with some new troubleshooting tool love, courtesy of the ADREPLSTATUS team at Microsoft. I’ll let them do the talking:

    The Active Directory Replication Status Tool (ADREPLSTATUS) is now LIVE and available for download at the Microsoft Download Center.

    ADREPLSTATUS helps administrators identify, prioritize and resolve Active Directory replication errors on a single DC or all DCs in an Active Directory Domain or Forest. Cool features include:

    • Auto-discovery of the DCs and domains in the Active Directory forest to which the ADREPLSTATUS computer is joined
    • “Errors only” mode allows administrators to focus only on DCs reporting replication failures
    • Upon detection of replication errors, ADREPLSTATUS uses its tight integration with resolution content on Microsoft TechNet to display the resolution steps for the top AD Replication errors
    • Rich sorting and grouping of result output by clicking on any single column header (sort) or by dragging one or more column headers to the filter bar. Use one or both options to arrange output by last replication error, last replication success date, source DC naming context and last replication success date, etc.)
    • The ability to export replication status data so that it can be imported and viewed by source domain admins, destination domain admins or support professionals using either Microsoft Excel or ADREPLSTATUS
    • The ability to choose which columns you want displayed and their display order. Both settings are saved as a preference on the ADREPLSTATUS computer
    • Broad OS version support (Windows XP -> Windows Server 2012 Preview)

    ADREPLSTATUs UI consists of a toolbar and Office-style ribbon to expose different features. The Replication Status Viewer tab displays the replication status for all DCs in the forest. The screenshot below shows ADREPLSTATUS highlighting a DC that has not replicated in Tombstone Lifetime number of days (identified here by the black color-coding)

    Click me

    Using the Errors Only button, you can filter out healthy DCs to focus on destination DCs reporting replication errors.

    Click me

    The Replication Error Guide has a Detected Errors Summary view that records each unique replication error occurring on the set of DCs targeted by the administrator.

    Click me

    Close up of the Detected Errors Summary view.

    Click me

    Selecting any of the replication error codes loads the recommended troubleshooting content for that replication error. The TechNet Article for AD Replication Error 1256 is shown below.

    Click me

    The goals for this tool are to help administrators identify and resolve Active Directory replication errors before they cause user and application failures, outages or lingering objects caused short and long-term replication failures, and to provide administrators greater insight into the operation of Active Directory replication within their environments.

    The current version of ADREPLSTATUS as of this posting is 2.2.20717.1 (as reported by ADREPLSTATUS startup splash screen).

    Known Issues



    ADREPLSTATUS fails to launch on highly secure computers.


    ADREPLSTATUS will not work when the following security setting is enabled on the operating system:

    • System cryptography: Use FIPS 140 compliant cryptographic algorithms, including encryption, hashing and signing algorithms

    Extra checkmark appears at bottom of column chooser when right clicking on a column header


    Known issue and by design.


    • ADREPLSTATUS is a read-only tool and makes no changes to the configuration of, or objects in an Active Directory forest
    • The ADRPLSTATUS tool is supported by the ADREPLSTATUS team at Microsoft. Administrators and support professionals who experience errors installing or executing ADREPLSTATUS may submit a “problem report” on the following web page:

    • If the issue is known, the ADREPLSTATUS team will reply to this page with the status of the issue. The status field will be listed as “known issue”, “by design”, “investigating”, “In progress” or “resolved” with supporting text
    • If a problem requires additional investigation, the ADREPLSTATUS team will contact you at the email address provided in your problem report submission
    • ETA for problem resolution will depend on team workload, problem complexity and root cause. Code defects within the ADREPLSTATUS tool can typically be resolved more quickly. Tool failures due to external root causes will take longer unless a work-around can be found
    • The ADREPLSTATUS team cannot and will not resolve AD replication errors identified by the ADREPLSTATUS tool. Contact your support provider, including Microsoft support for assistance as required. You may also submit and research replication errors on:


    Until next time,

    Ned “repple depple” Pyle

  • Detaining Docs with DAC

    Hey all, Ned here again with a quick advert:

    Robert Deluca from our Partner and Customer team just published a blog post on Dynamic Access Control. He walks through the configuration of “document quarantine” to protect sensitive data on file shares and automatically clean up files that violate storage policies. We’ve seen a lot of DAC blog posts over the past couple of months but this one talks about a real-world scenario Robert encountered with some of our early Beta customers.

    Document Quarantine with Windows Server 2012 Dynamic Access Control

    Definitely take a look at this one!

    - Ned "CDC" Pyle

  • RSA Key Blocking is Here!

    Hello everyone. Jonathan here again with another Public Service Announcement post.

    Today, Microsoft has published a new Security Advisory:

    Microsoft Security Advisory (2661254): Update For Minimum Certificate Key Length

    The Security Advisory and the accompanying KB article have complete information about the software update, but the key takeaway is that this update is now available on the Download Center and the Microsoft Update Catalog. In addition, Microsoft will release this software update through Microsoft Update (aka Windows Update) in October 2012. So all of you enterprise customers have two months to start testing this update to see what impact it has in your environments.

    If you want information on finding weak keys in your environment then review the KB article. It describes several methods you can use. Microsoft Support has also created a PowerShell script that has been posted to the the TechNet Script Center.

    Finally, I have one final warning for those of you that use makecert.exe to create test certificates. By default, makecert.exe creates certificates that chains up to the Root Agency root CA certificate located in the Intermediate Certification Authorities store. The Root Agency CA certificate has a public key of 512 bits, so once you deploy this update no certificate created with makecert.exe will be considered valid.

    You should now consider makecert.exe deprecated. As a replacement, starting with Windows 7 / Windows Server 2008 R2, you can use certreq.exe to create a self-signed certificate. For example, to create a self-signed code signing certificate you can create the following .INF file:

    Subject = "CN=Self Signed Cert"
    KeyLength = 2048
    ProviderName = "Microsoft Enhanced Cryptographic Provider v1.0"
    KeySpec = "AT_SIGNATURE"
    RequestType = Cert
    SMIME = False
    ValidityPeriod = Years
    ValidityPeriodUnits = 2

    OID =

    The important line above is the RequestType value. That tells certreq.exe to create a self-signed certificate. Along with that value, the ValidityPeriod and ValidityPeriodUnits values allow you specify the lifetime of the self-signed certificate.

    Once you create the .INF file, run the following command:

    Certreq -new  selfsigned.inf selfsigned.crt

    This will take your .INF file and generate a new self-signed certificate that you can use for testing.

    Ok, so this was supposed to be a short post pointing to where you need to go, but it turns out that I had some other related stuff. The important message here is go read the Security Advisory and the KB article.

    Go read the Security Advisory and the KB article.

    Ex pace.

    Jonathan “I am the Key Master” Stephens

  • Managing RID Issuance in Windows Server 2012

    Hi all, Ned here again to talk further about managing your RID pool.

    By default, a domain has capacity for roughly one billion security principals, such as users, security groups, managed service accounts, and computers. If you run out, you can’t create any more.

    There aren’t any domains with that many active objects, of course, but we've seen:

    • Provisioning software or administrative scripts accidentally bulk created users, groups, and computers
    • Many unused security and distribution groups created by delegated users
    • Many domain controllers demoted, restored, or metadata cleaned
    • Forest recoveries with an inappropriately set lower RID pool
    • The InvalidateRidPool operation performed too frequently
    • The RID Block Size registry value increased incorrectly
    • RID Master seized

    All of these situations use up RIDs unnecessarily, often by mistake. Over many years, a few environments ran out of RIDs and this forced customers to migrate to a new domain or revert with domain and forest recoveries.

    Windows Server 2012 addresses issues with RID allocation that have become more likely with the age and ubiquity of Active Directory. These include better event logging, more appropriate limits, and the ability to - in an emergency - increase the overall RID pool allocation by one bit.

    Let's get to it.

    Periodic Consumption Warnings

    Windows Server 2012 adds global RID space event tracking that provide early warning when major milestones are crossed. The model computes the ten (10) percent used mark in the global pool and logs an event when reached. Then it computes the next ten percent used of the remaining and the event cycle continues. As the global RID space is exhausted, events will accelerate as ten percent hits faster in a decreasing pool (but event log dampening will prevent more than one entry per hour). The System event log on every domain controller writes Directory-Services-SAM warning event 16658.

    Assuming a default 30-bit global RID space, the first event logs when allocating the pool containing the 107,374,182ND RID. The event rate accelerates naturally until the last checkpoint of 100,000, with 110 events generated in total. The behavior is similar for an unlocked 31-bit global RID space: starting at 214,748,365 and completing in 117 events.


    Understand that these events are never "expected": investigate the user, computer, and group creation processes immediately in the domain if you see the event. Creating more than 100 million AD DS objects is quite out of the ordinary!


    RID Pool Invalidation Events

    There are new event alerts that a local DC RID pool was discarded. These are Informational and could be expected, especially due to the new virtualized domain controller functionality. See the event list later for details on the event.

    RID Block Size Cap

    Ordinarily, a domain controller requests RID allocations in blocks of 500 RIDs at one time. You can override this default using the following registry REG_DWORD value on a domain controller:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\RID Values

    RID Block Size

    Prior to Windows Server 2012, there was no maximum value enforced in that registry key, except the implicit DWORD maximum (which has a value of 0xffffffff or 4294967295). This value is considerably larger than the total global RID space. Administrators sometimes inappropriately or accidentally configured RID Block Size with values that exhausted the global RID at a massive rate.

    In Windows Server 2012, you cannot set this registry value higher than 15,000 decimal (0x3A98 hexadecimal). This prevents massive unintended RID allocation.

    If you set the value higher than 15,000, the value is treated as 15,000 and the domain controller logs event 16653 in the Directory Services event log at every reboot until the value is corrected.

    Global RID Space Size Unlock

    Prior to Windows Server 2012, the global RID space was limited to 230 (or 1,073,741,823) total RIDs. Once reached, only a domain migration or forest recovery to an older timeframe allowed new SIDs creation - disaster recovery, by any measure. Starting in Windows Server 2012, the 231 bit can be unlocked in order to increase the global pool to 2,147,483,647 RIDs.

    AD DS stores this setting in a special hidden attribute named SidCompatibilityVersion on the RootDSE context of all domain controllers. This attribute is not readable using ADSIEdit, LDP, or other tools. To see an increase in the global RID space, examine the System event log for warning event 16655 from Directory-Services-SAM or use the following Dcdiag command:

    Dcdiag.exe /TEST:RidManager /v | find /i "Available RID Pool for the Domain"

    If you increase the global RID pool, the available pool will change to 2,147,483,647 instead of the default 1,073,741,823. For example:



    This unlock is intended only to prevent running out of RIDS and is to be used only in conjunction with RID Ceiling Enforcement (see next section). Do not "preemptively" set this in environments that have millions of remaining RIDs and low growth, as application compatibility issues potentially exist with SIDs generated from the unlocked RID pool.

    This unlock operation cannot be reverted or removed, except by a complete forest recovery to an earlier backup.

    Windows Server 2003 and Windows Server 2008 Domain Controllers cannot issue RIDs when the global RID pool 31st bit is unlocked. Windows Server 2008 R2 domain controllers can use 31st bit RIDs but only if they install hotfix KB2642658. Unsupported and unpatched domain controllers treat the global RID pool as exhausted when unlocked.

    Implementing Unlocked Global RID space

    To unlock the RID pool to the 31st bit after receiving the RID ceiling alert perform the following steps:

    1. Ensure that the RID Master role is running on a Windows Server 2012 domain controller. If not, transfer it to a Windows Server 2012 domain controller

    2. Run LDP.exe

    3. Click the Connection menu and click Connect for the Windows Server 2012 RID Master on port 389, and then click Bind as a domain administrator

    4. Click the Browse menu and click Modify

    5. Ensure that DN is blank

    6. In Edit Entry Attribute, type:


    7. In Values, type:


    8. Ensure that Add is selected in Operation and click Enter. This updates the Entry List

    9. Select the Synchronous option, then click Run:


    10. If successful, the LDP output window shows:

    ***Call Modify...

     ldap_modify_ext_s(Id, '(null)',[1] attrs, SvrCtrls, ClntCtrls);

    modified "".


    11. Confirm the global RID pool increased by examining the System Event Log on that domain controller for Directory-Services-SAM Informational event 16655.

    RID Ceiling Enforcement

    To afford a measure of protection and elevate administrative awareness, Windows Server 2012 introduces an artificial ceiling on the global RID range at ten (10) percent remaining RIDs in the global space. When within one (1) percent of the artificial ceiling, domain controllers requesting RID pools write Directory-Services-SAM warning event 16657 to their System event log. When reaching the ten percent ceiling on the RID Master FSMO, it writes Directory-Services-SAM event 16657 to its System event log and will not allocate any further RID pools until overriding the ceiling. This forces you to assess the state of the RID Master in the domain and address potential runaway RID allocation; this also protects domains from exhausting the entire RID space.

    This ceiling is hard-coded at ten percent remaining of the available RID space. I.e. the ceiling activates when the RID master allocates a pool that includes the RID corresponding to ninety (90) percent of the global RID space.

    • For default domains, the first trigger point is 230-1 * 0.90 = 966,367,640 (or 107,374,183 RIDs remaining).
    • For domains with an unlocked 31-bit RID space, the trigger point is 231-1 * 0.90 = 1,932,735,282 RIDs (or 214,748,365 RIDs remaining).

    You can hit this event twice in the lifetime of a domain - once with a default-sized RID pool and once when you unlock. Preferably never, of course.

    When triggered, the RID Master sets AD attribute msDS-RIDPoolAllocationEnabled (common name ms-DS-RID-Pool-Allocation-Enabled) to FALSE on the object:

    CN=RID Manager$,CN=System,DC=<domain>

    This writes the 16657 event and prevents further RID block issuance to all domain controllers. Domain controllers continue to consume any outstanding RID pools already issued to them.

    To remove the block and allow RID pool allocation to continue, set that value to TRUE. On the next RID allocation performed by the RID Master, the attribute will return to its default NOT SET value. After that, there are no further ceilings and eventually, the global RID space runs out, requiring forest recovery or domain migration.


    Do not just arbitrarily remove the ceiling once hit - after all, something weird and potentially bad has happened here and your RID Master is trying to tell you. Stop and take stock, find out what caused the increase, and don’t proceed until you are darned sure that you are not going to run out immediately due to some sort of run-away process or procedure in your environment.

    Removing the Ceiling Block

    To remove the block once reaching the artificial ceiling, perform the following steps:

    1. Ensure that the RID Master role is running on a Windows Server 2012 domain controller. If not, transfer it to a Windows Server 2012 domain controller

    2. Run LDP.exe

    3. Click the Connection menu and click Connect for the Windows Server 2012 RID Master on port 389, and then click Bind as a domain administrator

    4. Click the View menu and click Tree, then for the Base DN select the RID Master's own domain naming context. Click Ok

    5. In the navigation pane, drill down into the CN=System container and click the CN=RID Manager$ object. Right click it and click Modify

    6. In Edit Entry Attribute, type:


    7. In Values, type (in upper case):


    8. Select Replace in Operation and click Enter. This updates the Entry List.

    9. Enable the Synchronous option, then click Run:


    10. If successful, the LDP output window shows:

    ***Call Modify...

    ldap_modify_ext_s(ld, 'CN=RID Manager$,CN=System,DC=<domain>',[1] attrs, SvrCtrls, ClntCtrls);

    Modified "CN=RID Manager$,CN=System,DC=<domain>".


    Events and Error Messages

    The following new messages log in the System event log on Windows Server 2012 domain controllers. Automated AD health tracking systems, such as System Center Operations Manager, should monitor for these events; all are notable, and some are indicators of critical domain issues.

    Event ID







    A pool size for account-identifiers (RIDs) that was configured by an Administrator is greater than the supported maximum. The maximum value of 15,000 will be used when the domain controller is the RID master. See for more information.

    Notes and resolution

    The maximum value for the RID Block Size is now 15000 decimal (3A98 hexadecimal). A domain controller cannot request more than 15,000 RIDs. This event logs at every boot until the value is set to a value at or below this maximum.

    Event ID







    A pool of account-identifiers (RIDs) has been invalidated. This may occur in the following expected cases:

    1. A domain controller is restored from backup.

    2. A domain controller running on a virtual machine is restored from snapshot.

    3. An administrator has manually invalidated the pool.

    See for more information.

    Notes and resolution

    If this event is unexpected, contact all domain administrators and determine which of them performed the action. The Directory Services event log also contains further information on when one of these steps was performed.

    Event ID







    The global maximum for account-identifiers (RIDs) has been increased to %1. See for more information including important operating system interoperability requirements.

    Notes and resolution

    If this event is unexpected, contact all domain administrators and determine which of them performed the action. This event notes the increase of the overall RID pool size beyond the default of 230 and will not happen automatically; only by administrative action.

    Event ID







    Action required! An account-identifier (RID) pool was allocated to this domain controller. The pool value indicates this domain has consumed a considerable portion of the total available account-identifiers.

    A protection mechanism will be activated when the domain reaches the following threshold of total available account-identifiers remaining: %1. 

    The protection mechanism prevents the allocation of account-identifier (RID) pools needed to allow existing DCs to create additional users, computers and groups, or promote new DCs into the domain. The mechanism will remain active until the Administrator manually re-enables account-identifier allocation on the RID master domain controller.

    See for more information.

    Notes and resolution

    Contact all domain administrators and inform them that the domain is close to preventing any further principal creation. Interrogate all administrators to find out who or what is creating principals lately and examine the Diagnosis section here for more inventory steps.

    Event ID







    Action required! This domain has consumed a considerable portion of the total available account-identifiers (RIDs). A protection mechanism has been activated because the total available account-identifiers remaining is approximately: %1.

    The protection mechanism prevents the allocation of account-identifier (RID) pools needed to allow existing DCs to create additional users, computers and groups, or promote new DCs into the domain.  The mechanism will remain active until the Administrator manually re-enables account-identifier (RID) allocation on the RID master domain controller.

    It is extremely important that certain diagnostics be performed prior to re-enabling account creation to ensure this domain is not consuming account-identifiers at an abnormally high rate. Any issues identified should be resolved prior to re-enabling account creation.

    Failure to diagnose and fix any underlying issue causing an abnormally high rate of account-identifier consumption can lead to account-identifier (RID) pool exhaustion in the domain after which account creation will be permanently disabled in this domain.

    See for more information

    Notes and resolution

    Contact all domain administrators and inform them that no further security principals can be created in this domain until this protection is overridden. Interrogate all administrators to find out who or what is creating principals lately and examine the Diagnosis section here for more inventory steps. Use the steps above to unlock the 31st RID bit only after you have determined that any runaway issuance is not going to continue.

    Event ID







    This event is a periodic update on the remaining total quantity of available account-identifiers (RIDs). The number of remaining account-identifiers is approximately: %1.

    Account-identifiers are used as accounts are created, when they are exhausted no new accounts may be created in the domain.

    See for more information

    Notes and resolution

    Contact all domain administrators and inform them that RID consumption has crossed a major milestone; determine if this is expected behavior or not by reviewing security trustee creation patterns. To ever see this event would be highly unusual, as it means that at least ~100 million RIDS have been allocated.

    These are just some of the excellent supportability changes available in Windows Server 2012 AD DS. For more info, check out the TechNet library starting at:

    I hope to have more of these kinds of posts coming along soon, as the gloves were taken off this week for Windows Server 2012. You know me though – something shiny goes by and I vanish for weeks. We’ll see…

    Ned “The Chronicles of RID” Pyle

  • Windows PowerShell remoting and delegating user credentials

    Hey all Rob Greene here again. Yeah, I know, it’s been a while since I’ve written anything for you good people of the Internet.

    I recently had an interesting issue with the Active Directory Web Services and the Active Directory Windows PowerShell 2.0 modules in Windows 7 and Windows Server 2008 R2. Let me explain the scenario to you.

    We have a group of helpdesk users that need to be able to run certain Windows PowerShell commands to manage users and objects within Active Directory. We do not want to install any of the Active Directory RSAT tools on helpdesk groups Windows 7 workstations directly because these users should not have access to Active Directory console snap-ins [Note: as pointed out in the Comments, you don't have to install all RSAT AD tools if you just want AD Windows PowerShell; now back to the action - the Neditor]. We have written specific Windows PowerShell scripts that the help desk users employ to manage user accounts. We are storing the Windows PowerShell scripts on a central server that the users need to be able to access and run the scripts remotely.

    Hmmm…. Well my mind starts thinking, man this is way too complicated, but hey that’s what our customers like to do sometimes… Make things complicated.


    The basic requirement is that the help desk admins must run some Windows PowerShell scripts on a remote computer that leverages the ActiveDirectory Windows PowerShell cmdlets to manage user accounts in the domain.

    So let’s think about the “ask” here:

    • We are going to require Windows PowerShell remoting from the Windows 7 client to the middle tier server where the ActiveDirectory Windows PowerShell modules are installed.

    By default you must connect to the remote server with an Administrator level account when PS remoting otherwise the remote session will not be allowed to connect. That means the helpdesk users cannot connect to the domain controllers directly.

    If you are interested in changing this requirement the Scripting Guy blog has two ways of doing this via:

    • The middle tier server where the ActiveDirectory Windows PowerShell cmdlets are installed has to connect to a domain controller running the Active Directory Web Service as the PS remoted user account.

    Wow, how do we make all this happen?

    1. You need to enable Windows PowerShell Remoting on the Remote Admin Server. The simplest way to do this is by launching an elevated Windows PowerShell command prompt and type:

    Enable-PSRemoting -Force

    To specify HTTPS be used for the remote connectivity instead of HTTP, you can use the following cmdlet (this requires a certificate environment that's outside the scope of this conversation):

    Set-WSManQuickConfig –Force -UseSSL

    2. On the Remote Admin Server you will also want to make sure that the “Windows Remote Management (WS-Management)” service is started and set to automatic.

    If you have done a decent amount of Windows PowerShell scripting you probably got this part.

    Alright, the next part is kind of tricky. Since we are delegating the user’s credentials from the Remote Admin Server to the ADWS service, you are probably thinking that we are going to setup some kind of Kerberos delegation here. That would be incorrect. Windows PowerShell remoting does not support Kerberos delegation. You have to use CredSSP to delegate the user account to the Remote Admin Server (which does a logon to the Remote Admin Server) and then it is allowed to interact with the ADWS service on the domain controller.

    More information about CredSSP:

    MSDN Magazine: Credential Security Support Provider

    951608 Description of the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3

    If you have done some research on CredSSP, it takes the user's name and password and passes it on to the target server. It is not sending a Kerberos ticket or NTLM token for validation. This can be somewhat risky. Just like with Windows PowerShell remoting CredSSP usage is disabled by default and must be enabled. The other key thing to understand about CredSSP is you have to enable the “Client” and the “Server” to be able to use it.

    NOTE: Although Windows XP Service Pack 3 does have CredSSP in it. The version of Windows PowerShell for Windows XP does not support CredSSP with remote management.

    3. On the Remote Admin Server, we need to enable Windows Remote Management to support CredSSP. We do this by typing the command below in an elevated Windows PowerShell command window:

    Enable-WSManCredSSP –Role Server -Force

    4. On the Windows 7 client, we need to configure the “Windows Remote Management (WS-Management)” service startup to Automatic. Failure to do this will result in the following error being displayed at the next step:

    Enable-WSManCredSSP : The client cannot connect to the destination specified in the request. Very that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination to analyze and configure the winRM service: “winrm quickconfig”

    5. On the Windows 7 client, we need to enable Windows Remote Management to support CredSSP. We do this by typing the command below in an elevated Windows PowerShell command window:

    Enable-WSManCredSSP -Role Client -DelegateComputer * -Force

    NOTE: “*” is a placeholder for your DNS domain name. Within the client configuration is where you can constrain the CredSSP credentials to certain “Targets” or destination computers. If you want them to only work to a specific computer replace * with the specific servers name.

    6. Lastly, when the remote session is created to the target server we need to make sure that the “-Authentication CredSSP” switch is provided. Here are a couple of remote session examples:

    Enter-PSSession -ComputerName -Credential (Get-Credential) -Authentication CredSSP

    Invoke-Command –ComputerName –Credential (Get-Credential) –Authentication CredSSP –ScriptBlock {Import-Module ActiveDirectory; get-aduser administrator}

    I hope that you have some new information around Windows PowerShell remoting today to make your Windows PowerShell adventures more successful. This story changes in Windows 8 and Windows Server 2012 for the better, so use this article only with your legacy operating systems.

    Rob “Power Shrek” Greene

  • Shipped it

    Windows 8 RTM

      Windows Server 2012 RTM

         IT Pros






    - Ned "terse" Pyle