If you intend on sharing your printer from a 32-bit server to 64-bit clients, you will need to ensure both 32 and 64-bit drivers are installed at the server. The issue however is that the server will not allow you to install 64-bit drivers.  There is a really quick and simple solution.

1) Download the 32 and 64-bit Universal Printer Drivers from the manufacturer's site. DO NOT try and fiddle around with anything else.

2) Log into an as a domain administrator on a 64-bit PC or Server located in the same domain

3) From the command prompt run "printmanagement.msc" 

---- Right Click "Print Servers" -> "Add/Remove Servers"
---- Enter the hostname of your server and click "Add to List"
---- Click "Apply" and "OK"

---- Expand the server you entered and load the "Drivers" child object
---- Right click the centre pane and  choose "Add Driver"
---- Choose "x64" and "x86"
---- Complete the driver installation by assisting the installer to the INF files located in your 32 and 64-bit driver downloads you already completed
---- If you successfully installed the drivers, you should see both 32 and 64-bit listed under the drivers pane

4)  It's now time to install and share the printer!

Browse to "Printer Management Console" ->  "Printer Servers" -> "Server Name" -> "Printers"  -> right click "Add Printer"

 Complete the printer installation and select the drivers you installed when it asks.

5) Check the driver options 

Select the printer you installed -> right click "properties" -> "Sharing" -> "Additional Drivers"

You should see both x64 and x86 drivers checked off; you're ready to roll!

If you do not see both checked off:

Select the printer you installed -> right click "properties" -> "advanced tab"
Choose the correct driver from the drop down list under "Driver: " and recheck the additional drivers options to verify.

I have run into this many times; it’s unpleasant and completely unnecessary! I’m going to show you how to use a powerful tool built into Windows 7 to control the audio volume available to specific applications.

Let’s get started:

1.  Click on the “Volume” icon in the system tray (bottom right corner near the clock):

1. Click “mixer”:

You will be provided a list of each application currently accessing your sound system.

1. Adjust the volume (1)  or completely mute (2) it for the specific application causing the issue. In this case, the annoying ad came while I was browsing the internet using Mozilla Firefox. This would indicate we need to mute or reduce the volume on Mozilla Firefox.

Quick and easy, and you will no longer have to suffer through ads or annoying audio while listening to your music!

I would also like to make sure you are aware that if you mute or reduce the volume for an application like Mozilla Firefox, it will affect everything in Mozilla Firefox. If you visit youtube and require audio for another feature in Mozilla Firefox, you will need to adjust this volume when the time comes.

SiteA
Fortinet A

--- WAN1: 55.55.55.20
--- Int1: 10.20.1.1
--- Port 36008 should be forwarded to 10.10.1.17 in Site B

SiteB
Fortinet B

--- WAN1: 66.66.66.60
--- Int1: 10.10.1.1
--- Server on 10.10.1.17 with port 36008 open and ready

IPSEC Interface Name: IPSEC-YKN1-SPG1

The idea ... when anyone on the internet connects to 55.55.55.20 on port 36008, they will be redirected up through the IPSEC tunnel and to the remote server.  Let's get started!

1) FortinetA - Create a port-forwarding rule just like any other

2) Fortinet A - Create a firewall policy to allow the internet traffic in on WAN1 and out the IPSEC Interface to your port forwarding rule (remote server)

Do not forget to enable NAT!!!

3) Fortinet B - Create a reverse route to manage the WAN1 interace on Fortinet A

Without this, the fortinet will drop the incoming packets when it does a reverse path check.

"id=36871 trace_id=188 func=ip_route_input_slow line=1268 msg="reverse path check fail, drop"

I recommend you set the distance to 1 so that it takes priority, you should decide depending on your other routes.

Instead of using the /24, you could use the gateway the WAN1 port of the Fortinet A is using. For this demonstration to help keep your sanity, we've left it at the full subnet.

4) Test it out! 

The best method to test this is to telnet to port 36008 from an EXTERNAL location to 55.55.55.20.
You can do this with any operating system.

Telnet 55.55.55.20 36008

If it connects to your service, you're good to go!

If you're having issues, I suggest changing the forwarding port to a port that you know is open on the server. Try using telnet from the inside of your network to verify the port is open, and then test externally.

Common server ports are 21, 22, 80, 110, 143, 3389

Check which ports are open on your server, head back to Step 1) and use this port instead.
Once you have it routing through to that port correctly, change it to the actual port you need.

1) Create a network share

This share must reside on a server or PC accessible to you virtual machine, and the user you will be used to connect to it must have full/read.

2) Log onto your existing virtual machine

Verify you can access this network share by IP or hostname (ie. \\computername\sharefolder). Do not proceed further until you can see and write to this folder from 1). 

3) Install the Windows Server Backup tools 

Load the Server Manager > Features > Add Features > Windows Server Backup Features (everything) > install 

4) Load the Windows Server Backup tools

Load the Administrator Tools -> Windows Server Backup 

5) Create a backup and dump your image to the network share you created 

Windows Server Backup > Backup Once > Full Server (recommended) > Remote Shared Folder > \\computername\sharefolder > Inherit 

You will be prompted for credentials.
MAKE SURE you use credentials that have full read/write access to the folder your shared!

START the backup! 

6) While the backup is running, create an empty VM on the new vSphere host

Load up your vSphere client ->CTRL-N

Configuration: Typical
Name:  You tell me!
Storage:  Choose the location for the new VM
Guest OS: Windows 2008 R2 64bit

Network:  Pick 1 network card, the correct network, and E1000 with Power On. DO NOT CHOOSE ANOTHER TYPE OF NETWORK CARD!
Windows 2008 R2 will recognize the e1000 with it's native drivers. You can change the network settings later.

Disk Provisioning: The size of your virtual disk size should be AT LEAST the size of the old VM virtual disk size.
I should note that you can also use this opportunity to INCREASE the size of your partitions. If your old VM is running out of space, crank it up here and Windows will increase the size of your partitions on restore.

Finish: Choose to "edit the virtual machine settings before completion" and click continue.

7) Verify your VM settings 

Make sure the RAM, CPU and other settings are verified for your old VM. This would be an excellent time to beef it up if you need to.

8) Configure the CD/DVD to mount and boot off of a Windows 2008/2008R2 Server image

Click the "New CD/DVD (adding)" devices -> side window -> Datastore ISO File or Host Device or Client Device > Find the ISO or DVD for windows server 2008 / 2008R2
Enable the "Connect at power on" option at the top.

Finish.

9) Check the status of the running backup from earlier. Do not proceed until the backup is completed and successful. 

Once the backup is complete, power down the old VM. If you turn it back on, you run the risk of IP address, DNS and hostname conflicts.

10) Start the new Virtual Machine and start the Windows 2008 installation process

Choose your default language, time, keyboard -> next
Choose "Repair your computer" (bottom left)
Choose "restore your computer using a system image that you created earlier" > next
Choose "cancel" when it reports "Windows cannot find a system image on this computer"
Choose "select a system image" > next
Choose "advanced" > "Search for a system image on the network" > "yes"

You will now be provided a field to enter the network path to the backup share we created earlier. Make sure to type it in exactly as your testing value.

\\computername\sharefolder

Click OK (it will now attempt to access that folder)
Enter the login credentials for the share you created.

If everything you entered and shared is correctly setup, you will be provided a populated table with the backup completed earlier.

Choose Next, Next

11) If you wish to increase the size of the partitions from the old VM, this is your chance.

12) Finish it up and get the restore started

This process could take minutes to hours depending on the size of your old VM.

13) Finish the new VM configuration and take it live

At this point, the snapshot of your previous VM is now live on the new VM.
The last steps include:

- Install the VMware tools using the built-in tools
- Adjust any network settings , network card types (i prefer the VMXNET3 drivers myself)
- Double check all services and applications are live after you reboot (vmware tools and network changes should be followed by a reboot)

http://www.pendrivelinux.com/boot-iso-from-usb-flash-drive

This tool lets you burn a standard ISO to a USB.
Lets you also have multiple ISOs on the key to choose for the boot sequence.

Delicious!

Sadly, there are only 2 resolutions and neither of them are global.

1) When you see the “FROM” field appear while forwarding a contact, manually click "From" -> "other e-mail address" -> and choose your name from the list.
This will change the “from” address to your correct address, hit send, and life is good.

2) You can manually create new contacts and copy the information from the old to the new.
DO NOT right click and copy a contact, you need to make a new contact and copy each field over individually.
If you copy a contact, it will transfer the x400 metadata.
I strongly feel this is a bug and Microsoft should look at removing the reference to the old address.

1) To show your list of users and their settings
dsquery user "ou=someOU,dc=yourdomain,dc=ca" -limit 0 | dsget user -email -pwdneverexpires

2) To update all users to yes or no
dsquery user "ou=someOU,dc=yourdomain,dc=ca" -limit 0 | dsmod user -pwdneverexpires yes

Here's the scenario: Exchange 2010. You are looking to move all mailboxes out of a particular database. After moving all the mailboxes you request exchange to remove the database through the EMC or shell, when suddenly:

This mailbox database contains one or more mailboxes, mailbox plans, archive mailboxes, or arbitration mailboxes. To get a list of all mailboxes in this database, run the command Get-Mailbox -Database <Database ID>. To get a list of all mailbox plans in this database, run the command Get-MailboxPlan. To get a list of archive mailboxes in this database, run the command Get-Mailbox -Database <Database ID> -Archive. To get a list of all arbitration mailboxes in this database, run the command Get-Mailbox -Database <Database ID> -Arbitration. To disable a non-arbitration mailbox so that you can delete the mailbox database, run the command Disable-Mailbox <Mailbox ID>. To disable an archive mailbox so you can delete the mailbox database, run the command Disable-Mailbox <Mailbox ID> -Archive. Arbitration mailboxes should be moved to another server; to do this, run the command New-MoveRequest <parameters>. If this is the last server in the organization, run the command Disable-Mailbox <Mailbox ID> -Arbitration -DisableLastArbitrationMailboxAllowed to disable the arbitration mailbox. Mailbox plans should be moved to another server; to do this, run the command Set-MailboxPlan <MailboxPlan ID> -Database <Database ID>.

As you are a brilliant IT wizard, you immediately remember to check if you moved all the archive and arbitration mailboxes.

[PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>Get-Mailbox -Database "Staff & Testing Mailboxes" -Archive
[PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>Get-Mailbox -Database "Staff & Testing Mailboxes" -Arbitration
[PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>Get-Mailbox -Database "Staff & Testing Mailboxes"

No results are returned ... why does exchange think there are mailboxes left inside?
Good question!

When the database removal request begins a validation process is completed to ensure no user mailbox attributes are linked to the database. In very rare instances, you may find a particular attribute has failed to update or be reset and thus ... it fails. In our particular case, an existing mailbox had the "online-archive" feature removed and during the process, the "msExchArchiveDatabaseLink:" attribute was still referencing this old database. So how did we find it?

Easy!

1) Load the command prompt and run "dsquery * domainroot -attr * -limit 0 > results.txt"

This will dump the attributes for every object in AD to a text file you can search through.

2) Open the text file with notepad and search for a unique string from your database name. In our case, "Testing" worked out great from "Staff & Testing mailboxes"

3) We found the single attribute that was causing the removal process to think there were still active mailboxes in the database.

msExchArchiveDatabaseLink: CN=Staff & Testing Mailboxes,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=XXXXXXX,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=XXXXXXX,DC=XXX

If you look directly above this row, you will find a few values that will help you identify the user account in question that has this attribute set.
In our case, we found these records a few lines above:

sAMAccountName: jon
userPrincipalName: jon@doe.com
mail: jon@doe.com

Now we know which user has a reference to the old database, and which attribute.

4) Load ADSIEDIT.MSC and browse to the user object under the default naming context. Right click the object, properties, scroll down until you find "msexcharchivedatabaselink" and clear it. After you save it should be "<not set>".

If you're not familiar with ADSIEDIT, open it, choose the default naming context and you will be provided with a list of objects similar to your active directory users/computers. When you find the user that had the bad link, right click their object and select properties. Within is a fantastic list of all sorts of attributes ... including the one you need to change (msexcharchivedatabaselink).

BE CAREFUL USING ADSIEDIT ... you can do SERIOUS damage. You've been warned!

After you reset this value, try removing the database again and you should find success. If not, run the dsquery again and look for other objects referencing the old database.

Some other things to mention ... although likely not necessary ... during the process, I also:

- Deleted the System Mailbox record for this database using the DSQUERY Results and ADSIEDIT ... not sure if this was another contributing factor to the success.

- With SP1, mailboxes are moved and the existing copy is left in the old database as a disconnected "SoftDeleted" status. I manually removed these as well, not sure it this was another contributor factor to the success.

If you want to remove all disconnected mailboxes from a database, run the following command

Get-MailboxStatistics –Database “dbname” | Where-Object {$_.DisconnectReason –eq “Disabled”} | ForEach {Remove-StoreMailbox –Database $_.database –identity $_.mailboxguid –MailboxState Disabled }

If you want to remove all soft-deleted mailboxes from a database, run the following command

Get-MailboxStatistics –Database “dbname” | Where-Object {$_.DisconnectReason –eq “Softdeleted”} | ForEach {Remove-StoreMailbox –Database $_.database –identity $_.mailboxguid –MailboxState Softdeleted }

Thanks to: http://www.howexchangeworks.com/2010/09/purge-disconnected-or-soft-deleted.html
For the softdelete info!

-------------------

Social engineering is the art of manipulating people into performing actions or divulging confidential information, rather than by breaking in or using technical cracking techniques. While similar to a confidence trick or simple fraud, the term typically applies to trickery or deception for the purpose of information gathering, fraud, or computer system access; in most cases the attacker never comes face-to-face with the victim. In the United Kingdom, social engineering using impersonation (e.g. to gain information over the phone) is known informally as blagging. In addition to criminal purposes, social engineering has also been employed by debt collectors, private investigators, bounty hunters and tabloid journalists.

A study by Google researchers analyzing fake AV distribution found that up to 90% of all domains involved in distributing fake antivirus software used social engineering techniques.

Sourced from: Wikipedia.org.

-------------------

In our industry, the most dangerous and commonly used method of Social Engineering is the “Fake Helpdesk”, or more accurately described as “tricking employees into thinking the person on the phone is a legitimate helpdesk technician from the IT department.”. It’s VERY common to find employees doing exactly what the fake support technician requests without any inquiry as to the reason for the support work, or a request for identification.

Even with all the right infrastructure in place including firewalls, intrusion prevention packages, real-time monitoring solutions, and strict password policies, a simple phone call from a patient and polite hacker can penetrate your entire network in minutes. We’ve seen it, this should be taken very seriously.

How to protect yourself

1)      Ask for identification (name, company, phone number and website).

2)      If you receive a call or email from anyone requesting you complete a task or provide information and you do not recognize the caller, start asking questions.

3)      If you receive a call or email, NEVER give out your information.

4)      If you receive a call or email, NEVER accept technical support unless you are 100% confident the person is someone you’ve dealt with before. If you haven’t, see 3).

5)      If you receive a call, the caller should have no objection letting you call them back at their head-office after you find the number yourself (use their website).

6)      Verify the user calling is from a company you normally deal with.

7)      If something doesn’t feel right, call your manager.

8)      Call your IT Department to verify the legitimacy of the call.

Educate Your Team

Ensure your staff are aware of the threat and educate them. Make sure they possess the knowledge to ask the right questions and contact the right people if something doesn’t add up.

Test You Staff

Be pro-active and attempt a “Social Engineering” hack at your locations. How difficult it is to acquire information from your staff? More training may be required. Take the time to educate your team, this threat is real and you need to take precautions.

Did you know?

1)      Caller ID can be faked (or in fancy terms, SPOOFED)? Although it might say “Royal Bank” or “SIRKit Ltd”, this can easily be manipulated.

2)      Banks and Government agencies will never call you and ask for your personal information. You will always have to call them.

3)      Banks and Government agencies will never e-mail you a request for information. You will always have to call them, or use their website.

4)      Legitimate organizations will never e-mail you with a link to change your password or provide login details.

5)      E-mail is rarely encrypted. Never send sensitive information via email. EVER.

6)      You will never be notified by e-mail that you’ve won anything of significance. It’s pretty much guaranteed to be fake.

7)      E-mail addresses can be faked. Although your e-mail application says billgates@microsoft.com or kris@sirkit.ca, it’s not guaranteed that the e-mails originated from these addresses.

8)      When you click on a link in an e-mail, verify the web address AFTER the page loads. Always look at the name right before the .com, .net, .org or .ca. This is the TRUE domain.
Hopefully this gives you a bit of insight into the threat.
If you have any questions at all, please do not hesitate to contact us.

We recently applied an upgrade from Worry Free Business Security 6.0 SP3 to 7.0. After the upgrade we noticed whitelisted Ephemeral and other port ranges in the firewall policies were not allowing traffic in. After numerous hours verifying everything was correctly setup we got in touch with Trend Micro and they sent back a patch to resolve the issue. We haven't seen this online yet, so I figure this may help a few of you.

--------------------------------------------------------------------------------

Good Day.

Please apply the attached Hotfix to the WFBS Server. Unzip password: novirus
Let the agents update afterwards then observe if the issue persists.

We are looking forward to your reply.

Technical Support – Worry-Free Products and Services Trend Micro, Inc. “Securing Your Journey to the Cloud”

--------------------------------------------------------------------------------

Download: http://www.sirk.ca/downloads/WFBS_70_WIN_All_HFB1461.zip

After applying this patch and allowing the update to propagate down to the clients, the port ranges started allowing traffic through.