Archive

Posts Tagged ‘MS Windows’

Error “WindowsUpdate_80244019” or “WindowsUpdate_dt000” during update your Windows.

The problem in majority of the cases is related to the wrong DNS loading. The problem itself very often happens when you are behind several routers (like one from internet connection vendor and one your WiFi router) and until you don’t flush your current DNS configuration you can try anything but you won’t be successful.
What’s really funny that’s so easy – just run the command prompt with admin rights, then run the following command:

ipconfig /flushdns

make a coffee and get back to the WU heaven 🙂
All other applications are able to deal with that – WU not. From my point of view this is a bug and I am just surprised it’s nowhere documented.

You could also register the DNS in command prompt with:

ipconfig /registerdns

and check your current DNS settings with:

ipconfig /displaydns

Hope this helps!

Advertisements

Solving ORA-01031: insufficient privileges while connecting as sqlplus / as sysdba.

Many times we can see an issue like this:
screen1
This is a very common and frequent error that can occur after the new oracle software install or due to some permissions changes at OS level. I will discuss the approach to solve ORA-1031 error on both Windows and Linux environment but first a little theory.
An administrative account is a user that is granted SYSOPER or SYSDBA privileges. Oracle DBAs and operators typically use administrative accounts to manage the database and database instance. SYSDBA and SYSOPER allow access to a database instance even if it is not running. Control of these privileges is managed outside of the database via password files and special operating system groups (dba on Unix/Linux and ORA_DBA on Windows). External password files are created with the orapwd utility.
If an administrative users belongs to the ‘dba’ group on Linux or the ‘ORA_DBA’ group on Windows, he/she can connect like this:

sqlplus / as sysdba

No password is required. This is equivalent to the unsupported “connect internal” method.
A password is required for “non-secure” administrative access. These passwords are stored in password files. Remote connections via Net8 are classified as non-secure. Look at this example:

sqlplus sys/password as sysdba

The Oracle password file ($ORACLE_HOME/dbs/orapw$ORACLE_SID or $ORACLE_HOME/database/orapw$ORACLE_SID) stores passwords for users with administrative privileges. One needs to create a password files before remote administrators will be allowed to connect.
Follow this procedure to create a new password file:
– Log in as the Oracle software owner
– Run command: orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=mypasswd
– Shutdown the database (SHUTDOWN IMMEDIATE)
– Edit the INIT.ORA file and ensure REMOTE_LOGIN_PASSWORDFILE=exclusive is set
– Startup the database (STARTUP)
Keep in mind that the orapwd utility presents a security risk in that it receives a password from the command line. This password is visible in the process table (at least as long as orapwd is running) and in the shell’s history file of many systems.
Last but not least, avoid at all cost the OPS$ accounts and setting the REMOTE_OS_AUTHENT initialization parameter (deprecated in Oracle 11g) which could be a security risk in a client/server environment.

Now, let’s go back to the ORA-01031 error – how to solve it in Windows environment?
First of all, be sure that your OS user belongs to the ORA_DBA group.
screen2
Then, set the SQLNET.AUTHENTICATION_SERVICES parameter to NTS in the sqlnet.ora file (located in the $ORACLE_HOME/network/admin):

SQLNET.AUTHENTICATION_SERVICES=(NTS)

which allows Windows users to be authenticated using Windows NT native security.
With your user account added to the ORA_DBA group and the SQLNET.AUTHENTICATION_SERVICES parameter being set to NTS, you should have sufficient privileges and be able to connect as SYSDBA without a password.

How to solve the ORA-01031 error in UNIX/Linux environment?
1. Check that $ORACLE_SID and $ORACLE_HOME are set correctly as:

echo $ORACLE_SID
echo $ORACLE_HOME

Find the values returned by above commands and match these values under /etc/oratab file, these have to be listed there.
screen3
The values above are matching with /etc/oratab entries.
If the $ORACLE_SID and $ORACLE_HOME are not set properly then set it as:

export ORACLE_SID=orcl11gr2
export ORACLE_HOME=/u01/app/oracle/product/1120

and try to connect as “/ as sysdba” – it should work now.
If these are correct but still the error is coming then move to step 2.
2. Ensure you are invoking sqlplus from correct $ORACLE_HOME by checking the $PATH environment variable:

echo $PATH

If this is correct but still the error is coming then move to step 3.
3. Set the SQLNET.AUTHENTICATION_SERVICES parameter to ALL in the sqlnet.ora file (located in the $ORACLE_HOME/network/admin):

SQLNET.AUTHENTICATION_SERVICES=(ALL)

If this is correct but still the error is coming then move to step 4.
4. Ensure $TWO_TASK is not set.

echo $TWO_TASK

If it return any lines, then unset the environment variable as:

unset TWO_TASK

If this is correct but still the error is coming then move to step 5.
5. Check the permissions on the Oracle executable file.
screen4
It should show the permissions as on the above screen – if its not the same then issue the following command to set the correct permissions:

chmod 6751 oracle

If these are correct but still the error is coming then move to step 6.
6. Make sure that dba group at OS level only exists once in /etc/group file and that the users belonging to the dba group are properly comma separated. Check that the oracle user uid and gid are the same in /etc/group and /etc/passwd.
If these are correct but still the error is coming then move to step 7.
7. Check for the dba group at OS level. We need to make sure that OS user issuing “connect / as sysdba” belongs to dba group at OS level.
There is one file we need to check for this: $ORACLE_HOME/rdbms/lib/config.s or $ORACLE_HOME/rdbms/lib/config.c (file name vary depending on OS). The value for SS_DBA_GRP in these file is typically set to “dba” :
screen5
Let’s check it as oracle user:

[oracle@orclprod ~]$ id
uid=54321(oracle) gid=54321(oinstall) groups=54321(oinstall),54322(orcldba)

Look for the groups value here – 54322(orcldba), the value is orcldba so we need to modify the config.c or config.s so that it should look like:

#define SS_DBA_GRP "orcldba"

After making changes to config file make sure that:
– no oracle processes are running
– login as oracle
– $LD_LIBRARY_PATH and $ORACLE_HOME are set properly
and relink oracle binaries with the following command:

$ORACLE_HOME/bin/relink all

If all previous settings are correct and still ORA-1031 is coming then the only option is to take strace output and check while opening which file the error is coming – for example:

strace -o /tmp/strace.txt sqlplus "/ as sysdba"

Run .NET framework 1.1 apps and programs in Windows 8

Recently, I tried to run the .NET framework 1.1 supported application in Windows 8.1. As you may not know .NET Framework 1.1 is not supported on the Windows 8 or Windows Server 2012 operating system. In some cases, the .NET Framework 1.1 is specifically identified as required for an application to run. In those cases, you should contact your independent software vendor (ISV) to have the application upgraded to run on the .NET Framework 3.5 SP1 or later version.
But there are cases (very often) when the software version is old and you do not have the upgraded version of the software. In my case, I tried to install the package and got the following error message: “Setup cannot continue because this version of the .NET Framework is incompatible with a previously installed one“.

There are two methods to fix this issue.
Method 1 – install .NET Framework 3.5
For some users all those apps which need .NET Framework 1.1 to run can work properly with .NET framework 3.5. So, you can optionally download .NET 3.5 and install it but make sure you can turn off 4.0 framework and other versions if you have it apart from 3.5. So you have to turn off .NET 4.0 and leave on .NET 3.5 – in my case, it didn’t solve the issue.

Method 2 – manually install .NET Framework 1.1
Download Microsoft .NET Framework 1.1 redistributable package (dotnetfx.exe). Make sure the setup file is saved as dotnetfx.exe. Download Microsoft .NET Framework 1.1 Service Pack 1 (NDP1.1sp1-KB867460-X86.exe). Make sure that the file is renamed and saved as dotnetfxsp1.exe, so that the rest of the steps can be followed easily. Move both installation files into the same directory (for example c:\dotnet).
This method involves recompiling the .NET framework 1.1 and then installing .NET Framework 1.1 with slipstreamed/integrated SP1 by running netfx.msi which will created in the working folder after running the following commands (run command prompt in admin mode and run the following command one by one):

dotnetfx.exe /c:"msiexec.exe /a netfx.msi TARGETDIR=C:\DotNet"

after it is installed

dotnetfxsp1.exe /Xp:C:\DotNet\netfxsp.msp

and

msiexec.exe /a c:\DotNet\netfx.msi /p c:\DotNet\netfxsp.msp

I hope one of the above method will work for you to run any app or program. Make sure to restart your PC after following any of the above methods.

Running Windows PowerShell scripts.

Few notes before, I wrote about finding the HP product number of any of your HP servers using PowerShell. First time, when I tried to do this, I double-clicked a .PS1 file (.PS1 being the file extension for Windows PowerShell scripts), sat back, and waited for the magic to happen.
As it turned out, however, this is what happened:
screen01
Instead of running, my script opened up in Notepad. Interesting, but not exactly what I had in mind. Oh wait, I thinked, I got it: I probably have to run Windows PowerShell before I can run a Windows PowerShell script. OK, that makes sense. And so, with that in mind, I opened up Windows PowerShell and typed the path to the .PS1 file at the command prompt. Pressed ENTER and waited for the magic to happen.
As it turned out, however, this is what happens:
screen02
Why did I get weird error messages when I try to run a script? That’s easy. The security settings built into Windows PowerShell include something called the “execution policy” – the execution policy determines how (or if) PowerShell runs scripts. By default, PowerShell’s execution policy is set to Restricted – that means that scripts – including those you write yourself – won’t run. Period.
How to verify the settings for your execution policy? By typing the following at the PowerShell command prompt and then pressing ENTER:

Get-ExecutionPolicy

Now, admittedly, this might seem a bit severe. After all, what’s the point of having a scripting environment if you can’t even run scripts with it? But that’s OK. If you don’t like the default execution policy (and you probably won’t) then just go ahead and change it. For example, suppose you want to configure PowerShell to run – without question – any scripts that you write yourself, but to run scripts downloaded from the Internet only if those scripts have been signed by a trusted publisher. In that case, use this command to set your execution policy to RemoteSigned:

Set-ExecutionPolicy RemoteSigned

Alternatively, you can set the execution policy to AllSigned (all scripts, including those you write yourself, must be signed by a trusted publisher) or Unrestricted (all scripts will run, regardless of where they come from and whether or not they’ve been signed).
After I changed execution policy settings it’s possible to run scripts. However, there is a little trick that might run you into problems. For example, suppose you change directories from your Windows PowerShell home directory to C:\scripts (something you can do by typing cd C:\scripts). As it turns out, the C:\scripts folder contains a script named script.ps1. With that in mind I typed the script name, pressed ENTER and waited for the magic to happen.
As it turned out, however, this is what happens:
screen03
I know what you’re thinking: didn’t we just change the execution policy? Yes, we did. However, this has nothing to do with the execution policy. Instead, it has to do with the way that PowerShell handles file paths. In general, you need to type the complete file path in order to run a script. That’s true regardless of your location within the file system. It doesn’t matter if you’re in C:\Scripts; you still need to type the following:

C:\Scripts\script.ps1

Now, I said “in general” because there are a couple of exceptions to this rule. For example, if the script happens to live in the current directory you can start it up using the .\ notation, like so:

.\script.ps1

And while PowerShell won’t search the current directory for scripts it will search all of the folders found in your Windows PATH environment variable. What does that mean? That means that if the folder C:\Scripts is in your path then you can run the script using this command:

script.ps1

But be careful here. Suppose C:\Scripts is not in your Windows path. However, suppose the folder D:\Archive is in the path, and that folder also contains a script named script.ps1. If you’re in the C:\Scripts directory and you simply type script.ps1 and press ENTER, guess which script will run? You got it: PowerShell won’t run the script in C:\Scripts, but it will run the script found in D:\Archive. That’s because D:\Archive is in your path.
Just something to keep in mind.

How to run scripts without starting Windows PowerShell?
As a security measure you can’t start a PowerShell script by double-clicking a .PS1 file. So apparently that means that you do have to start PowerShell before you can run a PowerShell script. However, that doesn’t mean that you can’t start a PowerShell script from a shortcut or from the Run dialog box; likewise you can run a PowerShell script as a scheduled task. The secret? Instead of calling the script you need to call the PowerShell executable file, and then pass the script path as an argument to PowerShell.exe. For example, in the Run dialog box you might type a command like this:
screen04
There are actually three parts to this command:
Powershell.exe, the Windows PowerShell executable.
-noexit, an optional parameter that tells the PowerShell console to remain open after the script finishes. Like I said, this is optional: if you leave it out the script will still run. However, the console window will close the moment the script finishes, meaning we won’t have the chance to view any data that gets displayed to the screen.
Incidentally, the -noexit parameter must immediately follow the call to the PowerShell executable. Otherwise the parameter will be ignored and the window will close anyway.
C:\script.ps1, the path to the script file

Categories: MS Windows, OS Tags: ,

Enable multiple RDP connections per user in Windows Server 2012.

By default, Windows 2012 servers allow a single Remote Desktop session (exactly the same way as it was in Windows 2008).
If only one session is available and you take over another person’s live session, you may choose to enable multiple RDP sessions.

Below, you can find steps for enabling multiple sessions:
1. Open the start screen (press the Windows key) and type gpedit.msc and open it.
2. Go to Computer Configuration => Administrative Templates => Windows Components => Remote Desktop Services => Remote Desktop Session Host => Connections.
3. Set Restrict Remote Desktop Services user to a single Remote Desktop Services session to Disabled.
4. Double click Limit number of connections and set the RD Maximum Connections allowed to 999999 (maximum allowed).

gpedit

Categories: MS Windows, OS Tags: , , ,

Desktop icons in Windows 2012 R2.

Here you can find my grumblings about desktop icons in Windows 2008R2.
Guess what? In Windows 2012R2 nothing really changed. Oh, wait – because it is the new version of Windows – adding desktop icons (My Computer for example) in Windows 2012R2 is even more complicated than before.
Anyway, first, you’ll have to go into Server Manager and under Manage, choose Add Roles and Features.
screen1

Then click Next on EVERY SCREEN until you get to the Features section, select Desktop Experience under User Interfaces and Infrastructure.
screen2

Once added, you will have to aprove installing other features required by Desktop Experience.
screen3

Then you need to reboot the server. That’s right! A reboot is required to add icons to your desktop.

Once you’ve rebooted the server, simply right-click on the Desktop and select Personalize. From here, you can add the desktop icons you desire as usual.

I’m speechless.

Repair Internet Explorer ver. 7/8/9

Recently, I had problem with IE on Windows 2003 Server 64-bit version. When I tried to open the page with JavaScript redirection I got blank screen. When I searched for the solution I discovered the following site.
Below, you can find the article (with scripts) that solved problems with IE in my case (it could disappear from the web).

This script works for IE9 as well. In particular it seems to fix the problem that after a successful installation the IE launch “blinks away” without an error message. I suggest to also completely reset IE at Internet Options -> Advanced, in this case after running the script.

This script is a rewrite of my repair script for IE6. It works with IE7 and IE8. There are two new downloads for 64bit systems, one for 32bit IE, one for 64bit IE.

Usage: unzip the download and run the cmd file in it with a doubleclick. On Vista/Windows 7/Windows 2008 you have to do this with administrator privileges (right-click on the cmd file and choose “run as administrator”). The command window will stay open after excecution, so you can check for errors. Do not run in “safe mode”. If the problem doesn’t go away you may need to reboot Windows for it to take effect. Also, it may be helpful to reset IE completely (as explained above).

This script is mainly intended to fix some missing registrations of system libraries (DLLs) after initial installation of IE8. You can use it later, too. The missing registrations are usually a result of using registry cleaners. But it registers or installs all files that are part of IE8 as they come with the IE8 setup file, plus a few others which are known for clear problem symptoms in case their registration got lost.

Recently (after Windows 7 launch) there have been many reports on problems with 32bit IE8 on Windows 7 64bit, that can be corrected with the ie8-rereg.32-on-64.cmd script. You should be aware that this is not a bug in Windows or IE. These problems are created by not-uptodate programs that write wrong values in the registry where they should not write at all. A known example are Opera versions that come pre-installed on “magazine CDs” for browsing the content of those disks.

Among other symptoms this script may fix:

  • open in new tab/window not working
  • find on this page “empty”
  • tabs on Favorites pane missing
  • about screen and other dialogs “empty”
  • IE8 closes immediately (not if caused by an add-on!)
  • can’t print (interface not registered)

The reregistration of the crypto functionality (initpki) is commented out. It’s very rarely necessary and takes a long time to finish. In case you really need it, please look in the script (at the end) and activate it.

The new scripts for 64bit Windows do not contain the shdocvw.dll fix anymore as this bug seems to occur only on Windows XP. In case you need that fix you can look up the necessary reg command at the end of the script. You know that you need that fix if the new tabs page (about:tabs) is changed and doesn’t display the last visited sites anymore after running the script.

Versions:
ie8-rereg.cmd – for IE7/8/9 on 32bit-Windows
ie8-rereg.32on64.cmd – for 32bit IE7/8/9 on 64bit Windows
ie8-rereg.64on64.cmd – for 64bit IE7/8/9 on 64bit Windows

You could download all versions of the script here.