Working at an MSP, I’ve been trying to script a lot of the repetitious tasks I have to do with Powershell. One of the smaller ones is hiding a local admin account on non domain computers.
Usually, I would have to navigate into the registry to HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon and create a new key, called SpecialAccounts, and then another new key called UserList and then add a new dword value with the name of the account. That’s a lot of work!
Today, I fired up Google and Powershell ISE and came up with this simple, simple script:
I’ve been doing a lot of research recently on secure methods of password sharing. Being in IT, I have to share many passwords each day and also have passwords shared with me by clients.
My favorite so far is ZeroBin. It is no-frills, open source (so anyone can vet it), and fairly simple. It requires no database and doesn’t store any information in a database. It is as simple as downloading the components, throwing it on a web server and going to the index page. That’s it. I did it on my server here and have been using it personally with no issues.
You can set messages / data to delete after a certain amount of time, like 5 or 10 minutes, or longer… 10 – 30 days.
How is this secure?
The text or data is encrypted & compressed inside the browser, then sent to the server already encrypted
The server has the encrypted data and that is all
The text is encrypted inside the browser. The encrypted data is sent to the server, while the encryption key does not get sent. Therefore even if a server was compromised, nothing could be done with the data
The encryption key is part of the URL and that is what unlocks the data
I’ve been using the beta build of Office 2016 and one of the nice new features that I’ve been getting use out of is the “Attach File” button. Before, you were prompted for a folder and file when clicking this button. In Outlook 2016, you are shown recent documents that you have saved. So if you work on Doc21.docx, save it, then go into Outlook and click ‘Attach File’… that file is the first one listed without needing to navigate around folders and finding your file! Nifty little feature. Screenshot below:
I recently wrote about some WordPress trouble a client had that was related to the database size. I listed some SQL commands that can be run, but there are simpler ways to keep a WordPress database clean and optimized to avoid trouble like that.
It’s good practice to install a plugin like WP-Optimize that can perform the same tasks without the need for nitty gritty SQL commands. Not only will your database not fill up, but keeping your database optimized will also make sure your website / blog loads as fast as possible.
WordPress also has a feature called “revisions” that can unnecessarily clog up the database. You can only turn that off by diving into some PHP files on the web server, which isn’t for the faint of heart. For more information on doing that, head over here.
I ran into this problem a day ago; all users on a WordPress blog couldn’t login. They wouldn’t receive an error when entering the correct password, but they also wouldn’t login. Attempts to reset passwords also failed, even using the trick to reset the admin password via theme.php.
Eventually I found that the database was full. The client, on Network Solutions, was allotted 300mb and they were at 301. Not to fear! I found that running the following SQL commands directly in the database manager would do the job:
DELETE FROM wp_posts WHERE post_type = “revision”;
OPTIMIZE TABLE wp_posts;
DELETE FROM wp_comments WHERE comment_approved = “spam”;
DELETE FROM wp_commentmeta WHERE meta_key
DELETE FROM wp_commentmeta WHERE comment_id
NOT IN (
But alas, I found myself in a Catch-22. To remove the data deleted above, you have to optimize each table. But to optimize each table, there had to be more free space in the database! Some users have had luck calling their web host, and having them somehow clear out the old entries. This client in particular ended up buying for $4 per month an extra 700mb in database space.
Post title inspiration goes to the graphic novel and cult classic:
There aren’t many guarantees out there in the IT world, but I’ve found that without fail, web designers will ALWAYS manage to screw up MX records when doing work in a web domain’s DNS settings.
Last week for instance, I was told a client was getting a new website. I immediately warned them about the track record many web designers have when doing things like this. The client immediately emailed the web designer, in Australia, about being careful. The reply was as follows:
[Client XYZ] email records won’t be altered as we’re only interested in the web hosting information
Suffice to say, less than five hours later I saw this when doing an MX lookup to see if this web designer was any different than the others: