[Kaseya Agent Procedure] – Run CHKDSK And Repair If Needed.

Free Kaseya Script – Run CHKDSK And Repair

Here is another free script from Cubert’s Dwelling, An Agent procedure that will run a CHKDSK in read only mode. Parse the output and run a chkdsk /F if it meets the criteria set forth in the script. It then emails an alert with the scan results to a email address provided before it uploads a copy of the scan to the get file for storage and review. Finally it updates 2 custom fields in the system info table with a brief result and the last run time. If it finds the disk healthy it will report as such if not it will report one of several error types.

Download Script Here

You will need to unzip the script and import it into Kaseya. Once imported edit the script and find the 2 places it email out and update the email address(es), Then you will need to add the 2 custom fields into your System-info table.

To add the custom fields:
1#  Open Kaseya and go to [Audit] – [View Individual Data] – [System Information] and select the button marked [New Custom Field]

2# The next box that pops up will create a new field, We will need to add 2 fields the first is CheckDisk Status and it will be a type String and Check Disk Updated with a type String.

Now run your disk check and see what it shows. If it meets with the right disk errors, a  repair is sent to the system and a email to you to reboot system when you can so the repair can complete. You can add another execute command under where we call the chkdsk /F with a shutdown -r -t 3 and that will cause the system to reboot its self after issuing the fix cmd. This is great for servers where your scheduling the disk scans during maintenance cycles but not so good with workstations where user gets booted up then a scan runs that then reboots the system will only inflame your users. So be mindful of how you use a shutdown cmd.

Enjoy

Cubert 🙂

[Solved]-Windows Easy Transfer Won’t Connect Between Systems Across The Network

How to get your Windows Easy Transfer to work over the Network.

This is a very common issue, I seem to hit the never ending “Trying to Connect” cycle of death on just about every other time I use Windows Easy Transfer. It doesn’t matter if your doing a transfer from XP to 7 or from 7 to 7, I’ve seen it time and time again.

I foung the Quick fix that works everytime I’ve used it.

The Guys over at LSP-Fix have a simple little program that fixes winsock issues.

LSP-Fix is a free Windows utility to repair a loss of Internet access associated with certain types of software. This type of software, known as a Layered Service Provider or LSP, typically handles low-level Internet-related tasks, and data is passed through a chain of these programs on its way to and from the Internet. However, due to bugs in the LSP software or deletion of the software, this chain can get broken, causing the Internet connection to become inaccessible or just a wee bit unstable. 

Download LSP-Fix here.

I know it doesn’t seem plausible that your winsock is messed up but take it from me, New Laptops out of the box can and will have issues. Download and run the tool and it will corrected the issues and your copy will start working.

LSP-Fix does not delete anything, it only fixes the order of the LSP’s. It does not require a reboot after you run the tool, just run the tool, select fix and then restart your Windows Easy Transfer process. I would suggest that you run it on both the sending and receiving systems, I find that they all seem to need  reording.

I hope this helps someon out there.

Cubert

How-to Create a SMTP Relay Connector for Microsoft Exchange Server 2010 using PowerShell

Create new connector and assign relay permissions.

Pretty simple really,

Open your exchange power shell and enter the following cmds to create and set permissions on your new connector. Use the New-ReceiveConnectorcmdlet to create the Receive connector Anonymous Relay that listens on local IP addresses.

New-ReceiveConnector -Name “Anonymous Relay” -Usage Custom -PermissionGroups AnonymousUsers -Bindings 192.168.1.5:25 -RemoteIpRanges 192.168.1.1-192.168.1.255

 

Now we must use the Exchange Shell to grant relay permission to anonymous connections on the new Receive connector.  The next cmd-let retrieves the specified Receive connector information and pipes the result to the Add-ADPermissioncmdlet to grant relay permission to anonymous connections on the new Receive connector.

Get-ReceiveConnector “Anonymous Relay” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

You can open up a telnet session to the IP of your exchange server and test the mail flow. This will confirm that your relay is up and running.

 

The first thing to do is to open a connection from your computer to your mail server.
telnet 192.168.1.5 25
You should receive a reply like:
Trying ???.???.???.???…
Connected to 192.168.1.5
Escape character is ‘^]’.
220 mail.domain.ext Microsoft Exchange Server XXX.YYY.xxx.yyy

You will then need to delcare where you are sending the email from:
HELO local.domain.name – dont worry too much about your local domain name.

This should give you:
250 192.168.1.5 Hello local.domain.name [Your IP address],

Now give your email address:
MAIL FROM:< mail@domain.com >

Should yeild:
250 2.1.0 mail@domain.com... Sender ok

Now give the recipients address:
RCPT TO:< mail@otherdomain.com >

Should yeild:
250 2.1.0 mail@otherdomain.com... Recipient ok

To start composing the message issue the command DATA

If you want a subject for your email type

Subject: type your subject here
You may now proceed to type the body of your message.

To tell the mail server that you have completed the message enter a single “.” on a line on it’s own.
The mail server should reply with: 250 2.0.0 ???????? Message accepted for delivery

You can close the connection by issuing the QUIT command.
The mailserver should reply with something like:

221 2.0.0 mail.domain.com closing connection Connection closed by foreign host.

Enjoy,

Cubert

[Solved]-Remote Web Workplace will not connect to my computer.

You have a user that has a  Home  (Windows 7 Home) or Work (Windows 7 Pro) Computer

When using remote web workplace they selects connect to my computer, picks their computer from the list and then it never makes it past this point. There is a error icon displayed in the lower progress bar area of the browser.

Running IE as a administrator they are able to use RWW just fine.

The user is an administrator on the computer. IE9 has been removed and replaced with IE8 same results.

Windows firewall is off,  We have tried with the firewall on and off, makes no difference.  We have added RWW site to the trusted site and relaxed all the active security settings for the trusted site, same result. The browser add-ons show the Microsoft rdp active control is installed when in IE both as an admin and just launching it normally so what could be hanging us up?

Well you will find that your UAC is on and one of the results of this being active is that Active X functions are suppressed. Just turn off UAC and the problem will go away.

Go to your start button and in the search window type “UAC”. It will launch the UAC Control and allow you to change the settings

Enjoy

Cubert.

[Solved] NTFRS – Journal Wrap Errors detected on Domain Controller

File Replication Service has detected that the replica set “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)” is in JRNL_WRAP_ERROR

Are you getting this error in your File Replication Service?

The File Replication Service has detected that the replica set “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)” is in JRNL_WRAP_ERROR.
Replica set name is : “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)”
Replica root path is : “c:\windows\sysvol\domain”
Replica root volume is :
\\.\C:
A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to read from the NTFS USN journal is not found. This can occur because of one of the following reasons.
[1] Volume “\\.\C:” has been formatted.
[2] The NTFS USN journal on volume “\\.\C:” has been deleted.
[3] The NTFS USN journal on volume “\\.\C:” has been truncated. Chkdsk can truncate the journal if it finds corrupt entries at the end of the journal.
[4] File Replication Service was not running on this computer for a long time.
[5] File Replication Service could not keep up with the rate of Disk IO activity on
\\.\C:.
Setting the “Enable Journal Wrap Automatic Restore” registry parameter to 1 will cause the following recovery steps to be taken to automatically recover from this error state.

This is caused when the Sysvol gets currupted and is simple to fix. I will walk you through the steps.

First off before we do anything lets backup by taking a Shadow Copy of the C: Drive. To do this we will open MyComputer and select the C:Drive, right click it and select properties. Now find the ShadowCopy Tab, highlight the C: Drive and click the “Create Now” button to create a backup point on the drive. You do not need to “Enable” ShadowCopy to take a 1 time snapshot.

Now that we have a backup point to go to if all hell breaks loose we can safely move on to the next step. Open up  REGEDIT and navigate to the RegKey -> System\CurrentControlSet\Services\NtFrs\Parameters and create a new REG_DWORD key called Enable Journal Wrap Automatic Restore and place a 1 as the hex value.

Now launch a Command window(DOS) and run the following commands:

NET STOP NTFRS

NET START NTFRS

This will then cause the following to appear in your File Replication Service Event Log:

The File Replication Service is deleting this computer from the replica set “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)” as an attempt to recover from the error state,
Error status = FrsErrorSuccess
At the next poll, which will occur in 5 minutes, this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.

This will be followed by the following Event Log:

File Replication Service is scanning the data in the system volume. Computer MyDomainServer cannot become a domain controller until this process is complete. The system volume will then be shared as SYSVOL.

This will be followed by the following Event Log:

 The File Replication Service moved the preexisting files in c:\windows\sysvol\domain to c:\windows\sysvol\domain\NtFrs_PreExisting___See_EventLog.

Now we need to wait a bit and allow the replication to complete. This has taken anywhere from 5 minutes to 20 minutes for me based on server and what is being replicated. You will know it is complete when you get the Event Log:

The File Replication Service is no longer preventing the computer MyDomainController from becoming a domain controller. The system volume has been successfully initialized and the Netlogon service has been notified that the system volume is now ready to be shared as SYSVOL.

Once you get this log your replication is complete and the Journal Wrap issues are fixed. We now need to go back to REGEDIT and change the entry we placed in there from a 1 to a 0.

You are all done.

May this help someone out there..

Cubert

Fix: Remove all snapshots Unable to access file since it is locked

Solved!

You are running ESX and have a VDR or 2 setup to do backups? Somewhere the VDR was rebooted or stopped working during backup and now has left snapshots on you VMs. You try to manually remove the snapshots and BAMB!

Error: Remove all snapshots  Unable to access file <unspecified filename> since it is  locked.

Here is how to fix it:

Shutdown your VDRs and then try to remove your snapshots. If they fail to remove then take another snapshot then try using the removing all “Delete All”  function. This is a safe process at this point, the delta files are not deleted until the successful merge of the delta and the flat file. This means if it fails you should still be no worse off than you are currently, no data was lost.

Now once all snaps are deleted, you may get a similar error trying to start your VDR. The VDR mounts the VM disks and does it’s backup . The mounts may still exist and this will cause the VDR issues booting.  Edit the settings in the VDR and look for Hard disks 2+ and remove them from the VM (Do NOT Delete Then!!! Just Remove them leaving HardDisk1) .

Once all but HardDisk1 has been removed from the VDR VM then reboot the VDR and you should be ready to start backing up again.

 

I hope this helps someone out there..

Cubert.

XYMON -> New BBWin Client GUI 1.1 Released.

Are you looking for a BBWin Client GUI to configure BBWin.cfg?

Can I see by raise of hand how many of you out there wishes for a good BBWin GUI so you don’t have to edit a that bloody XML file. I am having to flip between Wordpad, Task Manager and the Services console to place in the services and processes I want to monitor on my Windows hosts and that was such a pain.

So out comes BBWin-GUI!

Download file –> BBWin-GUI-1.1

 

BBWin is an open source client for Windows working with BigBrother or Xymon(Hobbit) monitoring software. We also have a custom VM appliance with XYmon and Cacti pre installed and ready to go. See MAG Server here on Squidworks for more information.

Our new BBWin GUI will read in your current BBWin.cfg file and then allow you to edit it. It provides all the services and processes running on your system and pulls all the unique event logs so  you may choose what to accept and what to ignore. Inside the new BBWin-GUI you will find your local disks and the ability to exclude disks as well as set the thresholds for warnings and panics.  Checkout some of the screen shots below.  Download and try BBWin GUI.

 

 

 

 

 


 

 

 

 


 

 

 

 


 

As always I hope this little app helps someone out there.

Enjoy

Cubert

Howto : Remove Windows Server 2008 / Windows 7 multiple default gateways with the first being 0.0.0.0

Windows has 2 default gateways set and the first is 0.0.0.0 which is causing network failures

You may have installed a new Windows 2008 server or Windows 7 workstation with a static IP address but networing outside your localnet fails. After you investigate you find by running “ipconfig” that there is 2 default routes listed. You see first 0.0.0.0 and then you see your real default router IP address below the 0.0.0.0 address.

This is preventing you from accessing the Internet as it believes the first route to the internet is your local IP address and it goes nowhere. You need to get the first route out but if you use “route delete” on the next reboot it will right back and you will be left without Internet access so what do you do?

You need to edit the registery and remove the entry listed in the default route key. To do this go to:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\your interface #\DefaultGateway

You will most likely find if you edit this key 2 IP addresses listed and the one you want being listed as the second IP in the list. Just remove all IP addresses but the real gateway address.

Close and reboot then try to ping out and it should now work.

Enjoy.

Cubert