Keith Smith - My Blog

Keith Smith - My Blog

Must have GPOs for Windows 10

Tuesday, September 27, 2016 - Posted by Keith A. Smith, in Microsoft

I started testing Windows 10 Enterprise in my environment. I know there are a number of new features in Windows 10 that aren't great for domains (PIN codes, Microsoft Accounts, etc.). After digging through all the GPO settings, I decided on the on the following. Once the modification was made and applied to the test machines, I brought in a few non-IT staff for UAT testing of the images. Everything went well, so I decided to share the settings I used in the GPO

  • lock Microsoft Accounts from being added or logging in (will not prevent accessing the Windows Store)
  • Force default lock screen and disable Spotlight
  • Disable WiFi Sense
  • Enable Virtualization Based Security with Secure Boot and DMA Protection only Credential Guard enabled with UEFI lock (NOTE: This will install the Hyper-V Hypervisor, with will cause VMware Workstation to stop working)
  • Disable first sign-in animation
  • Disable advertising ID
  • Configure telemetry to level 0 - Enterprise Only
  • Disable access to pre-release features
  • Disable feedback notifications
  • Disable access to insider builds
  • Disable Cortana
  • Disable Defender
  • Disable Windows Hello
  • Disable lock screen (the swipe up thing)
  • Disable 3rd party advertisements in Windows Spotlight
  • Disable picture and PIN password sign-in
And last but not least is setting explorer's default to This PC instead of Quick Access by doing the following:


Value Name: LaunchTo


Value: 1


View Comments 0 Comments
Share Post   

How to become a windows sysadmin

Friday, March 11, 2016 - Posted by Keith A. Smith, in Microsoft

·    Create two networks/VLANs (desktops and servers)

·    Install Windows Server (VM or standard hardware if you have it available) GUI Mode.

·    Install another server, single NIC on the server VLAN

·    Create your first active directory domain controller.

·    Create another server but this time make it a core server. Make it a domain controller

·    Test AD replication via the GUI and cmd.

·    Create an OU for your workstations; create an OU for your users, and an OU for groups. From now on, any new computer or new user account must go into their respective OU. DO NOT MOVE THE DOMAIN CONTROLLERS FROM THE DOMAIN CONTROLLER OU.

·    Create subnets in Active Directory Sites and Services to match the IP’s used on the VLANs you created.

·    Check out DNS. Do you have a reverse look up zone? No? Then set it up.

·    Check out DNS. Records can get old and out of date and will screw up name to IP resolution. Make it so that scavenging happens automatically.

·    You need to block via windows DNS. Make it so that when a DNS look up is performed, computers use a loop back address. Test this via cmd to make sure it resolves as expected.

·    Set up DHCP on the first domain controller.

·    Set up a scope to hand out IPs for the Desktop VLAN. Make it so that this DHCP scope will be able to give endpoints the information they need networking wise to join a domain

·    Install a Windows endpoint or newer PC on the desktop VLAN

·    Your Windows endpoints are not getting IPs. Why? (hint: it's a routing/broadcast/relay issue)

·    Join that desktop to the domain

·    Now that you are getting IPs from your DHCP server, configure DHCP clustering. Load balancing or failover is your choice. Now test it.

·    Create a non-domain admin account in AD. Fill out the whole profile once the account is created.

·    Login to that Windows endpoint as a regular AD user and an Admin user. Try to install software under the non-admin account first and then the admin account. What is the difference?

·    Create another non-admin account. Make this non-admin user a local admin on that computer. Who else is also a local admin before you make any changes,

·    Review the attributes of that account in AD. You will need advanced features for this.

·    Create an AD group. Add the first non-admin account to this group.

·    On that desktop, install the RSAT tools so you can remotely manage another computer

·    Setup remote management on the core server so that it can be managed from the MMC of another computer (there are a number of ways to do this)

·    Find out what server is holding the FSMO roles via the GUI and the command prompt.

·    Split the FSMO roles between the servers. Try to keep forest level and domain level roles together.

·    On one of the domain controllers, create a file share set it so that only administrators and the second non admin account have access to it. Create another folder and give only the AD group you created permissions.

·    Use group policy to map both shares as network drives as a computer policy to the endpoint.

·    Login to the endpoint as the first domain user. Do you see the network drive mapped in windows explorer? No? Use gpresult via the cmd to find out why. If you do see it, try to access the drive. You should be denied if you set permissions correctly. Login as the second domain user, they should be able to open the mapped drive.

·    What if the account in the group tries to access the second drive? You should be able to get in.

·    Login to the windows endpoint as the second non-admin account. You should not have access to this drive because you are not in the group. Do not log off. Add this account to the group. Can you access the drive now? No? Logoff and login back in. Can you access the drive now?

·    Remove the share from the domain controller. We don't like putting shares on domain controllers if we don't have to.

·    Build out another two servers and join it to the domain as member servers.

·    Install DFS and File server roles/features on both servers.

·    Create a file share on bother servers with the same folder name. Create files on both servers. Make sure they are different. (i.e server1 will have "TextDoc01", server 2 will have "TextDoc02" in their shares).

·    Create a DFS name space. Add those shares to the name space.

·    On a domain joined endpoint, navigate to the DFS namespace you created. You should be able to see both files.

·    Create a DFS Replication group. Make it so that you have two way replication. You should now see both files on both servers. Make a change on one server and see if it replicates to another server. Does it work? Great. (you can shut down the file servers for now if you want or use them for the next step)

·    Configure WSUS so that you will only download Security updates for the desktop and server OS's ( highly recommend that you do not download any updates if you have access to the internet from this server)

·    Bonus points, install WSUS on another server and create a downstream server)

·    Create some groups in WSUS. Servers and endpoints will do nicely for names.

·    Create a new group policy that points workstations into the WSUS workstation group, points to WSUS for updates, and stop workstations from automatically downloading updates.

·    Read up on approving and pushing updates since the current assumption is that there are no updates to be pushed in this enclosed test network since there is no internet access to down load them. I believe there is a way to manually add updates to WSUS but I'm a bit foggy on that. Research it.

·    Do the same for servers.

·    Create a new AD user via powershell.

·    Create a new AD group via powershell.

·    Print a list of all domain users and computers in powershell, names only

·    Use powershell to pull a list of users who have remote as their office. If no users have remote listed as their office, use powershell to set that attribute and then pull users who have remote as their office.

·    Remove a user account from AD using powershell

·    Add a user to a group using powershell

·    Provision new AD users via a CSV in powershell

This is really only scratching the surface of a typical medium-large to enterprise level network. However, this should be enough to get you started.
View Comments 0 Comments
Share Post   

Life and Work Balance

Monday, February 22, 2016 - Posted by Keith A. Smith, in Journal of thoughts

This Post is private, you need to be a active susbcriber to vew this Post. Click here to Subscribe
View Comments 0 Comments
Share Post   

vSphere 6.0 vCenter Windows 2012 R2 with SQL Server Install Guide

Tuesday, September 29, 2015 - Posted by Keith A. Smith, in VMware, Microsoft

VMware vSphere 6.0 has brought a simplified deployment model where the dependency on Microsoft SQL server has been reduced. You now have the option of using the built-in vPostgre SQL provided by VMware, vPostgres on windows is limited to 20 hosts and 200 virtual machines.

vCenter System requirements

Supported Windows Operation System for vCenter 6.0 Installation:

  • Microsoft Windows Server 2008 SP2 64-bit
  • Microsoft Windows Server 2008 R2 64-bit
  • Microsoft Windows Server 2008 R2 SP1 64-bit
  • Microsoft Windows Server 2012 64-bit
  • Microsoft Windows Server 2012 R2 64-bit

Supported Databases for vCenter 6.0 Installation:

  • Microsoft SQL Server 2008 R2 SP1
  • Microsoft SQL Server 2008 R2 SP2
  • Microsoft SQL Server 2012
  • Microsoft SQL Server 2012 SP1
  • Microsoft SQL Server 2014
  • Oracle 11g R2
  • Oracle 12c

1. Make sure that you using static IP for your VM and you create forward and reverse DNS records on your DNS server. Also make sure that the machine is part of Windows domain.

2. Create an account in your Active Directory, this will be used on the SQL server for the vCenter database

3. Now you need to create a blank SQL database on an SQL server.

4. Once your blank database is created, you need to add the account you created in your Active Directory. Make sure to give it sysadmin for the server role.

Before you start the installer make sure your Windows Server VM is fully patched, otherwise you might get a prompt to patch the server. The two patches that are needed are below

5. During the vCenter installation process you might get a prompt asking to give the administrator’s account the right to Log On as a service on the server that run vCenter.  You need to grant the domain account you created earlier the right to Log On as a service.

The steps:

  • Get to the Administrative Tools, and then double-click Local Security Policy.
  • In the console tree, double-click Local Policies, and then click User Rights Assignment.
  • In the details pane, double-click Log on as a service.

  • Click Add User or Group, and then add the domain account you created to the list of accounts that possess the Log on as a service right.

6. Important - The SQL server native client is necessary to create the system DSN. To download the SQL Server Native Client, click on the link below

This ODBC Driver for SQL Server supports x86 and x64 connections to SQL Azure Database, SQL Server 2012, SQL Server 2008 R2, SQL Server 2008, and SQL Server 2005.

7. Now that the SQL Server Native Client is installed, create system DSN through ODBC data source administrator (64-bit).

Proceed through the wizard

8. Once you have fill out all the SQL server information, make sure you test the data source

If you everything is setup correctly then you should see this

9. Mount the vCenter server ISO and double click the autorun.exe

10. Proceed through the vCenter install

11. Once you get to the database settings, you will need to choose use an external database. If you DSN is blank then click the refresh button and it should appear

Continue the setup wizard and leave the default values… You should see the setup complete screen.  At this point you can open up a browser and visit the vCenter interface which uses adobe flash.


View Comments 0 Comments
Share Post   

Apply BgInfo via Group Policy Logon Script

Monday, September 28, 2015 - Posted by Keith A. Smith, in Microsoft

BgInfo is a well known tool that allows having a background Wallpaper showing some information about your system. This will save time when the need arises to collect details or troubleshoot your systems.
To centrally apply BgInfo I recommend the use of a Group Policy Logon script. 

1. Prepare the Background Wallpaper to apply via BgInfo:
You need to:
Copy the BgInfo.exe in a folder on \\yourdomain\netlogon
Run BgInfo.exe, prepare the fields to display and then save your template in a .bgi file

2.   2.  Prepare a Logon Script to run BgInfo:

You can use the following script to run BgInfo:

reg add HKU\.DEFAULT\Software\Sysinternals\BGInfo /v EulaAccepted /t REG_DWORD /d 1 /f

\\yourdomain\netlogon\Bginfo.exe \\yourdomain\netlogon\template.bgi /TIMER:00 /nolicprompt

The commands above can be saved in a .bat file in Netlogon folder 

3.   3. Apply BgInfo logon script using a Group Policy:

To apply BgInfo logon script using a Group Policy, proceed like the following:

  • Create a new GPO then go to User Configuration > Policies > Windows Settings > Scripts (Logon/Logoff) and then double-click on Logon

  • Select the BgInfo logon script you created and then click on OK

After that, you need to link your Group Policy to the OU containing the accounts on which it will be applied.

View Comments 0 Comments
Share Post   

Page  <1...1112131415...18>