09 May 2014

Remove Server Manager and PowerShell from Taskbar on RDS

Best article on this is at

http://www.emware.nl/articles/remove-server-manager-and-powershell-icons-from-taskbar.html

The only thing I would add is to also include the following files



  • %AllUsersProfile%\Microsoft\Windows\Start Menu\Programs\Accessories\Windows PowerShell\Windows PowerShell (x86).lnk
  • %AllUsersProfile%\Microsoft\Windows\Start Menu\Programs\Administrative Tools\Windows PowerShell (x86).lnk
  • %AllUsersProfile%\Microsoft\Windows\Start Menu\Programs\Windows System\Windows PowerShell.lnk
  • %AllUsersProfile%\Microsoft\Windows\Start Menu\Programs\System Tools\Windows PowerShell.lnk


  • References:

    Redirecting and Managing Modern Start Menu in Windows 2012

    The following text was created by the author of the http://msfreaks.wordpress.com/ blog. See that blog for more detail. Specifically http://msfreaks.wordpress.com/2014/04/17/step-by-step-redirecting-and-managing-the-modern-start-menu-in-windows-2012r2-rds/


    As a starter:
    - redirect the startmenu for all users to a shared location
    - enable access based enumeration for that share
    - copy shortcuts to applications to that share (best to make a folder for each application)
    - create security groups for the applications you wish to restrict to certain groups of users
    - replace the security on the folder in the redirected startmenu. remove authenticated users and such, and add the correct application security group with read rights
    If you look in the startmenu now, you will not only see the application folders as "groups" in the all programs part of the startmenu, you will also only see applications for which you were granted access rights.
    Login with a test user, arrange your tile-menu, and then, while this test user is logged on, export the .ms file holding the tile positions and such. Add this .ms readonly file to the correct location in the default user profile and mark it read-only, and make sure (script, gpo) that this .ms is marked read-write when a new user first logs on.

    Some other methods are available here also:
    http://technet.microsoft.com/en-us/library/jj134269



    References:
    http://social.technet.microsoft.com/Forums/windowsserver/en-US/da1b4dc6-efaf-4427-a1db-250b930e868d/2012-rds-and-publishing-full-desktop-and-lockdown?forum=winserverTS
    http://msfreaks.wordpress.com/

    06 May 2014

    Installing Exchange 2010 SP3 on Windows 2012 (NOT R2)

    There are plenty of easily found documents on how to do this, so I'm not going to repeat the instructions here. However, I ran into an issue that none of those articles mentioned, the details of which are below.

    I had installed all of the various Exchange 2010 SP3 prerequisites on Windows Server 2012 and followed all of the articles exactly, but whenever I ran setup.exe (GUI) or setup.com (CLI) to install Exchange, I got the an error containing the following phrase:

    Could not load file or assembly 'System.Management.Automation' or one of its dependencies.
    
    
    If you encounter the error message, you simply need to use Server Management Console to install the Windows PowerShell 2.0 Engine feature.



    References:
    Standard install instructions for Exchange 2010 on Windows 2012 (NOT R2)
    http://oxfordsbsguy.com/2013/03/24/how-to-install-exchange-2010-sp3-on-windows-server-2012/

    Installing the Windows PowerShell 2.0 Engine
    http://technet.microsoft.com/en-us/library/hh849675.aspx

    The forum discussions that gave me a clue as to the PowerShell version issue
    http://stackoverflow.com/questions/15473734/could-not-load-file-or-assembly-system-management-automation


    01 May 2014

    Remote Desktop Server Configuration in Windows 2012

    Check this out. It's grand.

    http://blogs.technet.com/b/askperf/archive/2012/10/30/windows-8-windows-server-2012-remote-desktop-management-server.aspx

    12 February 2014

    Recover NTFRS Issues - Including Active Directory Replication

    This guy lays it all out: http://adfordummiez.com/?p=61

    And here is a copy/paste in case he ever takes it down:
    Environment:
    - Windows 2000/2003/2008 domain controllers using FRS (not DFSR).
    - More than one Domain Controller
    - Atleast one DC with a healthy SYSVOL
    Why do Journal Wraps occur?
    Instan at the AD Troubleshooting blog made an excellent blog entry about:
    You should give it a read to understand what is going on under the hood.
    Symptoms that might occur:
    • Event ID 13568 is logged in the NtFrs event log
    • A generic Event ID 1058 may be logged
    • You make changes to a logon script but not all users got the change
    • Changing a GPO or creating a new GPO is not applied to all users or computers
    • Missing SYSVOL share
    • A RSoP or gpresult report that data or policy object is missing or corrupt
    If you take a look at the 13568 event you’ll see that there is a “solution” to this problem:
    Set the “Enable Journal Wrap Automatic Restore” registry parameter to 1
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters”
    Restart ntfrs service.
    This is not a good solution for post-Server 2000 SP3.
    I don’t know why Microsoft still have this “how-to-fix” in event 13568, but they say in KB 290762:
    Important: Microsoft does not recommend that you use this registry setting, and it should not be used post-Windows 2000 SP3. Appropriate options to reduce journal wrap errors include…
    Update: I had to ask around about this since it was nagging me:
    The event was never changed because the product group didn’t want to pay for the localization cost, nor admit that this registry setting caused more problems than it fixed. It actually came down to ego – the developer of FRS was a real piece of work. So instead the public docs were updated to state not to use that autorecovery registry setting.

    Instead you should go for the Burflags method. This will kick start your SYSVOL up and running. Most often a “non-authoritative” (D2) approach will fix you up.
    The “D2″ key can be set two places in registry:
    Global re-initialization:
    HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
    or
    Replica set specific re-initialization:
    HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\GUID
    If you’re using DFS replica sets that holds a large amount of data that is healthy, go for the “Replica set specific re-initialization”. If you set the Global Burflags, FRS will re-initialize all replica sets, including the DFS namespace the member holds. If they hold a large amount of data… that might take some time.
    To find the GUID of SYSVOL, look for the “Replica Set Name” named “Domain System Volume (SYSVOL SHARE)” under the subkey “HKLM\..\..\Replica Sets”:
    This screenshot have only one GUID since I don’t use DFS in my lab.
    Change the value of Burflags to D2 (hex).
    If you don’t uses DFS you could just set the Global Burflags to D2. It will not make any difference under what subkey you set it. This will re-initialize all replica sets the member holds (in this case the SYSVOL).
    After you have set the Burflags key to D2, you have to restart the NTFRS service on the affected DC.
    Overview of what happens:
    1. The Burflags is set to 0
    2. Event ID 13565 is logged. non-authoritative restore has started
    3. The content of SYSVOL are moved to the pre-existing folder
    4. Event ID 13520 is logged
    5. The local FRS database is rebuilt
    6. It re-join (vvjoin) the replica set
    7.  The “bad DC” will compare all files (file ID and MD5 sum) it has in the Pre-existing folder with the files from an upstream partner.
    8. If a match is found, it will copy the file from the Pre-Existing folder to the original location. If they don’t match, it will pull the file from the upstream partner.
    9. Event ID 13553 is logged
    10. FRS notifies (SysvolReady reg.key = 1) the Netlogon service that SYSVOL is ready and can be shared.
    11. The Netlogon service will share SYSVOL and Netlogon.
    12. Event ID 13516 is logged (finished)

    When you have verified that SYSVOL is shared and in sync, you can delete the content in the Pre-Existing folder to free up space.

    Authoritative restore (D4):
    If your SYSVOL is all messed up on every DC’s, you might have to do an “authoritative restore” using both the D4 and D2 values.
    By the way you should never, ever use the D4 flag on more than one DC as you will have a lot of collisions and morphed folders. The D4 flag should only be set like Microsoft says, as a last resort.
    Quick overview:
    1. Stop the NtFrs service on every DC
    2. Set the D4 flag on one DC that will be authoritative for the replica set(s). The SYSVOL content will not be moved to the pre-existing folder on the authoritative member.
    3. Set the D2 flag on the other DC’s (non-authoritative)
    4. Start the NtFrs service on the “D4″ DC.
    5. Check that Event ID 13553 and 13516 is logged.
    6. If step 5 is ok, start NtFrs on the “D2″ DC’s.
    For detailed steps, see “How to rebuild the SYSVOL tree and its content in a domain”

    References
    :
    How to rebuild the SYSVOL tree and its content in a domain
    http://support.microsoft.com/kb/315457
    Using the BurFlags registry key to reinitialize File Replication Service replica sets
    http://support.microsoft.com/kb/290762
    Backing Up and Restoring an FRS-Replicated SYSVOL Folder
    http://msdn.microsoft.com/en-us/library/cc507518(VS.85).aspx