Tuesday, May 15, 2018
XCOPY of Disk2VHD converted Windows system drive from MBR to GPT
I needed to convert my Windows system MBR disk into a GPT disk.
First step was to use Disk2VHD utility, to capture the disk in original state. Saved VHD file on a USB drive. Used the Windows Server installation disk (Server 2008 R2 - I will be attempting on a Server 2012 R2 later today) to convert the MBR disk to GPT
Then, after converting the disk into a GPT format, I mounted the VHD using diskpart and ran the Xcopy command to copy the Windows system files back to the newly formated GPT disk. (Used XCOPY h:\ c:\ /h /c /k /o /e /r /y /exclude:c:\excludeme.txt
Obviously, I didn't want to copy the pagefile.sys over to the new disk, so I wanted to use the /EXCLUDE switch to ignore this file. When I did used /exclude:c:\pagefile.sys, it just hung!!
The main thing I realized in using the /EXCLUDE flag is that you have to put the location of the excluded file list after the flag; not the actual excluded items/terms. Once I realize this, the command ran successfully.
Thursday, May 10, 2018
Dell iDRAC6 tweaks
Currently, my iDRAC 6 has a self-signed SSL certificate, so I must use Internet Explorer 11 or Google Chrome, which will allow me to get to the management page.
1. A series of "undefined" was all over the page. Solution: add the iDRAC IP address to the "Compatibility View settings" of IE 11.
2. Keyboard would not work in the Virtual Console. Solution: add the iDRAC IP address to the "Trusted Zones" of IE 11.
3. To mount Virtual Media, go to the iDRAC main console. Select "Console/Media". Once on the "Console/Media" tab, select Configuration (as seen below).
Scroll down to Media section and change the "Status" from 'Detached' to 'Auto Attach'. Apply saved settings.
Then when you open the "Virtual Media" dropdown of Virtual Console, you can attach an ISO/img file to mount and check the "Mapped" checkbox. Upon reboot of the Dell Server and hit F11, the BIOS Boot Manager will show Virtual Floppy and Virtual CD to boot from.
Tuesday, January 30, 2018
Enabling Remote Desktop from command line
Found this gem from John Savill's website
(Get-WmiObject Win32_TerminalServiceSetting -Namespace root\cimv2\TerminalServices).SetAllowTsConnections(1,1) | Out-Null
(Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\TerminalServices -Filter "TerminalName='RDP-tcp'").SetUserAuthenticationRequired(0) | Out-Null
Get-NetFirewallRule -DisplayName "Remote Desktop*" | Set-NetFirewallRule -enabled true
(Get-WmiObject Win32_TerminalServiceSetting -Namespace root\cimv2\TerminalServices).SetAllowTsConnections(1,1) | Out-Null
(Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\TerminalServices -Filter "TerminalName='RDP-tcp'").SetUserAuthenticationRequired(0) | Out-Null
Get-NetFirewallRule -DisplayName "Remote Desktop*" | Set-NetFirewallRule -enabled true
Friday, November 24, 2017
Windows 10 Start Menu, Cortana, Not Working for Domain Users, But OK for Local Users
I looked at several of the posts out there about the issue where Windows 10 system Start Menu, Cortana, etc works fine with a local account, but when added to the domain, Start Menu hangs and Cortana/Windows Search does not work.
I tried copying the file(folder) ‘C:\Users\Administrator\AppData\Local\Packages\windows.immersivecontrolpanel_cw5n1h2txyewy’ to C:\Users\
Didn't work. Plus, the folder was the same size as what I copied. Thought it may have been corrupted, but no change.
Went to the event log (should have went there first) and noticed all these errors from source:ESENT dealing with logging/recovery. Error details was:
WebCacheLocal database recovery restore failed with unexpected error - 1907
Looked this up and found that deleting (actually renamed) the C:\Users\Administrator\AppData\Local\Microsoft\Windows\WebCache\WebCacheV01.dat. Now the start menu and Cortana works properly. Wierd, but resolved. Thanks to Cannot open up Microsoft Edge or Internet Explorer in newly created profiles
Tuesday, November 7, 2017
WinRM Error number: -2144108526 0x80338012
I have two Windows 2012 servers in a Windows Failover cluster. I was trying to look at the shares under the Fileserver role. It kept spinning and returned error: “There were errors retrieving the file shares.” One of the troubleshooting steps is to check WinRM.
When running the command: winrm id -r:myserver
I received the standard error:
Message = The client cannot connect to the destination specified in the request. Verify 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, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig". Error number: -2144108526 0x80338012
On my workstations, winrm is working correctly, so I was unsure where the problem was.
When I run winrm enumerate winrm/config/listener I got this weird:
Listener [Source="GPO"]
Address = *
Transport = HTTP
Port = 5985
Hostname
Enabled = true
URLPrefix = wsman
CertificateThumbprint
ListeningOn = null
Listener [Source="Compatibility"]
Address = *
Transport = HTTP
Port = 80
Hostname
Enabled = true
URLPrefix = wsman
CertificateThumbprint
ListeningOn = null
Listener [Source="Compatibility"]
Address = *
Transport = HTTPS
Port = 443
Hostname = server.network.home
Enabled = true
URLPrefix = wsman
CertificateThumbprint = d1 ef b5 c3 64 48 c1 24 9b 3f h8 24 bb 68 8f 0354 27 64 df
ListeningOn = null
The "ListeningOn = null" was strange. I have WinRM configured using group policy. After some research, discovered article Unable to Use Server Manager Remotely to help me realize that my group policy IPv4 filter was not set. The article suggested that I create a new instance of the HTTP Listener for all IPs using (winrm create winrm/config/Listener?Address=*+Transport=HTTP ) . But I have that configured in GPO. I double checked between the two GPOs that I have for clients and servers, and discovered that I did not set an IPv4 filter for servers.
Once I entered it, ran gpupdate on servers and restared WinRM Service, all was good again.
When running the command: winrm id -r:myserver
I received the standard error:
Message = The client cannot connect to the destination specified in the request. Verify 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, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig". Error number: -2144108526 0x80338012
On my workstations, winrm is working correctly, so I was unsure where the problem was.
When I run winrm enumerate winrm/config/listener I got this weird:
Listener [Source="GPO"]
Address = *
Transport = HTTP
Port = 5985
Hostname
Enabled = true
URLPrefix = wsman
CertificateThumbprint
ListeningOn = null
Listener [Source="Compatibility"]
Address = *
Transport = HTTP
Port = 80
Hostname
Enabled = true
URLPrefix = wsman
CertificateThumbprint
ListeningOn = null
Listener [Source="Compatibility"]
Address = *
Transport = HTTPS
Port = 443
Hostname = server.network.home
Enabled = true
URLPrefix = wsman
CertificateThumbprint = d1 ef b5 c3 64 48 c1 24 9b 3f h8 24 bb 68 8f 0354 27 64 df
ListeningOn = null
The "ListeningOn = null" was strange. I have WinRM configured using group policy. After some research, discovered article Unable to Use Server Manager Remotely to help me realize that my group policy IPv4 filter was not set. The article suggested that I create a new instance of the HTTP Listener for all IPs using (winrm create winrm/config/Listener?Address=*+Transport=HTTP ) . But I have that configured in GPO. I double checked between the two GPOs that I have for clients and servers, and discovered that I did not set an IPv4 filter for servers.
Once I entered it, ran gpupdate on servers and restared WinRM Service, all was good again.
Thursday, October 26, 2017
Best Practices for Setting Folder Permissions
I thought this was a really good post on permission/ACL design on Windows file servers.
Following repost is from reference: https://social.technet.microsoft.com/Forums/ie/en-US/c6242159-d15d-417e-91f8-eb19c0da3a35/best-practices-for-basic-ntfs-permissions-on-a-share?forum=winserverfiles
Suggested Reading
Axioms of Permissions Administration
http://networkadminkb.com/Shared%20Documents/Axioms%20of%20Permissions%20Administration.aspx
The Golden Rules of Permissions Administration
http://networkadminkb.com/Shared%20Documents/The%20Golden%20Rules%20of%20Permissions%20Administration.aspx
Differences between Authenticated Users, Domain Users, and Everyone groups
http://networkadminkb.com/kb/Knowledge%20Base/ActiveDirectory/Differences%20between%20Authenticated%20Users,%20Domain%20Users,%20and%20Everyone%20groups.aspx
Recommended NTFS Permissions for New Drives
http://networkadminkb.com/kb/Knowledge%20Base/Windows2003/Recommended%20NTFS%20Permissions%20for%20New%20Drives.aspx
Creator Owner Explained
http://networkadminkb.com/kb/Knowledge%20Base/ActiveDirectory/Creator%20Owner%20Explained.aspx
Doing security is about creating an developing a philosophy, there are many out there. The one below is mine and works for most situations, this is just a simplified explanation of the Axioms and Golden Rules listed above.
For shares you should do the following
1) Everyone - Read (optional not really needed but a nice just in case)
2) Authenticated Users - Change
3) Local Administators - Full Control
4) File Strucutre Administrators - Full Control
For Shares note the following:
Alway limit Authenticated Users to Change at the Share to pervent non-admin users from accidently being given Full Control to the file structure.
You should always configure Local Adminsitrators Full Control at the Share so they can administrate it remotely
You should always create and use a Files Strucutre Adminsitrators groups and assign them full control to every share. This allows them to remotely administrater shares without being local administartors.
For your high level directories NTFS Permsisions where no files reside and only read access to folders is needed to get to the data in lower directories.
1) Authenticated Users - Read
2) Local Administators - Full Control
3) File Strucutre Administrators - Full Control
4) SYSTEM - Full Control
For NTFS in this situation note:
Alway limited Authenticated Users to Read to pervent non-admin users chaning folders and creating files here.
You should always configure Local Adminsitrators Full Control at the folder so they can administrate it remotely
You should always create and use a Files Strucutre Adminsitrators groups and assign them full control to every folder. This allows them to remotely administrater shares without being local administartors.
For NTFS permissions where users need to write data, stop inheritance, copy permissions and replace Authenticated users to two different groups
1) Directory group - Read Only
2) Directory group - Read and Write
3) Local Administators - Full Control
4) File Strucutre Administrators - Full Control
5) SYSTEM - Full Control
For NTFS in this situation note:
Alway remove Authenticated Users so the appropriate group limite access
You should always configure Local Adminsitrators Full Control at the folder so they can administrate it remotely
You should always create and use a Files Strucutre Adminsitrators groups and assign them full control to every folder. This allows them to remotely administrater shares without being local administartors.
http://social.technet.microsoft.com/Forums/en-US/winserverfiles/thread/68748d3a-575f-4ffa-bd98-c6b7fcb3a901
Following repost is from reference: https://social.technet.microsoft.com/Forums/ie/en-US/c6242159-d15d-417e-91f8-eb19c0da3a35/best-practices-for-basic-ntfs-permissions-on-a-share?forum=winserverfiles
Suggested Reading
Axioms of Permissions Administration
http://networkadminkb.com/Shared%20Documents/Axioms%20of%20Permissions%20Administration.aspx
The Golden Rules of Permissions Administration
http://networkadminkb.com/Shared%20Documents/The%20Golden%20Rules%20of%20Permissions%20Administration.aspx
Differences between Authenticated Users, Domain Users, and Everyone groups
http://networkadminkb.com/kb/Knowledge%20Base/ActiveDirectory/Differences%20between%20Authenticated%20Users,%20Domain%20Users,%20and%20Everyone%20groups.aspx
Recommended NTFS Permissions for New Drives
http://networkadminkb.com/kb/Knowledge%20Base/Windows2003/Recommended%20NTFS%20Permissions%20for%20New%20Drives.aspx
Creator Owner Explained
http://networkadminkb.com/kb/Knowledge%20Base/ActiveDirectory/Creator%20Owner%20Explained.aspx
Doing security is about creating an developing a philosophy, there are many out there. The one below is mine and works for most situations, this is just a simplified explanation of the Axioms and Golden Rules listed above.
For shares you should do the following
1) Everyone - Read (optional not really needed but a nice just in case)
2) Authenticated Users - Change
3) Local Administators - Full Control
4) File Strucutre Administrators - Full Control
For Shares note the following:
Alway limit Authenticated Users to Change at the Share to pervent non-admin users from accidently being given Full Control to the file structure.
You should always configure Local Adminsitrators Full Control at the Share so they can administrate it remotely
You should always create and use a Files Strucutre Adminsitrators groups and assign them full control to every share. This allows them to remotely administrater shares without being local administartors.
For your high level directories NTFS Permsisions where no files reside and only read access to folders is needed to get to the data in lower directories.
1) Authenticated Users - Read
2) Local Administators - Full Control
3) File Strucutre Administrators - Full Control
4) SYSTEM - Full Control
For NTFS in this situation note:
Alway limited Authenticated Users to Read to pervent non-admin users chaning folders and creating files here.
You should always configure Local Adminsitrators Full Control at the folder so they can administrate it remotely
You should always create and use a Files Strucutre Adminsitrators groups and assign them full control to every folder. This allows them to remotely administrater shares without being local administartors.
For NTFS permissions where users need to write data, stop inheritance, copy permissions and replace Authenticated users to two different groups
1) Directory group - Read Only
2) Directory group - Read and Write
3) Local Administators - Full Control
4) File Strucutre Administrators - Full Control
5) SYSTEM - Full Control
For NTFS in this situation note:
Alway remove Authenticated Users so the appropriate group limite access
You should always configure Local Adminsitrators Full Control at the folder so they can administrate it remotely
You should always create and use a Files Strucutre Adminsitrators groups and assign them full control to every folder. This allows them to remotely administrater shares without being local administartors.
http://social.technet.microsoft.com/Forums/en-US/winserverfiles/thread/68748d3a-575f-4ffa-bd98-c6b7fcb3a901
Thursday, August 31, 2017
Powershell Redirection of output
Was needing to send error output from a command to the logfile.
Ran across these two articles that helped me.
Powershell Move-Item logging
You may just need to collapse the output file descriptors. According to the about_Redirection page, it should work if you do the following:
Ran across these two articles that helped me.
Powershell Move-Item logging
You may just need to collapse the output file descriptors. According to the about_Redirection page, it should work if you do the following:
Move-Item c:\temp\*.* C:\Temp\2014 -Verbose -Force *>&1 |
Out-File -FilePath $MyLogPath
Or if you want to see the output at the same timeMove-Item c:\temp\*.* C:\Temp\2014 -Verbose -Force *>&1 |
Tee-File -FilePath $MyLogPath
Subscribe to:
Posts (Atom)